search

walles / moar

Moar is a pager. It's designed to just do the right thing without any configuration.
Other
587 stars 17 forks source link

Arrow key navigation in moar stomped by atuin #138

Closed mmindenhall closed 1 year ago

mmindenhall commented 1 year ago

Hello,

I'm seeing a very strange and unexpected interaction between atuin and moar within my CLI environment. I reported an atuin issue, but wanted to report here as well.

Here's what happens.

  1. I have both atuin and moar configured in my ZSH environment
  2. In a new terminal window, I can use the up/down arrow keys to navigate up and down through paged content one line at a time, and the left/right arrow keys to page across when invoking moar any of the following ways:
    1. directly (moar README.md)
    2. as configured PAGER
    3. as configured MANPAGER
    4. as an alias for more
  3. In the new terminal, when I hit ctrl-r (mapped to atuin), I see the atuin history search interface in the terminal window. I can search for a previous command, or simply hit esc to dismiss.
  4. For any subsequent use of moar in the same terminal window, I can no longer navigate through paged content using the arrow keys.
  5. This side effect seems to only affect moar. If I try to page the same file using the built-in more or less tools, the arrow keys still work.

@walles, are you aware of anything that atuin might be doing within the shell environment that could explain this strange side effect in moar?

How to reproduce

After following the installation instructions for atuin, I'm enabling it in my .zshrc:

eval "$(atuin init zsh --disable-up-arrow)"

I also have the following environment variables defined to use moar as my pager and manpager:

export PAGER="/opt/homebrew/bin/moar --style vulcan"
export MANPAGER="/opt/homebrew/bin/moar --style vulcan"

I have created an alias for more:

alias more="$(brew --prefix)/bin/moar --style vulcan"
walles commented 1 year ago

I suggest you try running moar with --trace both inside and outside of atuin and try to repro the issue.

Then check what the difference is in the two logs presented by moar.

Pressing down arrow will be logged as Handling key event 5..., look for that to see whether moar even gets the arrow events after atuin is done doing its thing.

mmindenhall commented 1 year ago

Hi @walles,

I ran moar --trace README.md in a new terminal window, before and after invoking the atuin search UI. Atuin is changing the key event/sequence for the arrow keys. In each case, I did the following:

Here are the results.

New terminal before atuin

$ moar --trace README.md
Please post the following report at <https://github.com/walles/moar/issues>,
or e-mail it to johan.walles@gmail.com.

Version: v1.15.1
LANG   : en_US.UTF-8
TERM   : xterm-256color

GOOS    : darwin
GOARCH  : arm64
Compiler: gc
NumCPU  : 10

DEBU[0000] Stream read in 0ms
TRAC[0000] Pager starting
TRAC[0000] Reader done, no filter
TRAC[0000] Reader done, contents explicitly set
TRAC[0000] Highlighting done
TRAC[0001] ttyin high watermark bumped to 3 bytes
TRAC[0001] Handling key event 5...
TRAC[0001] Handling key event 5...
TRAC[0001] Handling key event 5...
TRAC[0001] Handling key event 5...
TRAC[0002] Handling key event 5...
TRAC[0002] Handling key event 4...
TRAC[0003] Handling key event 4...
TRAC[0003] Handling key event 4...
TRAC[0003] Handling key event 4...
TRAC[0003] Handling key event 4...
TRAC[0004] Handling key event 6...
TRAC[0004] Handling key event 6...
TRAC[0004] Handling key event 6...
TRAC[0005] Handling key event 7...
TRAC[0005] Handling key event 7...
TRAC[0005] Handling key event 7...
TRAC[0008] Handling rune event 'q'/0x0071...
TRAC[0008] Pager done

Same terminal, after atuin

$ moar --trace README.md
DEBU[0000] Counted 88 lines in 0ms at 102ns/line
DEBU[0000] Stream read in 0ms
TRAC[0000] Reader done, no filter
Please post the following report at <https://github.com/walles/moar/issues>,
or e-mail it to johan.walles@gmail.com.

