Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

toggle_fullscreen setting in user config gets ignored if key is already used #91

ghost opened this issue May 5, 2012 · 1 comment


Copy link

ghost commented May 5, 2012

The following example config is stored in ${HOME}/.config/feh/keys:

save_image l
toggle_filenames f

scroll_up Up
scroll_down Down

When loading an image, and pressing f the image file name and count becomes visible and hides as expected with every key press. So it’s basically working to re-map keys without un-mapping them first (same for the two scroll commands whose keys are used for zooming in default config).

According to the documentation, the fullscreen toggle command is toggle_fullscreen and it’s mapped on v by default. Toggling fullscreen with default key works as expected.

Now I’m altering my config to this:

save_image l
toggle_fullscreen f

scroll_up Up
scroll_down Down

According to the behavior with toggle_filenames and Up/Down for scrolling, I expect toggling fullscreen when pressing f now.

Instead of toggling fullscreen the image list gets written to ${HOME}.

But if setting save_filelist before toggle_fullscreen f it works. So I have to unbind f before being able to toggle fullscreen with this key, but I don’t have to unset f before being able to display file names …

I’m not sure if this is intended behavior, but i’s inconsistent behavior.

Copy link

derf commented May 5, 2012

Yup, this is a documentation error.

When assigning a key binding, feh does not check if it is already bound somewhere else, and when handling a key press it simply walks through all available commands.
So in this case, the behaviour depends on the order in which feh checks the commands.

I'll update the documentation to note that conflicting key bindings need to be resolved by the user, thanks for pointing it out.

@derf derf closed this as completed in 9ed58f2 May 5, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant