Shit+selection does not work under rxvt-unicode

[etosan]

When using rxvt-unicde, edit cannot work with shift modifiers, home and end keys, etc to select text and navigate cursor. This work fine in nano, vim, dex and others.

[lhecker]

This project does not use ncurses, because this project's first and foremost target platform is Windows where that doesn't exist. At this point in the project, we don't have the capacity to make every terminal work and the focus on Linux is on the terminals that the maintainers use (which is primarily just me, and I only use KDE Konsole). Patches are very welcome, if they're minimal.

[lhecker]

Well, I checked it out in WSL real quick. Pressing Shift+Left/Right in Windows Terminal:

$ showkey -a
^[[1;2D  27 0033 0x1b
         91 0133 0x5b
         49 0061 0x31
         59 0073 0x3b
         50 0062 0x32
         68 0104 0x44
^[[1;2C  27 0033 0x1b
         91 0133 0x5b
         49 0061 0x31
         59 0073 0x3b
         50 0062 0x32
         67 0103 0x43

In urxvt:

$ showkey -a
^[[d     27 0033 0x1b
         91 0133 0x5b
        100 0144 0x64
^[[c     27 0033 0x1b
         91 0133 0x5b
         99 0143 0x63

In short, urxvt doesn't use the modern xterm style encoding for these keys. That's not really an issue I want to fix on our side. I'd rather have terminals mostly agree on their keyboard encoding.

[lhecker]

If you scroll to the end here, you can find a list of keybindings: https://vim.fandom.com/wiki/Get_Alt_key_to_work_in_terminal

I'm considering closing this issue as I don't plan to change it at the moment.

[etosan]

Ah I kinda see your reasoning and willing to keep stuff minimal.

Unfortunately the terminal configuration system on any unix is a fact of life. Trust me we don't like it, but it is what it is.

Terminals were always designed with "progressive enhancement" in mind (as web guys call it) so even if something is like 25% is wrong, but the crucial features work, it somehow works for user (with annoyances of course). But we can all agree, letting it sort itself out, that it is not a proper handling of the issue at hand.

First so that we all understand situation better, let's revise and hopefully agree on following facts:

• from basic point of view of normal terminal application terminal is "just" a file/pipe, one pipe for each std stream.
• any terminal then supports two methods for advanced communication with the terminal handler/emulator/real terminal:
  • out-of-stream ioctl() syscalls for setting up various extra parameters
  • and in-stream escape sequences
• standard terminal emulator, just like real terminal, simulates both
  • ioctl()s are being handled in each terminal based on OS (pty driver) capabilities, and are rather standardized (by platform), and most of these commands are, in fact, tangential to the editor
  • escape sequences on the other hand can differ wildly among terminal emulators and affect editors greatly
    • there are two ways of handling those:
      • hardcode them in editor (kinda works and is minimal, but eventually ends up flaky as the project and usage grows)
      • use platform provided terminal configuration (this is what most well behaved editors do)

Regarding to writing terminal applications there are then two library layers:

• upper, application level, "drawing lib" - often ncurses, curses, readline and myriad of others
  • this is what you have in mind, probably, when speaking of not using *curses
  • this "ncurses" reads the lower, system layer (terminfo), itself, to probe for terminal capabilities
• lower, system level library, handling terminal configuration database temininfo/termcap
  • this is what reads TERM= env variable and acts accordingly
  • this encodes all the "advanced" terminal capabilities that terminal can provide
  • on bsd systems this is traditionally termcap (but if I am not mistaken, termcap provides terminfo emulation on bsds)
  • on linux (and many other systems) this is traditionally terminfo

So with that behind us, now we can back to question of msedit target.

I don't understand rust (and haven't read the code yet), but you guys are essentially saying that you are handling escape sequences by hand in the msedit editor mainloop?

Okay, I did that myself back in the day, and his might work as fallback, but I believe IT WILL eventually bite you back.

And as I have never seen TERM setting related to "Windows Terminal" in the wild, only thing is to assume, that "Windows Terminal" guys emulate xterm sequence handling best they can, and since TERM= is set to xterm by default on many distros, and many console tools assume xterm if nothing is set, this just "works". Somehow.

putty which is similarly "broken", kinda "works" this way too. Until it doesn't.

Unfortunately I have to inform you, this approach IS WRONG and often leads to bigger problems down the road. As your editor will get more and more popular (because it is really pretty good and sane(!) - compared to for example nano) more and more annoying people like me will pop up and will be bickering that they terminal does not work.

I am not saying you should switch to ncurses now, but I implore you guys to just look into basic terminfo support.

As terminfo db is provided by OS itself, and terminfo library also handles capabilities database and dispatch based on TERM variable automatically, this should be enough for you to get data needed for given sequences on current terminal emulator.

As I say, I have no idea how rust works, but there already seems to be terminfo library support in rust (https://docs.rs/terminfo/latest/terminfo/), so this ability to load sequences form there could perhaps be added to the editor cheaply.

Don't get me wrong, and don't take this as rant or attack, I really love your editor, especially for normal linux users and linux neophytes coming from windows to linux. This is great little and VERY USABLE toy, but I really implore you to look at least into the terminfo support, especially to prevent future issues.

This database is also what makes users pick between terminal emulators, based on their capabilities. I many users pick kitty or alacritty because of advanced features and terminfo database encodes the difference between them.

[lhecker]

Terminals were always designed with "progressive enhancement" in mind (as web guys call it) so [...] [...]

For what it's worth, I do maintain Windows Terminal as well, so I'm somewhat familiar with the terminal world at this point, including on NIX platforms.

First so that we all understand situation better, let's revise and hopefully agree on following facts: [...] use platform provided terminal configuration (this is what most well behaved editors do)

You're right about this.

However, as I stated before, the main target of this project at this time is Windows where ncurses, terminfo, and termcap don't natively exist. Supporting multiple implementations is additional work. So, with my limited time on this project, I cannot make this a high priority issue at this time. I'd rather work on adding e.g. syntax highlighting instead which I'm certain people also want.

I don't understand rust (and haven't read the code yet), but you guys are essentially saying that you are handling escape sequences by hand in the msedit editor mainloop?

Yep.

And as I have never seen TERM setting related to "Windows Terminal" in the wild, only thing is to assume, that "Windows Terminal" guys emulate xterm sequence handling best they can [...]

It's rather nitpicky to say this, but technically everyone except for xterm, who support xterm sequences, emulate the behavior of those sequences. Thanks to the amazing work of j4james and many other contributors I think that Windows Terminal is doing a rather good job in that regard at this point. (I realize that this is entirely besides your point.)

I am not saying you should switch to ncurses now, but I implore you guys to just look into basic terminfo support.

That's not necessarily a suggestion I'm against, to be clear. I am hesitant, however, because I'm trying to keep the binary size low and balance my priorities. If someone were to submit a PR that adds support for terminfo lookups, I would measure its binary size impact, and if it's low, possibly merge it. (This makes it unlikely that a "crate" (a statically linked dependency) would work out.)

---

With all that said, reading the above fandom article, it says:

I gave up to fix Alt-mapping using vim's facilities and remaped keys I need using xterm resources. [...] I followed sergey's approach of configuring URxvt through Xdefaults because Vim's key reassignment facilities simply did not work [...]

This makes it sound like other venerable editors also struggle with urxvt, so I'm, again, not sure if this issue deserves to be a higher priority (given my constraints).