Charles Campbell wrote: > Bram Moolenaar wrote: > > [snip] > > Then we need a way to make the extra information available to be used in > > mappings, without breaking it for users relying on the current way. > > > > Some things that are no acceptable: > > - Have a setting to enable "the new way". This will break existing > > stuff and make users pull their hair out because they don't know this > > setting exists. Forget it. > > - Change the input queue from a stream of bytes to some list of structs. > > This isn't adding any functionality and breaks all kinds of mapping > > and termcode handling, register execution, etc. Forget it. > > > > What we can do is extend the existing modifier byte sequence. This is a > > bit tricky, but it should work. So we add a new byte sequence with the > > raw key encoded, plus modifiers. Thus for CTRL-[ you get the [ key with > > the CTRL modifier. > > > [snip] > > Another way to extend this might be to switch from a byte queue to a > short integer queue. The lower 8-bits would be as it is now; the upper > eight bits would encode modifier keys (shift, ctrl, alt, meta, whatever).
The current special-key encoding is a bit clumsy. On the other hand, there are situations where the queue can get very long (recursive execution of mappings or "1000@@"). Using 16 or 32 bits for every character is not attractive. One way to solve this is to use up to 128 bit integers, making sure that the higher bits are usually zero, and then use variable length encoding. ASCII characters should then still take only one byte. http://code.google.com/apis/protocolbuffers/docs/encoding.html Nevertheless, what gets encoded in registers must still be a byte sequence. And we need to be able to store double-byte and multi-byte characters. Thus I don't think this will make things simpler. -- This is the polymorph virus! Follow these instructions carefully: 1. Send this message to everybody you know. 2. Format your harddisk. Thank you for your cooperation in spreading the most powerful virus ever! /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
