[Pkg-zsh-devel] [PATCH 6/6] Try to bind <mod>-<cursor>

[Frank Terbeck]

Axel Beckert wrote:
> Frank Terbeck wrote:
>> Frank Terbeck wrote:
>> > First via terminfo, then at best effort.
>> [...]
>> > +    bindbesteffort S-Left  $'\e[1;2D' $'\e[d'   backward-word vi-backward-word
>> [...]
>> > +    bindbesteffort S-Right $'\e[1;2C' $'\e[c'   forward-word  vi-forward-word
>> 
>> This would probably fix #536459.
>
> IIRC you said on IRC that xterm would be the only one where some
> feature is announced via terminfo that would not cause this issue.

The only one I know off hand. ;)

> But I use xterm (uxterm actually, not sure if that makes a
> difference) and still have that issue, so I'm wondering why.

`uxterm' is just a wrapper shell script around `xterm' that enforces a
UTF-8 locale. So the terminfo entry is the same ($TERM should be "xterm"
or "xterm-256color" in both xterm and uxterm).

>> But as I said on IRC, I'm not sure we want to own this Pandora's
>> box. If it were possible to get the information for a decent
>> number of terminals, then why not. But that's not the case. And I
>> hate guessing...
>
> I don't think we should do the guessing thing / open pandora's box,
> but if it's supposed to work out-of-the-box on some specific terminal
> implementations and it doesn't, we should have a look. :-)

It's not "supposed" to work. It's not zsh default behaviour.

Some people expect it to work, because some other applications allow
that to work.

If we were to do this, we might as well do it with a giant "case...
esac" that covers a set of well known terminals. People have done this
in the past, so we could probably "borrow" the necessary code from
someone (I think our very own RichiH does something along those lines in
his zshrc).

That wouldn't rely on "terminfo" at all so it could break in the future
if the sequences chance for - say - xterm. But that's probably unlikely.


That all being said: I still think we should stay away from it.

Regards, Frank