Welcome to Vifm Q&A, where you can ask questions about using Vifm. Registration is optional, anonymous posts are moderated. E-mail and GitHub logins are enabled.
Ask a Question

Misc feedback

0 votes
in vifm by

Here is some miscellaneous feedback I would like to share.

  1. When deleting two directories, you get the message Are you sure you want to delete 2 files? and after confirmation the message 2 files deleted. Just a small detail, but I found it a bit confusing. Changing the wording to 2 items or 2 entries would encompass both files and directories.
    Another solution, but harder to implement than just changing the wording, would be to differentiate based on the type of entry: e.g. 2 directories deleted (in the case of only directories) or 1 directory and 3 files deleted (in the case of a mix of files and directories).

  2. A :messages clear (sub)command might be useful when debugging user commands, like in Vim.

  3. I don't know if Vifm is to blame for this, but when using the AppImage version, FUSE mounts over SSH work very slowly, to the point of being almost unusable. The Homebrew version works just fine.

  4. Is it possible to configure how often the file is reloaded when using automatic forwarding? It feels pretty slow at the moment. Some tests seem to indicate that it's only forwarded once every 10 seconds, while tail -f reflects updates instantaneously.

  5. The link to the #vifm@Freenode IRC channel on the website should probably be changed to Libera Chat, or removed.

  6. I noticed two very small typos in the documentation. I could make a PR, but I'm not sure how to do so because there is both vifm-app.txt and vifm.1 and I assume one is generated based on the other.

Thanks a lot for the recent updates to Vifm!

1 Answer

+1 vote
by
selected by
 
Best answer

Thanks for the feedback!

  1. When deleting two directories, you get the message Are you sure you want to delete 2 files? and after confirmation the message 2 files deleted.

Will change to "items". Being more specific requires more bookkeeping and deciding what to do with things like symbolic links to directories.

  1. A :messages clear (sub)command might be useful when debugging user commands, like in Vim.

Will add.

  1. I don't know if Vifm is to blame for this, but when using the AppImage version, FUSE mounts over SSH work very slowly, to the point of being almost unusable. The Homebrew version works just fine.

I don't see there being a difference. Is there a delay when you're making a connection or is everything slow? The first one could be related to things like SSH agent and associated timeouts.

  1. Is it possible to configure how often the file is reloaded when using automatic forwarding? It feels pretty slow at the moment. Some tests seem to indicate that it's only forwarded once every 10 seconds, while tail -f reflects updates instantaneously.

