Some message types are handled after other message types, regardless of input order.

[LyxHuston]

When passing messages to xplr from the command line through the -m flag, the order I pass in messages does not have any effect on execution order.

For a minimal example, try calling a custom function that changes some state based on the current vroot, then setting the vroot.

local past_vroot = nil

xplr.fn.log_vroot = function (app)
    past_vroot = app.vroot
end

... some sort of code that changes the dispplay based on `past_vroot`

note: It seems like lua functions that are called this way have their return messages ignored?

xplr -m "CallLua: log_vroot"
xplr -m "SetVroot: /arbitrary/path"

However, it will always set the vroot first, then call the lua function. The same happens if they are in reverse order.

I have also tried:

xplr -m "CallLua: log_vroot" -m "SetVroot: /arbitrary/path"
# error: xplr -m: too many positional values, not enough positional placeholders
xplr -m "CallLua: log_vroot"
xplr -m "Refresh"
xplr -m "SetVroot: /arbitrary/path"
# no difference
xplr -m "CallLua: log_vroot"
sleep 5
xplr -m "SetVroot: /arbitrary/path"
# no difference
xplr -m "[CallLua: log_vroot, SetVroot: /arbitrary/path]"
xplr -m "[{CallLua: log_vroot}, {SetVroot: /arbitrary/path}]"
xplr -m "{{CallLua: log_vroot}, {SetVroot: /arbitrary/path}}"
# all various parsing errors
xplr -m "0: [CallLua: log_vroot, SetVroot: /arbitrary/path]"
# expected error on using incorrect form

and a few other variations. It seems there is no reliable way to control input order of messages.

[LyxHuston]

It seems internally a few messages are handled by adding them to an internal Deque (App.msg_out) which causes this weird execution order issue. I see why (they're all ones that require releasing the terminal, so need to be in the correct space, and so are all handled by the runner) but why not have all messages pushed to this and then handle from there?

[sayanarijit]

Hi, thanks for reporting and investigating the issue. I’m currently taking a break. Will take a look in 4-5 days.

[sayanarijit]

I have checked. It's a valid point, and has been a pain point in the past also. Yes, ideally all messages need to be in the same queue, but for that, we need to resolve some Rust's lifetime related complexities, by refactoring the code better.