Welcome to clifm Discussions!

[leo-arch]

Welcome!

We’re using Discussions as a place to connect with people interested in this project. Here you can:

• Ask whatever question you’re wondering about.
• Share ideas and suggest new or improved features.

[tuerda]

Hello. I have been using this file manager quite heavily for a few days, and I would like to offer a very detailed review.

First and foremost: I love it. I probably had been looking for something like this for years, and didn't quite realize it.

In a sense, this feels almost like it could be a whole bunch of convenient shell aliases and such, but every time I try to think about how I would implement it in that way I realize there is more going on.
The improvements over just using the bare CLI to manage files are very subtle, but also highly significant.

It is so close to being a shell interface, though, that I thought for a bit about literally just using it as my shell.
I decided this probably was not a good idea, because it makes certain potentially dangerous operations too easy to do by mistake.

Comments on the core functionality:

• Re-displaying the directory contents and file numbers is something that feels like it should have a more direct method.
  There is a somewhat un-ergonomic keybinding, and there is also issuing the command . . The second method is the one I use, and it works fine, but I wonder, "why not do this if I just send a blank line as a command?".

• Symlinks in unix are a bit touchy. In the basic shell, if I do ln -s file1 ../bin/stuff it will actually do something really dumb, which is create a file in ../bin/stuff named file1 which does nothing at all because it is a symlink to itself.
  In order to get the link to work, you either have to write up the relative path from the destination directory, or the absolute path for the file.
  Which is preferred depends a little bit on the situation, but both are a bit of a hassle.
  I was hoping that in clifm the l command would automatically solve this issue doing one of these approaches (the absolute path is probably the easiest to implement), but it did not. Using the filename itself I can kind of see why you might want to keep it faithful to the shell, but if I use the number that corresponds to it, I clearly am talking about the file itself and not about the name as it appears in the list.

• Filters work backwards from what I would expect. If I filter for a regex, I would expect to see only files that match that regex, but instead I see only files that do not. This is not a big deal, since files that match a regex can still be shown using /, but I still find it mildly confusing, and wonder if maybe there should be a way to reverse the behavior of a filter.

Bugs:

I used the hell out of this and got one bug in the core functions once. The text I typed into the commands was invisible. It was still working, and the output of commands displayed just fine, but the commands themselves did not. I restarted the program and tried to do the same things to see if I got the same result twice, but I did not. I am not sure what conditions triggered it.

Plugins, extensions, etc:

While the basic functionality worked essentially without any problems at all, the same could not be said for the plugins that I tried.
I personally do not care about these plugins, and I tried them mostly to provide feedback.
I am also aware that these depend on some external programs and that some of this might involve the versions of the external programs which I am running, etc.

I tried and had trouble with two plugins: fzf-nav and icons.

icons:

This is the easiest one. I use a pretty unusual bdf font.
The icons-in-terminal project simply failed to patch in the icons, probably because it expected my font to be a more modern true type font like everyone else uses.
I installed, tried it in clifm, found that the icons were just squares, then went and tried the display icons script from the icons in terminal project and found that that displayed squares as well.
Hence, this is in no way your fault, but you might want to add a warning that it might not work with all fonts.

fzf-nav:

This mostly worked, but the issues were quite infuriating.
It is bad enough that I would never use this, but, I personally do not care:
The main attraction to it was the file previews, and I found that the fzf program simply was not the interface I would choose for file previews. I tried launching ranger nested inside clifm and it worked just fine, file previews and all, and the ranger interface was nicer than fzf anyway.

The issues were specifically with the BFG file previews. The parts that I looked into deeply were the display of images with ueberzug, and the display of pdf files with pdftotext.
I was unable to figure out how to change what program was used to display the previews of each filetype. In particular, pdf files were not being displayed with pdftotext, but instead the first page was displayed as an image with ueberzug. I tried to edit the fzf-nav script, as instructed, but nothing that I did changed this. I did not completely understand how the switches to test if a program was installed worked: I tested them separately in my shell and all of them were consistently evaluating to true, regardless of whether the program in question was installed or not.
I tried uninstalling ueberzug, and pdf files just gave a message that it was a binary pdf file, and did not display anything at all. I tried opting to use scope.sh instead, but then images and pdf files both just gave me an empty box (plain text files did display and used the usual scope.sh highlighting scheme).

