Multiple exec commands

[rprospero]

One feature that would be quite useful would be allowing for multiple exec commands. I've repeatedly found myself in a pattern where I run swayimg twice on the same set of images to take advantage of different exec commands on each pass through. It would be very convent if I could bind a second (or more) command to a different key and make only a single pass, performing the correct action on each image.

I'm not opposed to putting together a PR that adds the functionality, but I didn't know

• would this functionality be welcome?
• what would the second exec command be named in the config file? I would probably just call it exec2. but I'm bad at naming things.
• similarly, what would be the name for the key binding? Should there be a default binding for the auxiliary action?
• How many actions should be allow? A primary and auxiliary action would already be a great improvement, but one could also imagine exec2 through exec9. Indeed, allowing an arbitrary/unbounded number of commands feels rewarding, but also likely requires greater changes to the code.

[artemsen]

Yes, I am sure this feature would be useful.
But I don't think we should limit the number of exec at all.
I would store commands like this:

[keys]
e = exec("rm %")
f = exec("mv % ../dir/$(basename %)")

I need to refactor the config handler code to support this feature.
But this will also resolve #81 =)

[MahouShoujoMivutilde]

I guess it depends whether you prefer to have a prefix key, but wouldn't nsxiv-like approach be better?

Basically, one exec, that also passes the next pressed key after it's been triggered and the current file to a given shell script.

So instead of a bunch of single key bindings you have a sort-of mode (like in vim), allowing you to potentially bind already used keys.

[artemsen]

I guess it depends whether you prefer to have a prefix key, but wouldn't nsxiv-like approach be better?

To be honest, I don't like this way. The key is passed in arguments, but the path is on stdin stream. Maybe I'm missing something, but it looks strange =)

Basically, one exec, that also passes the next pressed key after it's been triggered and the current file to a given shell script.

So, we will have one script for all operations and this script will be very swayimg-specific. It's not just a call to rm, the script should parse all input arguments, including key specifiers.

So instead of a bunch of single key bindings you have a sort-of mode (like in vim), allowing you to potentially bind already used keys.

You can already rebind any existing key.

[MahouShoujoMivutilde]

To be honest, I don't like this way.

Fair enough.

It's designed like this because in nsxiv you can mark multiple files and then run this script on all the selected files.

(e.g. useful for rotating multiple photos)

So, we will have one script for all operations and this script will be very swayimg-specific

Well, yeah.

You can already rebind any existing key.

Yes, but the point is with a script like that you can have

n = next_file
e = exec
# and keybinding `en` (e -> n) availible for something else inside the script.

[artemsen]

Oh, I get it. It's similar to <Leader> mappings in vim.
The script is something like a plugin with the specific interface.
I think it's difficult for the end user to use =)
It's easier to implement and support the exec(cmd) scheme.