On Mon, 06 Oct 2014 18:11:19 +0200 Bram Moolenaar <[email protected]> wrote:
> We could do something for the GUI, I thought there was a todo item for > that already. Can't find it now... The idea basically is that when > Tab and CTRL-I are both mapped, they will be considered to be > different. This is required for existing mappings to keep working. > It will still break when someone tries to overrule a mapping for Tab > with a mapping for CTRL-I though. Hopefully that doesn't happen very > often. That sounds like an excellent first step. Doubly-so would be if, even on a terminal, I could write one of my many hacky 'map the byte sequences' fixes, to teach vim how to read the incoming keypresses. I.e. if I could then :map ^[[105;5u <Ctrl-i> :map ^[[73;5u <Ctrl-I> then at least vim would recognise that I had typed a Ctrl-i, instead of undoing my last 5 changes. I mean, I could write that map right this very second, but without the feature named above I'd have nothing to map it /to/ on the RHS. On a more general note though, I find the idea of using :map on byte sequences to teach vim about new keypresses that aren't programmed in to be unsatisfactory. It gets upset with timing, and it doesn't apply during 'paste mode. Would it be possible to define a more robust mechanism for doing these kinds of fixes? -- Paul "LeoNerd" Evans [email protected] http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS
signature.asc
Description: PGP signature