Version: v1.15.1
LANG   : en_US.UTF-8
TERM   : xterm-256color

GOOS    : darwin
GOARCH  : arm64
Compiler: gc
NumCPU  : 10

TRAC[0000] Pager starting
TRAC[0000] Reader done, contents explicitly set
TRAC[0000] Highlighting done
TRAC[0001] ttyin high watermark bumped to 3 bytes
DEBU[0001] Unhandled multi character terminal escape sequence(s): B
DEBU[0001] Unhandled multi character terminal escape sequence(s): B
DEBU[0001] Unhandled multi character terminal escape sequence(s): B
DEBU[0001] Unhandled multi character terminal escape sequence(s): B
DEBU[0001] Unhandled multi character terminal escape sequence(s): B
DEBU[0002] Unhandled multi character terminal escape sequence(s): A
DEBU[0002] Unhandled multi character terminal escape sequence(s): A
DEBU[0002] Unhandled multi character terminal escape sequence(s): A
DEBU[0002] Unhandled multi character terminal escape sequence(s): A
DEBU[0003] Unhandled multi character terminal escape sequence(s): A
DEBU[0004] Unhandled multi character terminal escape sequence(s): C
DEBU[0004] Unhandled multi character terminal escape sequence(s): C
DEBU[0004] Unhandled multi character terminal escape sequence(s): C
DEBU[0005] Unhandled multi character terminal escape sequence(s): D
DEBU[0005] Unhandled multi character terminal escape sequence(s): D
DEBU[0005] Unhandled multi character terminal escape sequence(s): D
TRAC[0006] Handling rune event 'q'/0x0071...
TRAC[0006] Pager done

I don't understand what side effect atuin is having that causes this problem, but it's notable that moar is the only tool (so far) that is affected. This makes me wonder whether the key event mapping/subscription in moar could be extended to include these "Unhandled multi character terminal escape sequence(s)"?

walles commented 1 year ago

Hi! Can you try again with this binary?

moar.gz

It's the latest release exactly with only 6abe5ba and 15a90f5f77644 applied to it. That should make the Unhandled multi character printouts actionable for me.

Right now, when the printout says B, it really means <ESC>somethingBmaybesomethingelse, but the ESC character gets eaten by your terminal so I can't know what really happened here.

I think these are the sequences we should be getting, but that's apparently not what's happening: https://github.com/walles/moar/blob/6abe5ba1b138108478118f360c47324f40df515e/twin/keys.go#L49-L52

mmindenhall commented 1 year ago

OK, here's what I get with that binary after running atuin.

$ ~/tmp/moar --trace README.md
DEBU[0000] Counted 88 lines in 0ms at 670ns/line
DEBU[0000] Stream read in 0ms
TRAC[0000] Reader done, no filter
Please post the following report at <https://github.com/walles/moar/issues>,
or e-mail it to johan.walles@gmail.com.

Version: v1.15.1-2-g15a90f5
LANG   : en_US.UTF-8
TERM   : xterm-256color

GOOS    : darwin
GOARCH  : amd64
Compiler: gc
NumCPU  : 10

TRAC[0000] Pager starting
TRAC[0000] Reader done, contents explicitly set
TRAC[0000] Highlighting done
TRAC[0000] ttyin high watermark bumped to 3 bytes
DEBU[0000] Unhandled multi character terminal escape sequence(s): {<0x1b>OB}
DEBU[0001] Unhandled multi character terminal escape sequence(s): {<0x1b>OA}
DEBU[0001] Unhandled multi character terminal escape sequence(s): {<0x1b>OC}
DEBU[0002] Unhandled multi character terminal escape sequence(s): {<0x1b>OD}
TRAC[0003] Handling rune event 'q'/0x0071...
TRAC[0003] Pager done

Also, the author of atuin responded late yesterday, and it looks like the command echoti smkx is responsible for the side-effect that is throwing things off in moar. If you use zsh, you should be able to run that command and then run moar to reproduce the behavior.

walles commented 1 year ago

Fixed by daafbcdac4cc826d670a58bf9a6f9ef495159997.