Welcome to Vifm Q&A, where you can ask questions about Vifm usage. Registration is optional, anonymous posts are moderated. GitHub or Google logins are enabled.
0 votes
in vifm by

I tried to simulate a Miller columns layout (albeit with only 2 columns) in vifm using tree, because I believe it to be a more useful type of folder preview, as it allows to swiftly peek through the content of many folders without having to enter them. The dual pane layout (orthodox), on the other hand, is more optimal for moving files, and vifm makes toggling between the two layouts easy using w by default.

In my ~/.vifm/vifmrc :

" Directories
 fileviewer .*/,*/ tree -CFixL 1 --dirsfirst --noreport %f|tail -n +2

Now, here are the problems I encountered in my quest to integrate tree's output to vifm's preview as seamlessly as possible:

  1. vifm's preview pane always displays a blank line on top, causing a shift.
  2. tree sorts directories alphabetically regardless of cAsE, unless its output is piped to sort -f, but still, executable files sort before folders, which is not the same order as in vifm.
  3. Since tree is not aware of the width of vifm's preview pane (which can vary depending on the terminal size), files with long file names spill over multiple lines instead of being trimmed.
  4. Finally, there are other minor inconsistency issues, but they are not paramount right now.

Do you think that they can be resolved, or would it be better to implement native directory preview in vifm instead of relying on tree and tail?

2 Answers

0 votes
by

I tried to simulate a Miller columns layout (albeit with only 2 columns) in vifm using tree, because I believe it to be a more useful type of folder preview, as it allows to swiftly peek through the content of many folders without having to enter them.

For me it's like you enter them, but always in control of parent directory, which is counter-intuitive. Tree-like view is somewhere in between, I guess.

would it be better to implement native directory preview in vifm

It's already implemented although the purpose is different and there is no depth limit.

vifm's preview pane always displays a blank line on top, causing a shift.

Maybe this should be controlled by s in 'tuioptions'.

tree sorts directories alphabetically regardless of cAsE, unless its output is piped to sort -f, but still, executable files sort before folders, which is not the same order as in vifm.

Hard to work around this tree, builtin implementation just sorts by name (in case sensitive way on *nix). It's possible to make it sort as current view at the cost of some slowdown (meta-data for each file must be queried).

Since tree is not aware of the width of vifm's preview pane (which can vary depending on the terminal size), files with long file names spill over multiple lines instead of being trimmed.

This one is easy, just set 'nowrap' option.

Finally, there are other minor inconsistency issues, but they are not paramount right now.

Do you think that they can be resolved

Why use tree for a single level? Wouldn't ls be better choice? E.g.:

fileviewer .*/,*/ ls --group-directories-first --classify --color %c
by

>> vifm's preview pane always displays a blank line on top, causing a shift.

Maybe this should be controlled by s in 'tuioptions'.

It definitely should be configurable.

fileviewer .*/,*/ ls --group-directories-first --classify --color %c

Fails on OS X (-_-)

by

BSD-style utilities lack long options along with lots of useful features, but one should be able to install normal (GNU) binutils.

0 votes
by

As of now development version implements per-pane miller mode with file preview being on the other pane if needed:

Miller view

It will be part of the next release (v0.9.1 probably).

If you would like to make a bug report or feature request consider using GitHub, SourceForge or e-mail. Posting such things here is acceptable, but this is not a perfect place for them.
...