On 5/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Sun, May 14, 2006 at 03:28:23PM -0600, Eric Arnold wrote:
>
> I've uploaded the patch. It's at proof-of-concept stage.
Eric, I noticed you've made a few patches. I especially like the one
where you introduced the "GetChar" event. This is a fantastic idea
because the "getchar()" function itself is very limiting, disabling
normal Vim behavior during its use. Something like this "GetChar" event
will allow some extremely powerful plugins to be made.
Have you proposed the patch to Bram?
I've posted it to the vim-dev group, but I haven't heard from him.
Maybe he was too busy to think about it. I don't have a feel for
what's it takes to have an enhancement patch accepted, yet. Maybe
I'll ask for some conceptual input from him.
--Matt
P.S. Maybe a GetCharPre/GetCharPost scheme would be useful, since
because of mappings and what not, you might not know what's going to
happen when the char is processed. You could use GetCharPost to see what
happens after it was processed. Just a thought.
I'm not sure where I could put the trap that would make sense. Do you
have examples in mind?
I've added an 'o'=="OP_PENDING" return from mode() which tells you
when a char is received in operator-pending mode. I.e. for "cw", "c"
would be normal mode, and "w" would be operator-pending.
I'm not sure if there's a good way to know ahead of time whether
something is going to require additional keystrokes (op-pending)
without a comprehensive list of commands and a full scan of all
mappings, in the script. As far as I can tell, in the code, by the
time you know about op-pending, the processing is well under way, and
could be in any of the evaluation branches. There might be a function
that says "start_of_op_pending_sequence()", but I can't find it.
I'm currently playing around with just keeping an input stack, and
seeing if it seems Ok to always be a key or two behind, waiting to see
if op-pending keys appear.
P.S. Yehaa, I've wrapping tabs now! No more chopped file names :-)
