treat bookmarks, tags, and selection box like virtual directories

[knodalyte]

Bookmarks, tags, and the selection box are collections of files and/or directories, and their utility would be enhanced by treating them as if they were virtual directories, with all the existing clifm capabilities that would make these collections even more powerful.

I'm thinking as I'm writing, but perhaps a new command "virtualize" that could accept as arguments the existing bookmark, tag, or selection box commands and options, for example:

• virtualize sb
• virtualize t:mypdfs
• virtualize bm

For each of these scenarios, clifm would present the result set as if it were a directory full of files and/or subdirectories for further interaction using the existing clifm commands and shortcuts.

Perhaps this change could be implemented in part by making bookmarks and the selection box special cases of the tags function. This would also enable bookmarking of files as well as directories.

I think this will bring new power to an already highly functional application.

[leo-arch]

Hi @knodalyte. Thanks for this suggestion: virtual directories for special sets of files is no doubt an interesting idea. I guess it could be implemented using symlinks. Added to my todo list.

For the time being, it is already possible to operate on both specific tagged and selected files via the TAB key (if using fzf as TAB completion mode). For example:

For selected files:

p sel<TAB>

For files tagged as mypdfs:

p t:mypdfs<TAB>

Selected/tagged files will be listed. Mark those files you need (hitting TAB again) and then press Enter (or Right): marked files will be inserted into the command line, so that you can operate on them (in this example getting the files properties) as on any other file.

Not perfect, but pretty close to what you ask. Two missing features here (as far as I can see):

1. The ability to list/sort a given set of files as if they were files in CWD
2. There is no similar TAB expansion for bookmarked files (something like p bm<TAB>)

Besides the these two points, what else do you think cannot be done with CliFM as is now?

[knodalyte]

It's mostly about your missing point 1: treating tagged files as if they were files in clifm. I agree that it is possible to achieve most of the same results using the

command t:mytag<TAB>

construct, though it requires more cognitive load to think about what command I want to use before I even see the list. It also requires a two step process to (for example) get a long listing of tagged files and directories and then do something based on the file dates or sizes.

After looking more closely at how tagging operates, tagging would not replace bookmarks (although it does of course allow files to be tagged, whereas I cannot bookmark a file), because tags don't support shortcuts or names.

[leo-arch]

