Paul LeoNerd Evans wrote:
> Exec summary:
>
> Vim doesn't parse XTerm's modified keys properly, so things like
> <Ctrl-PageDown> don't work.
>
>
> Bigger summary:
>
> XTerm has a fairly generic mechanism for sending modified keys. Keys
> like <Ctrl-PageDown>, which used not to have a representation, now do.
> To parse these properly, Vim needs a full CSI-aware parser. It cannot
> continue to live with a term{cap/info}-driven prefix parser. Fixing this
> by adding a proper CSI parser would allow Vim to recognise any of
> XTerm's modified keys. These keys allow arbitrary modifier marking of
> arbitrary cursor or function keys.
>
> -----
>
> The way XTerm represents these keys is to use the second position
> parameter of CSIs. For example, PageDown is CSI 6~, Insert is CSI 2~,
> Left is CSI D, and so on. XTerm extends this in the second parameter,
> with a 1+bitmask representation (because unmodified, the value defaults
> to being 1).
>
> CSI 1 ; 1 D <Left>
> CSI 1 ; 2 D <Shift-Left> 1=shift; 1+1=2
> CSI 1 ; 3 D <Alt-Left> 2=alt; 1+2=3
> CSI 1 ; 4 D <Shift-Alt-Left>
> CSI 1 ; 5 D <Ctrl-Left> 4=ctrl
> ...
>
> CSI 6 ; 1 ~ <PageDown>
> CSI 6 ; 2 ~ <Shift-PageDown>
> CSI 6 ; 3 ~ <Alt-PageDown>
> ...
>
> and so on
>
> Currently vim doesn't understand these, prefixes don't match, and it
> gets all confused e.g. noticing the CSI 1 ; doesn't match anything,
> stops there, sees 5D in normal mode and deletes 5 lines of your text.
>
> To fix this, Vim needs to acquire a proper CSI parser. This would be
> able to pull out the arguments from the sequences, and apply them
> accordingly.
>
> This has to be a real parser, not just string prefix matching.
>
> 1: Because the orthoginallity of the mappings leads it to easily handle
> more cases.. E.g. if a new modifier <Super-> is ever defined, say,
> with a bitmask of 8, then just adding that one case to the parser
> allows any modified key to use it.
>
> 2: Because these sequences have meaning, they're not just opaque
> strings. See ECMA-48.
> Specifically, these all mean the same thing
>
> CSI 1 ; 3 D
> CSI 001 ; 03 D
> CSI 001 ; 03 ; D
>
> Having a real parser in Vim would make the scheme much more
> futureproof - the whole reason it breaks currently is the prefix
> mapping. (Other applications e.g. irssi and readline do the same
> thing). A proper parser could pull out all the parameters as decimal
> numbers, and treat them properly. If one day a meaning is defined
> for the third parameter, say, when everyone has pressure sensitive
> keyboards that report a force, Vim can still cope with the new
> sequences even if it doesn't understand them. By the same token, a
> CSI parser that doesn't know about the modifiers would have just
> ignored their presence, rather than giving up entirely.
>
>
>
> I don't know the internals of Vim, but suggestion on #vim/Freenode said
> that it doesn't have an internal representation of modified keys.
>
> To fix this issue reallyproperly, and do nice things with GUI Vim as
> well, I might suggest that keys be allowed to live in a struct something
> like:
>
>
> struct keypress {
> int codepoint; // For normal keys
> enum specialkey specialkey; // For cursor keys, function keys, etc..
>
> int is_shift:1;
> int is_alt:1;
> int is_ctrl:1;
> ...
> };
>
> XTerm has plans for making arbitrary keys arbitrarily modifyable - it
> would be great if Vim could :map any of these.
Did you check :help xterm-modifier-keys ?
What version of Vim are you talking about?
--
If you don't get everything you want, think of
everything you didn't get and don't want.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
