Persistence of key bindings

[dstd]

Every major release I get a broken UX due to a shortcuts change. Furthermore, when I upgraded to 3.0 I've lost my favorite feature - export to clipboard as curl command.

But I found that in 3.0 we have commands and configurable key bindings. So I could solve my issue with them. I thought that way, but I was wrong - all bindings I've updated got lost as soon as I quited.

I had a quick peek into the source code, but the only explicit initialization of the keymap I found is defaultkeys.map(self.keymap) in master.py.

Is there a way to keep the changes in key bindings between restarts, that I've missed?

[cortesi]

Hi there. Unfortunately custom key binding persistence just didn't quite make it into the 3.0 release. It's a top priority for the next release, though, and I have everything ready for us to take the next step. There are two ways we could go about this:

• A keybindings.yaml file in the config directory dedicated just to key bindings.
• A more general mechanism that lets us specify a list of commands to run on startup. This would let us then use the console.key.bind command to add custom keybindings. I think I prefer this approach, which will extend to all addons and open a bunch of other doors as well.

If you felt like digging in, I'd love a hand with this. If not, you can expect this to land in master in the coming weeks, and be out in the 4.0 release around the beginning of May.

[Kriechi]

I think a list of commands to run on startup would be very useful to further customize or automate things.

Just to spin this idea a bit further: does our current options & config file allow us to specify a a "~/.mitmproxy/startup_script.py" which is automatically loaded without manually specifying it for each mitmproxy/mitmdump invocation from the CLI?

[vfaronov]

I think a list of commands to run on startup would be very useful to further customize or automate things.

+1, but consider also a list of commands to run on shutdown. Use case: an addon that processes flows and produces a report file, like the histogram example from the docs. With mitmdump, you can’t do :myaddon.histogram @all /tmp/xxx; you have to save flows to a file and load it into mitmproxy just to invoke that command.

[vfaronov]

Just to spin this idea a bit further: does our current options & config file allow us to specify a a "~/.mitmproxy/startup_script.py" which is automatically loaded without manually specifying it for each mitmproxy/mitmdump invocation from the CLI?

Actually yes. You can write a script like this:

def load(loader):
    from mitmproxy import ctx
    ctx.master.commands.call('console.key.bind global 0 console.exit')

and list it in scripts: in your config file.

This would also work as a “shutdown script” for the use case I explained above, but for #3022.

Of course, if this approach is to be the designated solution for keybindings persistence, it needs to be documented.

[cortesi]

I've been pondering this, and I've concluded that we need a dedicated file to define key bindings (and actions #2718). I think specifying commands to all the tools for startup and shutdown will be invaluable, but is a separate feature.

Here's my rationale:

• The command mechanism for binding keys is flexible and useful, but can also be verbose and difficult to use. I feel an expanded syntax is required for the config file.
• Imagine a user starting mitmproxy, making binding a key, and then saving the result to file. We want to be able to save just the delta, just like we currently do with options. We can't do this with a list of startup commands, since the key binding that results from a command can only be established by executing the command (commands can be compound, and there's nothing stopping any parameter in a command binding a key from being dynamic).
• Key bindings and console commands will soon be extended to include help and prompt alternatives. This is going to make a pure-command format much too verbose (unless we have significant changes to the command format).

[cortesi]

See #3109 for a first draft of key binding persistence. The short version is that we now have a ~/.mitmproxy/keys.yaml file that can contain user keybindings, and is loaded on startup. We also have a corresponding command for loading keys at runtime from file. We don't support (and might never support) saving of dynamically bound keys to file yet - you have to edit the file by hand.

Please take a look at the patch, or sit tight for documentation and examples that will land in the next few days.

[cortesi]

I'll close this ticket, and we can discuss any issues in more specific tickets.