`commandline -f` ops reordered with respect to other commandline operations

[laughedelic]

I observe strange behaviour regarding the execution order of commandline calls with -f option and without.

Example: I define the following function and bind it to a ctrls:

function __surround
    commandline -f backward-kill-path-component
    commandline -i '"'
    commandline -f yank
    commandline -a '"'
end

bind \cs '__surround'

(in my fish_user_key_bindings.fish)

What happens instead:

• cut + paste (those with -f)
• insert + append

Here is a demo: asciicast

This is just a simplified example, I have encountered this behaviour in more situations and if this is not enough, I can provide more examples.

---

• Fish version: fish, version 2.3b2 (homebrew install --devel fish)
• Operating system: OS X El Capitan
• Terminal emulator: iTerm2

[krader1961]

That's because commandline -f pushes the function into the reader input queue. Those functions aren't actually executed until your function returns and the input reader runs again. The commandline -i and commandline -a on the other hand immediately modify the buffer. This causes the operations to be reordered as you noticed. This is not intuitive and quite annoying. I could have sworn there was an open issue discussing this but I can't find it.

This behavior is technically not a bug since fish is working as intended. Nonetheless, I think the behavior should be changed. Relabeling this an enhancement since I can't find the issue I thought was already open to change this behavior.

[laughedelic]

@krader1961 thanks for the explanation. Now I see, that -i/-a commands get actually executed first. Is there any way to overcome this? Or better just not to mix -f options with other ones?

Probably this closed issue is related: #1567

[krader1961]

Is there any way to overcome this?

Not that I'm aware of without changing the core code. It's not a general solution but for the example you gave in the original problem statement simply fetch the command line (commandline), mutate it however you want, then replace the command line with your mutated version (commandline -r).

[laughedelic]

fetch the command line (commandline), mutate it however you want, then replace

That's what I was doing so far. I just thought that it might be not effective.

[zanchey]

See #1567.

[laughedelic]

@zanchey do you mean something in particular? I referenced this issue in another comment, but it doesn't help much.

[faho]

@laughedelic: That changed it from a stack (which would mean all your stuff is interpreted in reverse) to a queue.

That was another notable time this behavior was touched, so it's important for any further changes (so as not to regress, etc). The comment wasn't for you in particular.

[zx8]

Sorry to dig up an ancient issue, but I've just been hit by this again in #5979 (comment) and was wondering if any of the recent work @ridiculousfish is doing around parsers/threading will affect this at all, or perhaps make it easier to implement in future?

I'm sure there's a good reason commandline -f is currently the way it is, but the current behaviour is very unintuitive and often stills surprises me when writing scripts (and I consider myself a relatively seasoned fish user).

As programmers, unless some sort of special syntax is involved, we're used to things being executed sequentially in scripting languages, and often taking effect immediately, which makes this particular nuance all the more surprising.

Is it safe to assume that since this issue is still open that there's intent to change (/fix) this one day?

[ridiculousfish]

No this won't be affected by any threading changes.

We're certainly open to a fix for this.