On Thu, Feb 17, 2011 at 08:14:05PM +0100, Bram Moolenaar wrote: > You can just keep the existing queue and make this work. It actually > already works for most keys, using a modifier sequence. Using > structures only makes it bigger.
Oh, and I'm not sure I follow your logic here.
Yes, it would make it bigger. By maybe bytes. Consider
struct keypress {
uint16_t flags; /* Unicode or special */
uint16_t modifiers; /* A bitmask */
uint32_t codepoint;
};
that's 8 bytes. As compared a single byte keypress that's 7 bytes
bigger. Less so, compared to e.g. a 3 or 4 byte modifier prefixed
sequence. Not a massive growth here. Lets be really pessimistic and say
we're using 7 bytes extra. Lets now say we're really memory-constrained,
and can only afford a single extra kilobyte of memory. That's still 146
keypresses of queue we can afford. Is vim's queue that big? Can we
really afford no more than a single kilobyte?
Ofcourse, this was a simplistic structure. If we care more about saving
memory at a slight CPU overhead we could
struct keypress {
unsigned int is_special : 1;
unsigned int modifiers : 10;
unsigned int codepoint : 21;
};
that's 4 bytes, to store the same information, noting that Unicode is
only a 21bit code space, a Unicode/special flag, and storage space for
10 modifiers.
4 bytes.
Those variable-length-encoded prefixed keypresses are getting on for
that long anyway. Plus now we're in a fixed-length encoding, so perhaps
we've saved CPU time and associated code space to store the program used
to encode and decode them.
I'm not sure an argument of memory consumption can be made against using
this encoding scheme.
Plus, it's only the queue of incoming keypresses - that queue isn't
going to stay very big for very long.
--
Paul "LeoNerd" Evans
[email protected]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