Getting previews of pdf files as images is not necessarily a bad thing, mind you, but the way ueberzug was working was pretty bad. Previews of images and pdfs were not displayed in their assigned box, but instead plastered over the directory view, covering up the rest of the interface and not allowing me to see what I was doing. It is this particular issue that - to my mind - renders the whole thing completely unusable.

FINAL THOUGHTS:

Overall great work! This made enough of a difference in my workflow that I quickly cleaned up several messy parts of my filesystem that I had just allowed to fester with my previous tools. I am not sure how I ever lived without it!
There are some things that I think it might be possible to do better (symlinks in particular).
I also found that the plugins I tried had some rough edges.
Everything else is pretty much perfect though.

[leo-arch]

Filters work backwards from what I would expect

The files filter works now as you said it should: !REGEX to exclude, and REGEX to include only those files matching the pattern.

[tuerda]

Just saw this now. Thanks for the update. This feels more intuitive to me.

[leo-arch]

In a sense, this feels almost like it could be a whole bunch of convenient shell aliases and such, but every time I try to think about how I would implement it in that way I realize there is more going on.

Indeed, CliFM started as a simple attempt to create a bookmarks system for the shell. The first version(s) of the program was in fact a (horrible) bash script. But as soon as you try something a bit more complicated, the shell tools probe to be quite inefficient (desperately slow). A shell script was definitely not the adequate tool. This is why the whole thing was rewritten in C (I even tried Python, but... no). I you care about performance, C is no doubt the way to go.

I thought for a bit about literally just using it as my shell

Exactly as you yourself figured it out, that's not a good idea at all. CliFM is a FILE MANAGER, tightly integrated to shell, true, but it is not a shell (I myself tried some time ago to convert the whole thing into a shell of its own, but realized that such an attempt was not only quite hard, but also unnecessary: we already have shells doing the same thing, and better for sure). However, I have not found any serious issue using CLiFM as a shell, at least running some basic shell commands: I myself do it all the time. But it is still NOT a shell.

Re-displaying the directory contents and file numbers is something that feels like it should have a more direct method

rf (short for refresh) is a command specifically designed for this purpose. Not sure if it is as direct as you expect though. About the blank lines idea, I'm not sure about it: blank lines are mostly intended to refresh/update the prompt (and only the prompt). But I will consider it.

Symlinks in unix are a bit touchy.

True. And it is also true that I tried to keep it faithful to the shell, just because I don't want to make decisions in place of users. However, sometimes it is needed (c, and md do this after all). But there would be not a problem at all to improve the l command. May you expand a bit more on what you exactly expect from this command: how should it behave exactly, under what conditions? Once again, the issue needs to be reproduced.

Filters work backwards from what I would expect

Yes, by default filters exclude, and I just never thought about making it work the other way round. But it seems a quite reasonable demand, and quite easy to implement. It will be done.

About the bug(s): No way to fix it if it cannot be reproduced.

Plugins:

Here you touch the two plugins I care the most, just because people really like this kind of stuff: I've seen people rejecting a file manager just because it cannot preview files. So, files previewing and icons are important.

