Lf: Push command behaving weirdly

[Jirixek]

Suppose I have command for renaming files from the front:
cmd rename_front &lf -remote "send $id push :rename<enter><home>"
This works in some cases, but sometimes (maybe 1 in the 10 times), <home> executes before <enter>. As a result, the cursor moves to the top of the page and you are only executing :rename<enter>. I know I could rewrite the command to use rename directly, but I think this should not happen. Also some of my other commands are affected.

[gokcehan]

@Jirixek Just to be clear, for this case you wouldn't need remote commands and push. The following should work:

cmd rename_front :rename; cmd-home

Or you can assign this directly to a key:

map R :rename; cmd-home

What other commands do you have problems with? Does it have something to do with remote commands or the push command?

[Jirixek]

I rewrote most of my commands so they don't use push, and if they do, it do so in a series (as in example below). Currently none of my commands are affected, but I think this behavior should be dealt with. I've attached an example where you have to use push and sometimes <left> executes before <enter>.

cmd rename_edit &{{
    if [ -n "$fs" ]
    then
        # Bulkrename
        lf -remote "send $id rename_bulk"
    elif [ -f "$f" ]
    then
        # File
        filename="${f##*/}"         # Get basename of the selection
        extension="${filename##*.}" # Get extension only

        # If file doesn't have any extension, handle normally
        [ "$extension" = "$filename" ] && \
            lf -remote "send $id rename" && exit

        lefts="$(printf '%0.s<left>' $(seq 0 "${#extension}"))"

        # Command below works as expected:
        # lf -remote "send $id rename"$'\n'"send $id push $lefts"

        # Command below is behaving weirdly:
        lf -remote "send $id push :rename<enter>$lefts"
    else
        # Other
        lf -remote "send $id rename"
    fi
}}

[gokcehan]

@Jirixek You're right this should not happen. I'm now able to reproduce the issue with:

map a push :rename<enter><home>

Marking this as a bug.

[Jirixek]

@gokcehan Also in my rewriting of remotes to not use push, I came across another weird issue which might be able to help you.
The command below appears to be working fine,

lf -remote "send $id :rename; cmd-delete-home"$'\n'"send $id push .$extension<home>"

but slightly modified command that use cmd-home instead of <home> inserts $extension with garbled characters in about 50% of the time:

lf -remote "send $id :rename; cmd-delete-home"$'\n'"send $id push .$extension"$'\n'"send $id cmd-home"

I'll attach full script:

cmd rename_clear &{{
    if [ -n "$fs" ]
    then
        # Bulkrename
        lf -remote "send $id rename_bulk"
    elif [ -f "$f" ]
    then
        # File
        filename="${f##*/}"                     # Get basename of the selection
        extension="${filename##*.}"             # Get extension only

        # If file doesn't have any extension, clear all
        [ "$extension" = "$filename" ] && \
            lf -remote "send $id rename_clear_all" && exit

        extension="$(printf '%q' "$extension")" # Escape bash sequences
        extension="${extension//\\ /<space>}"
        # Fine
        lf -remote "send $id :rename; cmd-delete-home"$'\n'"send $id push .$extension<home>"
        # Weird
        # lf -remote "send $id :rename; cmd-delete-home"$'\n'"send $id push .$extension"$'\n'"send $id cmd-home"
    else
        # Other
        lf -remote "send $id rename_clear_all"
    fi
}}

[BachoSeven]

I think I have been having an issue which is related to this:

I have a custom-defined command :

cmd mkdir $mkdir -p "$(echo $* | tr ' ' '\ ')"

I then map this using the push command:

map o push :mkdir<space>

The issue is that sometimes pressing o to call the mapping does the following:

• clearly runs the mapping for m (i.e. the first letter of mkdir), which executes a program(in my case m launches the file under cursor in w3m); and then when the process
  spawned from m is completed I find that the shell has :kdir written in it.

• This does not depend on whether m is actually mapped to anything, I had this issue also by seeing unknown mapping: m.

• This behaviour is not consistent, and I cannot really figure out when it is most likely to happen, but I have had it for a while now so I though I would mention it.

[gokcehan]

@BachoSeven Are you using version r16 or build master from the source? We have just landed the port from termbox to tcell a few days ago, and there have been changes to the input handling. I realized regular keys in push commands were not working. I have pushed a fix for that now. There are some missing special keys including <space> to test the examples mentioned here. I will go over the keys and then test these examples. There is a chance that this issue might have resolved on its own with the new tcell port.

[BachoSeven]

I will try master and let you know if I experience it. It does not happen always so I can't know right away.

[gokcehan]

@BachoSeven Don't bother to try it, the issue is still there. I understand why it happens. We're reading events in a separate goroutine, and when there are multiple keys in the queue, as in push commands, it's possible to read a cmd event as a regular event and vica verse, since the global mode has not changed yet during reading. I don't know how to solve it in an easy manner yet.

[gokcehan]

I have now pushed a patch to do event reading in the main loop so that mode changing push commands as discussed here should behave as intended. I have also went ahead and implemented a lazy drawing approach which has been bugging me for a while. This way ui drawing is held until the event queue is empty so that commands like push and copy pasting text into the prompt should feel instantaneous.

I have been testing this for a while and I haven't experienced this bug so far. I'm closing this issue now. Feel free to report further issues here if you have.