You can adjust 'timeoutlen' which is 1 second by default (don't know how you got 10 seconds). There is no delaying of file checks, they happen in response to key presses or when reading a key times out.

  1. The link to the #vifm@Freenode IRC channel on the website should probably be changed to Libera Chat, or removed.

I wasn't sure if that channel still exists and checked it only now. Seems to be gone (there is a new one in its place), so removed the link.

  1. I noticed two very small typos in the documentation. I could make a PR, but I'm not sure how to do so because there is both vifm-app.txt and vifm.1 and I assume one is generated based on the other.

Will fix. The files are just edited at the same time. I'm not aware of ways to generate one from the other (although there might be tools for trivial cases).

by
edited by

Thank you for your replies.

I don't see there being a difference. Is there a delay when you're making a connection or is everything slow? The first one could be related to things like SSH agent and associated timeouts.

Everything is very slow. For example, moving the cursor or changing directories happens in slow motion. I use the same connection, connect to the same remote system, use the same Vifm version etc. The only variable is the way Vifm is installed.

You can adjust 'timeoutlen' which is 1 second by default (don't know how you got 10 seconds). There is no delaying of file checks, they happen in response to key presses or when reading a key times out.

I open three terminals:

  • In terminal 1 I run tail -F vifm-test.log.
  • In terminal 2 I open Vifm, preview the same log file and hit F to enable automatic forwarding.
  • In terminal 3 I execute echo $RANDOM >> vifm-test.log.

New lines are immediately visible in the tail terminal. In the Vifm terminal, they only appear after long delays (up to 10 seconds in my experience), or indeed 1 second after a random key is pressed.

Perhaps I misunderstood how the automatic forwarding feature works. The documentation describes it as: "Roughly equivalent to periodic file reload and scrolling to the bottom. The behavior is similar to tail -F or F key in less." I expected that I didn't have to press a key to receive updates, and that they would happen immediately, like tail -F does.

I have created two commands that more or less accomplish what I expected.

command! Follow
  \ : execute '!clear'
  \ | execute '!!tail -F -n 100 %%c'

command! FollowColor
  \ : execute '!clear'
  \ | execute '!!tail -F -n 100 %%c | batcat --paging=never -l log'
by

Everything is very slow. For example, moving the cursor or changing directories happens in slow motion. I use the same connection, connect to the same remote system, use the same Vifm version etc. The only variable is the way Vifm is installed.

Not sure what could cause this. You could try passing --appimage-mount to the AppImage and running $path/usr/bin/vifm to see if that changes anything. Just saw that I've been using appimagetool from 2019, but that's not a very likely cause. The AppImage is built in a Slackware 14.2 container, not sure if that could introduce such delays though. What's your distribution?

In the Vifm terminal, they only appear after long delays (up to 10 seconds in my experience), or indeed 1 second after a random key is pressed.

It should be 1 second ('timeoutlen' ms) if no key is pressed or immediate if a key is pressed. You get delays in weird places. Unfortunately, it's hard to diagnose stuff like this. There is some rudimentary logging, but I'm not very hopeful it will help.

by

Changes for the future v0.15 release:

by

Sorry for the late reply.

Thanks for implementing these features so quickly! I'm looking forward to v0.15.

By the way, I noticed that an up-to-date version is once again available in the Debian repositories, which is very helpful as well.

You could try passing --appimage-mount to the AppImage and running $path/usr/bin/vifm to see if that changes anything

The delays are indeed gone when I run ./vifm-v0.14.3-x86_64.AppImage --appimage-mount in one terminal, and then e.g. /tmp/.mount_vifm-vpB1Zpi/usr/bin/vifm in another.

The AppImage is built in a Slackware 14.2 container, not sure if that could introduce such delays though.

I tried a very old AppImage (vifm-v0.12-beta-x86_64.AppImage) as an experiment, and the delays are noticeable there too.

What's your distribution?

I'm using Linux Mint 22.1.

It should be 1 second ('timeoutlen' ms) if no key is pressed or immediate if a key is pressed. You get delays in weird places.

Sorry, it turns out that I had set timeoutlen=10000 set. When I comment that line out, automatic forwarding works indeed as expected. I had set it to such a long time (10 seconds) to give myself sufficient time to use the very handy "which-key" (not sure about its official name) feature. I have dozens of key bindings set, and 1 second is too short to get an overview of them all. The Vim plugin keeps the preview of the key bindings open until the next key is pressed, which seems more convenient than a set time.

by

The delays are indeed gone when I run ./vifm-v0.14.3-x86_64.AppImage --appimage-mount in one terminal, and then e.g. /tmp/.mount_vifm-vpB1Zpi/usr/bin/vifm in another.

I failed to reproduce the delays in a Mint 22.1 VM. Please check whether running something like export APPDIR=/tmp/.mount_vifm-vpB1Zpi/; $APPDIR/AppRun has the same issue. We know the binary is fine, but maybe AppRun affects the outcome.

Sorry, it turns out that I had set timeoutlen=10000 set. When I comment that line out, automatic forwarding works indeed as expected. I had set it to such a long time (10 seconds) to give myself sufficient time to use the very handy "which-key" (not sure about its official name) feature.

Those are called suggestions in Vifm.

I have dozens of key bindings set, and 1 second is too short to get an overview of them all. The Vim plugin keeps the preview of the key bindings open until the next key is pressed, which seems more convenient than a set time.

The behaviour depends on the input. The wait time is infinite if already typed keys are not mapped to anything. You may want to use <wait> for some mappings.

by

Please check whether running something like export APPDIR=/tmp/.mount_vifm-vpB1Zpi/; $APPDIR/AppRun has the same issue. We know the binary is fine, but maybe AppRun affects the outcome.

This does seem to affect the outcome. The delays return when I follow these steps:

  • Run ./vifm-v0.14.3-x86_64.AppImage --appimage-mount in one terminal. This outputs a (random) directory name: /tmp/.mount_vifm-v7jqmxC.
  • Copy that directory name and use it to run export APPDIR=/tmp/.mount_vifm-v7jqmxC; $APPDIR/AppRun in another terminal.

There are no delays when I run directly /tmp/.mount_vifm-v7jqmxC/usr/bin/vifm in another terminal.

You may want to use <wait> for some mappings.

Thank you for this suggestion — I wasn't aware of the <wait> map argument.
It turns out that for some mappings, the wait time is indeed already infinite, e.g. for nnoremap xf :Follow<CR>.
However, for most of my mapping I use <Space> as the <Leader> key, and for these mappings the wait time still seems to follow timeoutlen, even after adding <wait>, e.g. nnoremap <wait> <Space>d :messages<CR>.
I'm also noticing another peculiar thing that might be related: when I press <Space>, all suggestions show up, not just those prefixed with a space:

key:  d     :messages<cr>
...
key: !      make cmdline range
...
key: <c-a>  increment number in names
by

This does seem to affect the outcome. The delays return when I follow these steps:

Thanks for testing, I actually didn't expect that result. The script sets/updates $LD_LIBRARY_PATH, $VIFM_APPDIR_ROOT and $TERMINFO_DIRS, which shouldn't have significant effects on FUSE. I wonder if either of this will cause the delays:

export VIFM_APPDIR_ROOT="path printed by ./vifm-v0.14.3-x86_64.AppImage --appimage-mount"; $VIFM_APPDIR_ROOT/usr/bin/vifm
APPDIR="path printed by ./vifm-v0.14.3-x86_64.AppImage --appimage-mount"; LD_LIBRARY_PATH="$APPDIR/usr/lib:$LD_LIBRARY_PATH" $APPDIR/usr/bin/vifm

However, for most of my mapping I use <Space> as the <Leader> key, and for these mappings the wait time still seems to follow timeoutlen, even after adding <wait>, e.g. nnoremap <wait> <Space>d :messages<CR>.

That's not expected.

I'm also noticing another peculiar thing that might be related: when I press <Space>, all suggestions show up, not just those prefixed with a space:

Haven't seen that. This may be caused by your set of mappings. Maybe show user mappings from :nmap <space> (only left-hand side is important).

by

I wonder if either of this will cause the delays:

I've tested both commands.

No delays for this command:

export VIFM_APPDIR_ROOT="path printed by ./vifm-v0.14.3-x86_64.AppImage --appimage-mount"; $VIFM_APPDIR_ROOT/usr/bin/vifm

Very strong delays for this command:

APPDIR="path printed by ./vifm-v0.14.3-x86_64.AppImage --appimage-mount"; LD_LIBRARY_PATH="$APPDIR/usr/lib:$LD_LIBRARY_PATH" $APPDIR/usr/bin/vifm

That's not expected.
Haven't seen that. This may be caused by your set of mappings. Maybe show user mappings from :nmap (only left-hand side is important).

I've managed to create a minimal reproducible example. My entire vifmrc is the following:

set suggestoptions=normal,visual,view,otherpane,keys,marks,registers

nmap     <Space>          <nop>

nnoremap <wait> <Space>a  :echo 'Pressed "<Space>a"'<CR>

nnoremap xa               :echo 'Pressed "xa"'<CR>

The issue is the nmap <Space> <nop> line. I've disabled this key because I prefer using <Tab> to switch the active pane and <Space> as my <Leader> key, like in Vim.
Removing this line makes the suggestion issue disappear. This has the minor side effect that pressing <Space> will in some cases still switch the active pane (e.g. pressing <Space>b if that isn't mapped), but I guess that's not too bad.

by

Very strong delays for this command:

Thank you, something in your system must not like this variable (maybe it results in weird library lookup or triggers something like AppArmor). It really shouldn't affect anything because $APPDIR/usr/lib is empty at the moment and I can even remove the variable altogether now that I know it's problematic since it's unused at least at the moment. However, please do one last test which avoids :$LD_LIBRARY_PATH:

APPDIR="path printed by ./vifm-v0.14.3-x86_64.AppImage --appimage-mount"; LD_LIBRARY_PATH="$APPDIR/usr/lib" $APPDIR/usr/bin/vifm

Adding : at the end (when the variable is not set) may be somehow causing the delays.

nmap <Space> <nop>

Thanks again, this is a bug.

by

Your intuition seems to be correct again. This command produces significant delays:

APPDIR="/tmp/.mount_vifm-vz4agFT"; LD_LIBRARY_PATH="$APPDIR/usr/lib:$LD_LIBRARY_PATH" $APPDIR/usr/bin/vifm

There are no such delays when :$LD_LIBRARY_PATH is omitted:

APPDIR="/tmp/.mount_vifm-vz4agFT"; LD_LIBRARY_PATH="$APPDIR/usr/lib" $APPDIR/usr/bin/vifm

I'm not sure why my system behaves like this. I've made quite a few modifications, so it isn't a vanilla Linux Mint 22.1 installation.

by

Great, thank you, now we know that $LD_LIBRARY_PATH should be modified a bit more carefully, even if we don't really know why. I didn't want to drop it completely because it may be necessary for some future release.

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.

Categories

Related questions

Snow Theme by Q2A Market
Powered by Question2Answer
...