Though I already started planning the virtualization system (don't promise anything however), version 1.6 will be released as is.

Btw, regular files can be bookmarked.

[leo-arch]

Hey @knodalyte, it is now possible to operate on specific bookmarks (just as you do with selected and tagged files) using the b: construct. Take a look at the description.

[knodalyte]

The b: construct is an improvement and does enable using clifm commands reasonably easily.

However, the use of the fzf list viewer/selector makes the UX not quite as powerful as the native clifm interface.

[leo-arch]

the use of the fzf list viewer/selector makes the UX not quite as powerful as the native clifm interface

Could you elaborate on this please?

[knodalyte]

I will try. I am making this up as I go along...

In the "clifm interface" (as opposed to the fzf interface), I can see (or select to see) details like file and directory timestamps, file izes, the number of children in a directory. I can also sort, filter,select using commands (as opposed to keyboard shortcuts), use ELNs. I can also use the standard set of clifm commands to do things like remove items, instead of the special bookmark commands.

In the case of bookmarks, not sure how consequential any of these are, but for selected files, maybe more so.

[leo-arch]

I see. The only way to get a native clifm interface, as you call it (I like it btw), is by means of virtual directories for these sets of files (selections, tags, and bookmarks). This feature is planned, and indeed I have the general outlines. Implementing it, however, is a different story.

Thanks again @knodalyte!

[leo-arch]

Hi @knodalyte. Added a new plugin to handle collections of files as virtual dirs. It makes use of an already existing feature of clifm: reading files from STDIN.

You need the latest clifm version for this to work.

To use the plugin, just add an action for it (actions edit) as follows:

vt=virtualize.sh

Run it as follows:

vt FILES...

where FILES could be individual files or sets of files (via sel and t:TAG). In the case of bookmarks, we have no auto-expansion yet. So, to pass all your bookmarks use TAB completion (vt b:<TAB>) and then select all matches with Ctrl-s.

For the time being it has only one option (-f), to list files as full paths (slashes replaced by colons) instead of just base names. Couldn't decide which approach was better, so that I added an option to let you use whichever you think is the best.

Once launched, it will execute clifm on a new terminal window (no console for now, sorry) using the temporary virtual directory as starting path. It's hard-coded to use "xterm -e" as terminal command. Of course, you can easily change this as you please by just editing virtualize.sh.

There's still plenty of room for improvement, and even things that just won't work (e.g. file names with spaces). But it's a good start.

EDIT: Keep in mind that files in a virtual directory are symlinks to the actual files, though operations on these symlinks are made not on the symlink itself, but on the target.

[leo-arch]

File names with spaces shouldn't be a problem now (four calls to sed(1) is not the ideal solution, but it works).

[knodalyte]

A couple quick notes:

1. selected files are displayed with colons instead of slashes, I think this is how the symlinks are stored, My sed fu was not adequate to tweak this in the script. Maybe inconsequential.
2. a note for anyone who wants to use kitty instead of xterm, the correct change is term_cmd="kitty sh -c"

I haven't played around with it enough yet to see how well it works in real life.

[leo-arch]

I'm not sure I understand your first point (and thanks for point 2), but here's the thing:

My biggest concern with this feature is how to display file names in the virtual directory. As far as I can see, we have two options:

1. Only the base name (if the file is /path/to/file), print only file.
2. The entire path.

Both approaches have their pros and cons:

1. Easier to read than 2, but the user has no easy way to know where that file is located exactly (a second operation is needed, i.e. using the p command to get the file's properties). Plus, if you have several files with the same name in different locations (say /path/to/file and /path2/to/file), we have two listed files with the same (base)name, in which case we need to modify one of them (currently a random six digits suffix is appended, for example, file.123456)
2. The whole file path is immediately present to the user (no further operation needed). However, this approach is unintuitive and generates larger file names (which will probably be trimmed down to 20 chars, clifm default max file name length). Slashes in the path are to be replaced by something else, since it is just not possible to use slashes as part of a file name: slashes are reserved as path components separators in Unix file systems. I replace slashes with colons, which is more or less arbitrary, but doesn't make much difference.

A third, hybrid approach is possible: use 2 only in case of identical base names. In our example, /path/to/file and /path2/to/file will become path:to:file and path2:to:file (while the remaining files will be printed according to 1). But we still have the same issues outlined above.

Just thinking aloud: a fourth approach would be to use 1 by default and set a keybind (say Alt + some_key) to toggle short and long formats (1 and 2 respectively).

Btw, do you know of any other implementation of virtual directories? It would be nice to know how others addressed this issue.

[leo-arch]

Finally, I took the fourth approach. By default, files in virtual directories are listed in the short form (base name of the target file), but can be switched to the long form via a keybinding (Alt-w). See the documentation here.

To use this new keybinding, do not forget to update your keybindings.cfm file: just delete it and it will be recreated automatically (run kb edit or restart clifm).

If you prefer to update the file manually, just add this line:

toggle-virtualdir-full-paths:\M-w

[leo-arch]

Hi @knodalyte. Have you tried this? Is it ok?

[knodalyte]

Hi Leo, yes, I have just been experimenting with it and like how it works with selected files and tabs. I think you indicated that virtualizing bookmarks is not complete yet.

One note: in the case of user error that is attempting to virtualize an invalid object, like vt b:<CR>, maybe the subprocess should be shortcircuited instead of opening a term that must then be quit.

[leo-arch]

virtualizing bookmarks is not complete yet

The only missing feature compared to tags and files selection is auto-expansion: b: or bm to automatically expand this expression to all bookmark paths.

the subprocess should be shortcircuited

Fair enough.

Thanks for your suggestions @knodalyte!

[leo-arch]

the subprocess should be shortcircuited

Done. Not perfect, but better.

[leo-arch]

Hi @knodalyte. Bookmarks automatic expansion is finally ready. For example,

vt b:

will send all your bookmarks at once to a virtual directory.

Note that :b also works.

Even more, automatic expansion has been added for file type and MIME type filters as well. So, now you can do

vt :b @image =l =x *.txt t:work sel

to open a virtual directory with:

Expression	Description
:b	All you bookmarks
@image	All image files (filtered by MIME type) in the CWD1
=x	All executable files (CWD)
=l	All symbolic links (CWD)
*.txt	All .txt files (CWD)
t:work	All files tagged as work
sel	All selected files

¹ Technically, all files whose MIME type contains the string image

[knodalyte]

This is great! Thank you!

As far as I am concerned, this issue can be closed.