This is my first time joining a discussion, I had a hard time just to
open an account and send my suggestion. I use the default reply
function and I don't mean to upset anyone. Hopefull now this reply is
well-edited (I removed the quote).
Yes, it was a much better reply, thanks, Stephen. And welcome to the
list. You picked a good lively discussion to get involved in!
How about checking the Scan Codes directly?
<Enter> = 1c 9c
<L-CTRL> = 1d 9d
<M> = 32 b2
<Tab> = 0f 8f
<L-CTRL> = 1d 9d
<I> = 17 97
We should be able to do it at a higher level than this, and avoid having
to deal with scan-code -> character mapping. Also, scan codes simply
aren't available when running in terminal mode. Every GUI will be
different, and different terminals will need different handling, but we
should be able to get something structured from the OS/window
manager/terminal which details the key pressed and its modifiers. I
don't think this part of things will be a problem. And since translation
from the GUI-specific form to Vim internal form will happen very
quickly, efficiency won't be an issue here either.
About Paul's type:
Tab { 1, 0, KEY_TAB }
Ctrl-I { 0, MOD_CTRL, 'i' }
Ctrl-Shift-I { 0, MOD_CTRL, 'I' }
I see is a switch type setting, it should work and require less
changes but I really don't know how to differentiate if it is
systemwise that<Tab> and<CTRL-I> gives the same 0x09.
GUIs should be able to get the information, and some terminals (e.g. via
libtermkey as has been discussed in another part of the thread).
The trouble with the structure is that it is big, and contrary to the
original assumption, it't not really useful to restrict its use to the
input queue. We need a solution that will work in other parts of Vim
efficiently--maybe a byte-stream solution, maybe an escape character
followed by a packed structure, maybe something we haven't thought of
yet. I think the byte-stream method will work well, and is closest to
what Vim already does so least work.
Also about your question:
When there is one. Or a codepoint in some encoding. Yeah, your struct
does allow for that. The struct isn't inexpressive, it's just that it's
big, and if it needs to be used in a LOT of places (which seem to just
be increasing...input queue, mappings, registers, strings, buffers?!),
suddenly not just one thing is getting a bit bigger--a lot of things are
getting bigger--potentially a lot bigger! If every time you yank text
into a register it gets 12 times larger, that may cause some problems!
Is it possilbe to swap those registers and histories onto hard disk so
as to control the memory size? It has advantages of large capacity,
infinite undo, and can be called to check the complete list.
It's not out of the question, but it would require significant changes
to a lot of Vim, I think, and is not what really how you would expect
them to work. Also, a massive chunk of disk space isn't all that much an
improvement than a massive chunk of main memory!
Cheers,
Ben.
--
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