This said, the icons issue is completely foreign: as you said, it depends on your fonts (though I didn't know/try it thus far) and on your terminal. I did was aware nonetheless of the terminal issue. urxvt do not correctly display (they look square) these icons (those provided by icons-in-terminal I mean). On most other terminals icons work just fine. I guess I should better document this feature. What I could try is to add support for other terminal icons projects, like nerd fonts. Do you know if nerd fonts work right on urxvt?

Previewing is a native feature of FZF, so I thought it would be a good tool for the job (and I should say it mostly works). I'm sure it is a matter of configuration. Just tell me exactly what terminal, fonts, and configuration are you using to improve the plugin. I need to reproduce the wrong behavior to fix it. It should not be any problem at all.

Needles to say, thank you very much for your time and report.

[tuerda]

I tried to restore the position (lines 45-51) and change only the size:

WIDTH=10
HEIGHT=10

This put me right back where we were before. The images are back, in the wrong place, and way too big (even with this drastic change in default sizing).

I found another place which seemed to have some hardcoding of width and height variables on line 361. I tried to make those 50x20 instead of 500x290 to see if that did anything; it did not.

---

Going off topic slightly:

slmenu is a very old program which was maintained for all of about a month circa 2013 or so.
I am no longer able to find it online anywhere, but I have been keeping my own backup around since then.
You could think of it as a drop-in replacement for fzf in any script that doesn't require the previewer.
It is literally just taking the dmenu source code and making the smallest change necessary for it run in a terminal instead of as a GUI.
There are two things I like about it: It draws the menu below the prompt without redrawing the terminal screen so I can still see output of previous commands. It also is not fuzzy, so I don't get tons of false positives.

The one line plugin is really just taking alias dcd='cd "$(find -type d 2> /dev/null | slmenu -i -l 20 )" ' and convincing it to work in clifm. It is a little more like jumper than like fzfnav . . . the point is just to go someplace directly without any of the intermediate steps. If you add your usual boilerplate "check if fzf is installed . . . bla bla" it could be a reasonable alternative.

[leo-arch]

Don't worry about the previewer issue: it will eventually be solved. For the time being, specially because it seems to happen only in your specific setup, we will let it live. However, I'm reworking the previewer with a few important changes:

a) Use hashes (instead of file names) for cached images: many files could have the same name, and that's a problem.
b) Add a configuration file (BFG.cfg) for easy setup. It is not that configurable right now, but at least lets you choose which of the available applications to use for different file types: asking to user to edit the code is definitely not a friendly gesture.

As to slmenu, the problem is that it cannot be found anywhere, and thereby adding it as an alternative to fzf makes not much sense. As soon as I realized that it was not in Arch repos (not even in the AUR!), I knew it was a very rare program. I guess it is something like dmenu, isn't it?

[tuerda]

This sounds like cool stuff, although I don't really need a previewer so I probably will not use it (except for testing, if you ask me to).

Yes, as I said, slmenu is off-topic.
I think I might be the only person on earth who uses slmenu (I use the hell out of it though). I did not mean to suggest you should offer slmenu as an alternative to fzf. I write and maintain my own slmenu scripts, and I do not expect you to participate.

I would also be willing to put slmenu on github if anyone but me showed signficant interest. As far as I can tell, however, nobody cares, so I just keep my own backup.

[leo-arch]

A Github repo would be a nice idea. Maybe people don't care just because they don't know, not because slmenu isn't worthwhile. I would definitely give it a try.

Btw, could you please take a look at this?

[leo-arch]

a) Use hashes (instead of file names) for cached images: many files could have the same name, and that's a problem.
b) Add a configuration file (BFG.cfg) for easy setup.

Done. though the previewer issue is still there, fzfnav should be better now: most features can be disabled if you don't like/need them, and previewing applications can be chosen from a (limited) list of supported applications.

[leo-arch]

I almost forgot it: I will improve fzfnav and BFG scripts to make them more easily hackable. Better documentation for this is needed too. Consider most plugins as beta features. Btw, do you know of any file previewer better than FZF?

[tuerda]

If we are talking about previewing programs for the terminal, I honestly feel like ranger knocks this out of the park.

I actually kind of like ranger, and I would happily use it if TUI was my jam. I used to think that it was, but clifm has pretty much put the final nail on that coffin.

[leo-arch]

Regarding the re-displaying thing, have you tried rebinding the keyboard shortcut to something more ergonomic? You could also wright a simple alias for the rf command, I mean, some single char like z or something.

[tuerda]

I am using . for this purpose.
It is pretty direct and works fine.

This is more like an "If I had written this, the way I would have done it is . . . " rather than an actual criticism. I just feel like the list is very important in clifm and even might have thought to automatically re-display if it ever scrolls off screen (this is too much, though: You might cover up some important info)

[leo-arch]

re-display if it ever scrolls off screen

Do you mean something like repeatedly pressing Enter in the prompt till the list just disappears? In that case, it shouldn't be hard to implement. Maybe as an optional feature.

[tuerda]

That is an option I guess.
TBH I don't care about this very much and I don't think you should lose sleep over it either: If I had made clifm it would have been very eager to show you this list all the time.

The way you did it is different, but it is sensible and good.

[leo-arch]

I'll bear you suggestion in mind anyway.