I'm interested in trying my hand at implementing this. I'm new to vim-dev,
so if anyone has any advice or reading material I should review, I'd
appreciate it :)
--
View this message in context:
http://vim.1045645.n5.nabble.com/Keyboard-input-handling-tp1211322p3322160.html
Sent from the Vim - D
> On 13 May 2010 11:18, Milan Vancura wrote:
> > BTW, slightly different topic: how can one remap some internal function from
> > its default hotkey to the different one? As far as I know there is nothing
> > like
> > "leave insert mode" function which can be mapped to the different key in
> > c
On 13 May 2010 11:18, Milan Vancura wrote:
> BTW, slightly different topic: how can one remap some internal function from
> its default hotkey to the different one? As far as I know there is nothing
> like
> "leave insert mode" function which can be mapped to the different key in case
> Esc is al
Hello.
This is very interesting thread.
> We -really- need to be able to distinguish Escape, the ASCII sequence of
> 0x1e, from , the human-level idea of pressing that piece of
> plastic. This would enable us to
>
> :map foobarsplot
And also get rid of the waiting loop for distinguishing betw
On Wed, May 05, 2010 at 10:40:39PM +0200, Bram Moolenaar wrote:
> Paul LeoNerd Evans wrote:
> > I would like to propose that the base of the input queue be turned into
> > a queue of structures something like the following form:
> >
> > struct keypress {
> >enum {
> > UNICODE,
> > S
On Wed, May 05, 2010 at 10:40:39PM +0200, Bram Moolenaar wrote:
> It's possible to make a difference between the two when there is a
> mapping for CTRL-SHIFT-T. I actually thought that was working, but it
> doesn't. Perhaps this only works in combination with Alt, don't have
> time right now to c
Paul LeoNerd Evans wrote:
> Vim's keyboard input system revolves centrally around a queue of bytes.
> This worked well when all the world was serial terminals. In this new
> world of GUIs this model doesn't work so well. I advocate changing it to
> a queue of keypress events.
>
> Over the past 7
On Wed, May 5, 2010 at 11:20 AM, Ben Fritz wrote:
>
>
> On May 4, 6:14 pm, Paul LeoNerd Evans wrote:
>> Vim's keyboard input system revolves centrally around a queue of bytes.
>> This worked well when all the world was serial terminals. In this new
>> world of GUIs this model doesn't work so well.
Original-Nachricht
> Datum: Wed, 5 May 2010 00:14:06 +0100
> Von: Paul LeoNerd Evans
> An: vim_dev@googlegroups.com
> Betreff: Keyboard input handling
> Vim's keyboard input system revolves centrally around a queue of bytes.
> This worked well when all the world was serial termi
On May 4, 6:14 pm, Paul LeoNerd Evans wrote:
> Vim's keyboard input system revolves centrally around a queue of bytes.
> This worked well when all the world was serial terminals. In this new
> world of GUIs this model doesn't work so well. I advocate changing it to
> a queue of keypress events.
On May 5, 1:14 am, Paul LeoNerd Evans wrote:
> Vim's keyboard input system revolves centrally around a queue of bytes.
> This worked well when all the world was serial terminals. In this new
> world of GUIs this model doesn't work so well. I advocate changing it to
> a queue of keypress events.
[.
On Tue, May 4, 2010 at 8:14 PM, Tom Sorensen wrote:
> On Tue, May 4, 2010 at 7:14 PM, Paul LeoNerd Evans
> wrote:
>> Over the past 7 years, I have been a member of the #vim channel on
>> Freenode. Almost every week we get somebody in the channel who wonders
>> such things as how to map Ctrl-Shift-
On Tue, May 4, 2010 at 7:14 PM, Paul LeoNerd Evans
wrote:
> Over the past 7 years, I have been a member of the #vim channel on
> Freenode. Almost every week we get somebody in the channel who wonders
> such things as how to map Ctrl-Shift-T differently from Ctrl-T. We
> explain that isn't possible
13 matches
Mail list logo
