search

martanne / vis

A vi-like editor based on Plan 9's structural regular expressions
Other
4.25k stars 258 forks source link

Home and end keys not working with tmux #931

Closed Ro5bert closed 3 years ago

Ro5bert commented 3 years ago

In tmux running in gnome terminal (TERM="screen-256color"), my home and end keys seem to generate \033[1~ and \033[4~, respectively. In this case, both home and end do nothing in normal mode, and they write <Find> and <Select> in insert mode.

In xterm (TERM="xterm"), my home and end keys generate \033[H and \033[F, and they work as expected in vis.

Is this an issue on my end? Or is this an issue with vis? My home and end keys work fine in other contexts, including in nvim.

Ro5bert commented 3 years ago

I configured things to be fixterms compatible and it's now working.

Strahinja commented 2 years ago

@Ro5bert It would be most beneficial for all the users of vis if you shared in detail how exactly you solved this issue.

Ro5bert commented 2 years ago

@Strahinja The issue was with my terminal, not with vis. Vis uses the fixterms terminal key encodings, which specifies that Home (resp., End) should be encoded as \033[7~ (resp., \033[8~) or \033[H (resp., \033[F). If your terminal does not use one of these encodings, you'll need to change it somehow. For st users, it suffices to change the appropriate entries of the key table in config.h and the khome and kend capabilities in st.info (see terminfo(5)).

Incidentally, the default st fails to be fixterms-compatible for other reasons. There is a patch that tries to add fixterms support, but I found it to be buggy/incomplete; in particular, it does not handle modified non-Latin1 Unicode correctly, which requires changes beyond editing the key table. As such, I pretty much rewrote all of st keyboard input handling. My fork of st is now quite different from the original st, but if you (or anyone reading this) happens to use st, let me know and I could dig through git history and try to produce a patch that will apply to the default st.

Strahinja commented 2 years ago

I ran into this issue in my custom musl-based distro, but running in a text console (tty). It is using netbsd-curses as well.

Ro5bert commented 2 years ago

@Strahinja I also have this issue in the linux tty, but it doesn't bother me much, so I haven't fixed it there. You could probably fix it by making a fixterms-compatible console keymap and loading it with loadkeys(1) (see keymaps(5)).

Strahinja commented 2 years ago

Yes, that would probably be the way of solving this in tty.

Interestingly enough, I don't have this issue in st + tmux in Artix Linux. I use TERM=tmux-256color, and patches I have applied so far include:

I can enter, for example, Cyrillic text in vis under tmux + st in X.Org without problems and pressing Home and End in both insert and normal modes positions the cursor to the beginning and end of line respectively. I also tested without tmux (just st under X.Org), with the same result. I use bare X.Org without any DE or DM, started from getty with startx in $HOME/.profile.

Ro5bert commented 2 years ago

That's strange. libtermkey claims to "follow[] terminfo for every sequence listed there, only falling back on other methods to deal with unrecognised input", meaning it should find the correct Home/End sequences regardless of whether the terminal in use claims to be fully fixterms-compatible, so maybe this is actually a bug in libtermkey.