On Tue, 21 Oct 2014 20:49:40 +0200
Christian Brabandt wrote:
> > In theory, yes. In practice, last time I looked xterm didn't do it
> > quite right yet.
> >
> > The setting is called modifyOtherKeys but the problem with is was
> > that it either modifies too little (leaving such pairs as Ctrl-
Hi Paul!
On Do, 09 Okt 2014, Paul "LeoNerd" Evans wrote:
> On Mon, 6 Oct 2014 19:59:45 +0200
> Christian Brabandt wrote:
>
> > Hi Paul!
> >
> > On Mo, 06 Okt 2014, Paul "LeoNerd" Evans wrote:
> > > But more than that I've got out and actually tried to do something
> > > to fix them in this reg
On Sunday, October 19, 2014 6:43:23 AM UTC-7, James McCoy wrote:
> On Oct 19, 2014 9:30 AM, "Bee" wrote:
> > On Sunday, October 19, 2014 6:07:07 AM UTC-7, Paul Evans wrote:
> > > I have now just personally run into yet another facet of this problem.
> > > Due to my mapping
> > > :map :b 5
> >
On Sunday, October 19, 2014 6:37:04 AM UTC-7, Bee wrote:
> On Sunday, October 19, 2014 6:30:50 AM UTC-7, Bee wrote:
> > On Sunday, October 19, 2014 6:07:07 AM UTC-7, Paul Evans wrote:
> > > I have now just personally run into yet another facet of this problem.
> > > Due to my mapping
> > > :map
On Oct 19, 2014 9:30 AM, "Bee" wrote:
>
> On Sunday, October 19, 2014 6:07:07 AM UTC-7, Paul Evans wrote:
> > I have now just personally run into yet another facet of this problem.
> > Due to my mapping
> > :map:b 5
> > I cannot type the Greek letter µ, often used as the "micro" SI prefix
sy
On Sunday, October 19, 2014 6:30:50 AM UTC-7, Bee wrote:
> On Sunday, October 19, 2014 6:07:07 AM UTC-7, Paul Evans wrote:
> > I have now just personally run into yet another facet of this problem.
> > Due to my mapping
> > :map:b 5
> > I cannot type the Greek letter µ, often used as the "mic
On Sunday, October 19, 2014 6:07:07 AM UTC-7, Paul Evans wrote:
> I have now just personally run into yet another facet of this problem.
> Due to my mapping
> :map:b 5
> I cannot type the Greek letter µ, often used as the "micro" SI prefix symbol.
try:
:map My
:help :digraphs
:digraphs
an
I have now just personally run into yet another facet of this problem.
Due to my mapping
:map:b 5
I cannot type the Greek letter µ, often used as the "micro" SI prefix
symbol.
Why?
Because µ is U+00B5 in Unicode. 0xb5 is 0x80 + 0x35. Vim treats this
high-bit-set as Alt+(ASCII 0x35), whic
On Mon, 6 Oct 2014 19:59:45 +0200
Christian Brabandt wrote:
> Hi Paul!
>
> On Mo, 06 Okt 2014, Paul "LeoNerd" Evans wrote:
> > But more than that I've got out and actually tried to do something
> > to fix them in this regard. I worked with Thomas Dickey to design a
> > new scheme for universally
Hi Paul!
On Mo, 06 Okt 2014, Paul "LeoNerd" Evans wrote:
> But more than that I've got out and actually tried to do something to
> fix them in this regard. I worked with Thomas Dickey to design a new
> scheme for universally encoding any modified keypress, Unicode-printing
> or special, on a termi
Michael Longval wrote:
> Well for what my $0.02 is worth, here goes:
>
> **Please remember IANAVD (I am not a Vim Dev)**
>
> Isn't there something to learn from Python.
>
> When Python 3 came out, it broke stuff, lots of it.
> But the advantages were worth it. (IMHO)
>
> Some people had too m
Paul Evans wrote:
> On Mon, 06 Oct 2014 17:54:47 +0200
> Bram Moolenaar wrote:
>
> > This hack means backwards compatibility is dropped, it can't be
> > included without breaking lots of things. Don't forget that users
> > today rely on CTRL-I doing the same as Tab. Only when they are
> > map
On Mon, 06 Oct 2014 18:11:19 +0200
Bram Moolenaar wrote:
> We could do something for the GUI, I thought there was a todo item for
> that already. Can't find it now... The idea basically is that when
> Tab and CTRL-I are both mapped, they will be considered to be
> different. This is required fo
On Mon, 06 Oct 2014 17:54:47 +0200
Bram Moolenaar wrote:
> This hack means backwards compatibility is dropped, it can't be
> included without breaking lots of things. Don't forget that users
> today rely on CTRL-I doing the same as Tab. Only when they are
> mapped separately should the mean som
Well for what my $0.02 is worth, here goes:
**Please remember IANAVD (I am not a Vim Dev)**
Isn't there something to learn from Python.
When Python 3 came out, it broke stuff, lots of it.
But the advantages were worth it. (IMHO)
Some people had too much invested in Python 2.6 however, so they s
Ingo Karkat wrote:
> On 06-Oct-2014 12:41 +0200, Paul \"leonerd\" Evans wrote:
>
> > On Sat, 4 Oct 2014 12:37:45 -0700
> > "/#!/JoePea" wrote:
> >
> >> Hmmm, yep. I just tested. gvim and MacVim both don't differentiate
> >> tab and ctrl_i!
> >>
> >> */#!/*JoePea
> >>
> >> On Sat, Oct 4, 2014 a
Paul Evans wrote:
> On Sat, 4 Oct 2014 12:37:45 -0700
> "/#!/JoePea" wrote:
>
> > Hmmm, yep. I just tested. gvim and MacVim both don't differentiate
> > tab and ctrl_i!
> >
> > */#!/*JoePea
> >
> > On Sat, Oct 4, 2014 at 12:34 PM, Ingo Karkat
> > wrote:
> >
> > > On 04-Oct-2014 15:43 +0200,
On 06-Oct-2014 12:41 +0200, Paul \"leonerd\" Evans wrote:
> On Sat, 4 Oct 2014 12:37:45 -0700
> "/#!/JoePea" wrote:
>
>> Hmmm, yep. I just tested. gvim and MacVim both don't differentiate
>> tab and ctrl_i!
>>
>> */#!/*JoePea
>>
>> On Sat, Oct 4, 2014 at 12:34 PM, Ingo Karkat
>> wrote:
>>
>>> O
On Sat, 04 Oct 2014 15:43:34 +0200
Bram Moolenaar wrote:
> Perhaps you were complaining about terminal emulators?
I've been complaining about terminal emulators for years.
But more than that I've got out and actually tried to do something to
fix them in this regard. I worked with Thomas Dickey
On Sat, 4 Oct 2014 12:37:45 -0700
"/#!/JoePea" wrote:
> Hmmm, yep. I just tested. gvim and MacVim both don't differentiate
> tab and ctrl_i!
>
> */#!/*JoePea
>
> On Sat, Oct 4, 2014 at 12:34 PM, Ingo Karkat
> wrote:
>
> > On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote:
> >
> > > Not sure wh
Hmmm, yep. I just tested. gvim and MacVim both don't differentiate tab and
ctrl_i!
*/#!/*JoePea
On Sat, Oct 4, 2014 at 12:34 PM, Ingo Karkat wrote:
> On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote:
>
> > Not sure what your problem is. This works just fine:
> >
> > imap
> >
> > It does requ
On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote:
> Not sure what your problem is. This works just fine:
>
> imap
>
> It does require gvim, since a terminal doesn't make a difference between
> Tab and CTRL-I.
No, even GVIM does not differentiate between and ; that's
what's causing so many p
No Prob, I don't really care because Gmail's Priority Inbox sorts it all
out for me. :D
*/#!/*JoePea
On Sat, Oct 4, 2014 at 11:32 AM, Michael Longval wrote:
> ... sorry about that Bram and Joseph,
>
> I replied by Email and your email addresses were quoted in the reply.
>
> I erased my email re
... sorry about that Bram and Joseph,
I replied by Email and your email addresses were quoted in the reply.
I erased my email replies and reposted without the email addresses.
Mike
( writes another "THINGS NOT TO DO" in his little moleskine notebook...)
--
--
You received this message f
Exactly.
My EMR is in Python3 and I run it in iTerm2 on MacOS (+Homebrew).
I could use Macvim but then I'd be going between two windows. (PITA)
There is no way to make Macvim the host (display) for my Python program? That
way I (might) be able to just use Macvim.
BTW : thanks for your grea
My guess is that there are lot of heretics like you and I.
Cheers!
Michael Longval, MD
On Oct 3, 2014, at 20:04, /#!/JoePea wrote:
Wow, cool!! I thought I was the only one using the IJKL inverted T!!! And my H
key is the insert key. I'm 28. :D I've inoremapped mine to move the cursor
around
My guess is that there are lot of heretics like you and I.
Cheers!
Michael Longval, MD
> On Oct 3, 2014, at 20:04, /#!/JoePea wrote:
>
> Wow, cool!! I thought I was the only one using the IJKL inverted T!!! And my
> H key is the insert key. I'm 28. :D I've inoremapped mine to move the cursor
Exactly.
My EMR is in Python3 and I run it in iTerm2 on MacOS (+Homebrew).
I could use Macvim but then I'd be going between two windows. (PITA)
There is no way to make Macvim the host (display) for my Python program? That
way I (might) be able to just use Macvim.
BTW : thanks for your great
Michael Longval wrote:
> Dear Vim users/devs/Bram
>
> I would like to add my voice to the request for an overhaul of Vim's
> key-input-handling.
>
> Precisely my problem is with Ctrl-i, (like most everyone who complains about
> this problem).
>
> I am using Vim in my EMR (Electronic Medical R
Wow, cool!! I thought I was the only one using the IJKL inverted T!!! And
my H key is the insert key. I'm 28. :D I've inoremapped mine to move the
cursor around while alt is pressed, word by word with Ctrl, and up and down
10 lines at a time with Ctrl. I've also mapped many other keys to IJKL,
e.g.
Dear Vim users/devs/Bram
I would like to add my voice to the request for an overhaul of Vim's
key-input-handling.
Precisely my problem is with Ctrl-i, (like most everyone who complains about
this problem).
I am using Vim in my EMR (Electronic Medical Record) system. Although I have
been using
On Tue, 29 Oct 2013 07:01:41 -0400
Michael Henry wrote:
> Sorry I was not clear. I certainly wasn't trying to break all
> mappings :-) I was thinking of and discussing mostly the :map
> functionality of Vim, not (yet) the terminal-handling side, and
> talking about behavior for a terminal where
On 10/28/2013 07:41 AM, Bram Moolenaar wrote:
>
> Michael Henry wrote:
>> So I suggest that a single global option that simply switches on
>> support for extended modifier for all keys, regardless whether
>> those keys are mapped, may well be good enough and might make
>> the implementation simple
On Oct 28, 2013 3:41 PM, "Bram Moolenaar" wrote:
>
>
> Michael Henry wrote:
>
> > On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar
wrote:
> > > I already said this: It's fine to add so long as it's 100% backwards
> > > compatible. That means encoding keys on top of what's already there,
> > > an
Michael Henry wrote:
> On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar wrote:
> > I already said this: It's fine to add so long as it's 100% backwards
> > compatible. That means encoding keys on top of what's already there,
> > and falling back to the ordinary key if the key + modifier isn't m
On Monday, October 28, 2013 12:00:40 AM UTC-5, Andre Sihera wrote:
> On 28/10/13 02:58, Paul LeoNerd Evans wrote:
>
> >> Please explain how you are going to differentiate CTRL-I and Tab in
>
> >> > random terminal emulator. Some may be configured to output either as
>
> >> > CSI sequence, but
On 28/10/13 14:00, Andre Sihera wrote:
On 28/10/13 02:58, Paul LeoNerd Evans wrote:
Please explain how you are going to differentiate CTRL-I and Tab in
> random terminal emulator. Some may be configured to output either as
> CSI sequence, but not all. This is not simply historical artifact.
Y
On 28/10/13 02:58, Paul LeoNerd Evans wrote:
Please explain how you are going to differentiate CTRL-I and Tab in
> random terminal emulator. Some may be configured to output either as
> CSI sequence, but not all. This is not simply historical artifact.
You can't. Does that matter? Some people
On Sun, 27 Oct 2013 10:38:09 -0700 (PDT)
ZyX wrote:
> Please explain how you are going to differentiate CTRL-I and Tab in
> random terminal emulator. Some may be configured to output either as
> CSI sequence, but not all. This is not simply historical artifact.
You can't. Does that matter? Some
On Sunday, October 27, 2013 6:54:16 PM UTC+4, Michael Henry wrote:
> On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar wrote:
> > I already said this: It's fine to add so long as it's 100% backwards
> > compatible. That means encoding keys on top of what's already there,
> > and falling back to th
On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar wrote:
> I already said this: It's fine to add so long as it's 100% backwards
> compatible. That means encoding keys on top of what's already there,
> and falling back to the ordinary key if the key + modifier isn't mapped.
This is very encouragin
On Sat, 26 Oct 2013 18:46:22 -0700
"/#!/JoePea" wrote:
> I've given this some thought. The backwards compatibility that users
> should experience should be as simple as possible.
>
> For example, let's suppose someone has the following in their vimrc.
>
> map :echo "hello"
>
> Let me describe
On 10/26/2013 04:06 PM, Nikolay Pavlov wrote:
> > How to detect the modifiers for many terminals in a portable way,
> > without requiring installing an obscure library (at least Ubuntu must
> > have it), I don't know.
>
> I think that vim is popular enough to expect distribution
> maintainers to pa
On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar wrote:
>
>
> I already said this: It's fine to add so long as it's 100% backwards
> compatible. That means encoding keys on top of what's already there,
> and falling back to the ordinary key if the key + modifier isn't mapped.
>
I've given this
On Sun, 27 Oct 2013 01:58:32 +0100
Paul "LeoNerd" Evans wrote:
> > How to detect the modifiers for many terminals in a portable way,
> > without requiring installing an obscure library (at least Ubuntu
> > must have it), I don't know.
>
> Then let me explain it to you Bram; it's very simple.
>
On Sat, 26 Oct 2013 21:50:57 +0200
Bram Moolenaar wrote:
> How to detect the modifiers for many terminals in a portable way,
> without requiring installing an obscure library (at least Ubuntu must
> have it), I don't know.
Then let me explain it to you Bram; it's very simple.
All modified keys
> How to detect the modifiers for many terminals in a portable way,
> without requiring installing an obscure library (at least Ubuntu must
> have it), I don't know.
I think that vim is popular enough to expect distribution maintainers to
package library once we start using it. With some lag, grea
Ingo Karkat wrote:
> On 14-Oct-2013 15:32 +0200, Paul "LeoNerd" Evans wrote:
>
> > On Sun, 13 Oct 2013 14:00:15 -0700 (PDT) Joseph Pea
> > wrote:
> >
> >> [...]
> >>
> >> I hope this proposal becomes reality sometime sooner than later!
> >
> > +1
> >
> > This has been dragging on for years
On 14-Oct-2013 15:32 +0200, Paul "LeoNerd" Evans wrote:
> On Sun, 13 Oct 2013 14:00:15 -0700 (PDT) Joseph Pea
> wrote:
>
>> [...]
>>
>> I hope this proposal becomes reality sometime sooner than later!
>
> +1
>
> This has been dragging on for years now (I think it was 8 years
> ago that I firs
I think the issue of backwards compatibility should be kept as simple as
possible. Nothing should change in the way that you can currently use VimL
(a.k.a. Vim Script) inside you .vimrc or in any other .vim file.
For example, you can currently do
map :echo "does something"
*or*
map :echo "do
I bet you know enough to be able to figure out fairly easily. :) Also, the
Vim organization in Google Summer of Code can have more than one mentor,
and you guys could work together. I think GSoC would be a really great way
of making this happen.
*/#!/*JoePea
On Wed, Oct 16, 2013 at 5:37 AM, Paul
On Oct 16, 2013 4:43 PM, "Paul LeoNerd" wrote:
>
> On Tue, 15 Oct 2013 12:03:41 -0700 (PDT)
> ZyX wrote:
>
> > 2. Second problem is pure technical: someone must sit down and code
> > this. Maybe use some terminal library, maybe not.
>
> Not wanting to sound like a broken record, but this suggesti
On Tue, 15 Oct 2013 12:03:41 -0700 (PDT)
ZyX wrote:
> 2. Second problem is pure technical: someone must sit down and code
> this. Maybe use some terminal library, maybe not.
Not wanting to sound like a broken record, but this suggestion is
basically what I keep making every few years.
If the in
On Tue, 15 Oct 2013 14:01:16 -0700
"/#!/JoePea" wrote:
> I think you, Paul Evans, would be a good choice for the mentor who
> would guide the students through the effort.
I'm not sure that's true because I have no knowledge at all of the
insides of vim. I know terminals, and I know what outward-
On Mon, Oct 14, 2013 at 6:32 AM, Paul LeoNerd wrote:
> On Sun, 13 Oct 2013 14:00:15 -0700 (PDT)
> Joseph Pea wrote:
>
> > The most trouble this will cause is that some people will have to
> > rewrite their mappings with the correct keystroke identifiers, which
> > is very easy to do.
> >
> > I ho
I see two problems with input queue:
1. Recognition and mapping keys that currently cannot be mapped.
2. Keeping backward compatibility with old behavior: e.g. keeping and
the same while allowing to map them separately.
I think that these problems should have separate solutions. To solve 1. we
On Sun, 13 Oct 2013 14:00:15 -0700 (PDT)
Joseph Pea wrote:
> The most trouble this will cause is that some people will have to
> rewrite their mappings with the correct keystroke identifiers, which
> is very easy to do.
>
> I hope this proposal becomes reality sometime sooner than later!
+1
Th
I 18th this effort. I've been using Vim since May this year and have run into
this innocently trying to map , , and .
Paul Evans suggested to use a modifiedunicode option (along with some other
options) to enable the "new features":
:set nomodifiedunicode
:map ONE
:map TWO
:set modifi
Ok, I am resurrecting a very old thread here because it keeps coming
up time and time again on #vim in Freenode, and Paul still wants this
to happen, as do many of us.
On Fri, Feb 25, 2011 at 8:43 AM, Bram Moolenaar wrote:
>
>
> So the problem is that many users expect CTRL-M to have the same eff
> > As long as the two triplets of keypresses I suggested originally can all
> > be represented uniquely, and without reference to timing information in
> > the Escape vs Alt+ case, then I'm happy with whatever internal
> > implementation makes it happen.
>
> The two triplets in question being
>
>
On Mon, Mar 07, 2011 at 11:24:23AM -0500, Benjamin R. Haskell wrote:
> >Changing terminal emulators is a done task; xterm has supported
> >this since 2008. In fact I asked Thomas Dickey to clarify this for
> >me, and he informs me it's all present and working.
>
> Despite its popularity, xterm is
[drafted a while ago, but sending now that the thread got bumped; might
be a bit roughdraftish]
On Fri, 25 Feb 2011, Bram Moolenaar wrote:
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
On Mon, 7 Mar 2011, Paul LeoNerd Evans wrote:
On Fri, Feb 25, 2011 at 02:43:23PM +0100, Bram Moolenaar wrote:
First problem is to actually detect what key was pressed, in most
terminal emulators this is not possible. In the GUI we can.
Changing terminal emulators to support this and making th
(Just a couple of points of extra clarity)
On Mon, Mar 07, 2011 at 03:46:35PM +, Paul LeoNerd Evans wrote:
> As long as the two triplets of keypresses I suggested originally can all
> be represented uniquely, and without reference to timing information in
> the Escape vs Alt+ case, then I'm ha
On Thu, Feb 24, 2011 at 05:25:17AM -0500, Benjamin R. Haskell wrote:
> The whole situation is pretty arbitrary. E.g. ./demo's output under
> a modifyOtherKeys:2 UXTerm, compressed to one row, for + the
> top row of my typical US 105-key or variant:
>
> ! # $ % & * ( ) +
>
> Why the Shift mo
On Fri, Feb 25, 2011 at 02:43:23PM +0100, Bram Moolenaar wrote:
> So the problem is that many users expect CTRL-M to have the same effect
> as Enter, just like people use CTRL-[ instead of Esc. And a few people
> would make the CTRL-M act different from Enter, and CTRL-[ different
> from Esc.
Tha
> So I would encourage you not to view this discussion as opposition to
> the idea. Quite the reverse. This discussion is actually an important
> part of making this idea happen. We need to discuss these things so we
> can do it the best way possible, without *needlessly* breaking backward
> compat
> 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).
>
> About vim, I misunderstood that it was a keybo
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 wel
So basically backward compatibility and memory efficiency are what
hold vim back in 1970. You made a lot of good points and reasons for
it to be so, but I'm always sad when good ideas are refused just
because of old scenarios.
I don't think anybody has refused the idea, and I don't think anybody
> That said, I think there is a compromise. Vim has features, maybe the
> new input mechanism could simply be a feature, something like
> +enhanced_term_input (like we have for +python or +eval), and plugins
> could simply check with stuffs like:
With an option like :set term_input_type=backward_c
> This would be easier if we actually had a solid 'new design'. We don't.
> We just have a bunch of rough ideas. One of those ideas had a drafted
> structure and suggestion that it be used only in the input queue, where
> the memory inefficiency would not be a concern. I have pointed out that
> the
Sorry Ben
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).
About vim, I misunderstood that it was a keyboar
On Thu, Feb 24, 2011 at 10:29:02AM +1100, Ben Schmidt wrote:
> >rxvt uses its own, totally-incompatible encoding scheme for modified
> >keypresses. This scheme is different to any other terminal that has such
> >abilities (all the others follow xterm's CSI scheme). It is also
> >incompatible with E
The whole situation is pretty arbitrary. E.g. ./demo's output under a
modifyOtherKeys:2 UXTerm, compressed to one row, for + the top row of my
typical US 105-key or variant:
! # $ % & * ( ) +
Why the Shift modifier on ~, @, ^, and _, but not !, #, $, etc? (Guessing
hysterical raisins.)
Th
So, I'm wondering: what does libtermkey bring to the table?
It parses CSIs, the way that xterm et.al. send modified keys.
Of course, Vim can already do this to an extent.
:help keycodes
:help xterm-8bit
:help +termresponse
It's only keys like Control-I which are still indistingishable from k
On Wed, 23 Feb 2011, Paul LeoNerd Evans wrote:
On Tue, Feb 22, 2011 at 11:43:39PM -0500, Benjamin R. Haskell wrote:
[...] I'm wondering: what does libtermkey bring to the table?
It parses CSIs, [...]
Without a CSI parser, using only a 1970s-style terminfo-driven prefix
hunting algorithm, t
On Feb 24, 5:13 am, Paul LeoNerd Evans wrote:
...
> Forceful-Ctrl-Up CSI 1;5;3 A
Now there's an idea :)))
Regards, John
--
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.or
On Tue, Feb 22, 2011 at 11:43:39PM -0500, Benjamin R. Haskell wrote:
> Taking that as a given, I'm going to ignore that aspect of this
> issue. My question is about libtermkey. I was curious enough to
> download it, unpack it, `make` it, and run ./demo. And,
> surprisingly, given that it seems to
On 20/02/11 10:17 PM, Philippe Vaucher wrote:
Yes. But what happens when you then edit that macro by putting the
register into a buffer, changing it, and yanking it again? This is not
uncommonly done. How should the registers be stored in .viminfo? How do
you write the input to the feedkeys funct
First, Stephen, please don't top-post. Like it or not (and personally I
don't!) that is the convention on this list. I must admit, though, that
particularly after somebody else has already bottom-posted, top-posting
makes things a big mess. In future, please write your replies under
short, relevan
On Thu, 17 Feb 2011, Paul LeoNerd Evans wrote:
Graywh wrote:
Please fix vim's input queue mechanism with key info structures a.la
libtermkey so that LeoNerd can fix terminal input and Gvim and
everyone will be happy. Thanks.
[...]
I am talking about ripping out the byte-queue input system
On Feb 22, 8:55 pm, Adrien "Pied" Piérard wrote:
> Hi.
>
> 2011/2/23 Stephen Lee :
>
> > Therefore I propose letting users choose their preferred keyboard
> > layouts instead of forcing any specific one to them.
> > In your case it seems you are talking about QWERTY and QWERTZ (from
> > wiki), s
Hi.
2011/2/23 Stephen Lee :
> Therefore I propose letting users choose their preferred keyboard
> layouts instead of forcing any specific one to them.
> In your case it seems you are talking about QWERTY and QWERTZ (from
> wiki), so the following would be keyboard layouts in the new directory
> c
Sorry everyone,
I just browsed through vim and found a directory called "keymap"
can we reuse and change or add different layout files in there?
On Feb 23, 2:35 am, Stephen Lee wrote:
> Therefore I propose letting users choose their preferred keyboard
> layouts instead of forcing any specific on
Therefore I propose letting users choose their preferred keyboard
layouts instead of forcing any specific one to them.
In your case it seems you are talking about QWERTY and QWERTZ (from
wiki), so the following would be keyboard layouts in the new directory
called "Keyboard"
(General keyboard lay
> Yes. But what happens when you then edit that macro by putting the
> register into a buffer, changing it, and yanking it again? This is not
> uncommonly done. How should the registers be stored in .viminfo? How do
> you write the input to the feedkeys function as a string in vimscript?
> Etc.. Th
> Yes. But what happens when you then edit that macro by putting the
> register into a buffer, changing it, and yanking it again? This is not
> uncommonly done. How should the registers be stored in .viminfo? How do
> you write the input to the feedkeys function as a string in vimscript?
> Etc.. T
Plus, it's only the queue of incoming keypresses - that queue isn't
going to stay very big for very long.
It's not just the input queue that's in question here, it's everywhere
in Vim where keypresses are represented. For instance, the right hand
sides of mappings are not primarily characters, b
On Fri, Feb 18, 2011 at 04:12:47PM +1100, Ben Schmidt wrote:
> >Plus, it's only the queue of incoming keypresses - that queue isn't
> >going to stay very big for very long.
>
> It's not just the input queue that's in question here, it's everywhere
> in Vim where keypresses are represented. For ins
On Fri, Feb 18, 2011 at 05:35:38AM -0800, Philippe Vaucher wrote:
> FWIW, you have my vote for making this happen. I think it's not that
> hard to make everyone happy on this subject by the mean of .vimrc
> settings, like we have between vi and vim for :set compatible.
:set compatible does sugges
FWIW, you have my vote for making this happen. I think it's not that
hard to make everyone happy on this subject by the mean of .vimrc
settings, like we have between vi and vim for :set compatible.
Wether we use structures or the byte 80 for special key is
implementation detail, I mean wether macr
Would it be better to have a new folder called "Keyboard", putting all
the key mapping definition files like dvorak.vim, 101-keyboard.vim,
etc. and let people set in .vimrc?
It may be more flexible than just new or old term mode...
On Feb 18, 6:07 am, Paul LeoNerd Evans wrote:
> On Thu, Feb 17,
Hello I just join discussion because I love vim and want to give a
small suggestion:
Is it possible to put a parameter in .vimrc like:
set keymap=byte-queue, structured, etc..
(default is byte-queue)
so that both sets of mapping could be kept...
sorry if I see the problem too surface.
On Feb 18
> It's not just the input queue that's in question here, it's everywhere
> in Vim where keypresses are represented.
> And I'm sure there are plenty more subtleties.
What I see here, if done, is a potential new major version of vim.
Such a new version may trade off backward compatibility for up-to
Plus, it's only the queue of incoming keypresses - that queue isn't
going to stay very big for very long.
It's not just the input queue that's in question here, it's everywhere
in Vim where keypresses are represented. For instance, the right hand
sides of mappings are not primarily characters, b
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
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.
OK, well which ever way works.. I'm not fussy about the intern
Please, please, PLEASE make this happen.
On Feb 17, 11:48 am, Paul LeoNerd Evans
wrote:
> On Fri, Feb 04, 2011 at 07:14:29PM +0100, Bram Moolenaar wrote:
> > Graywh wrote:
>
> > > Please fix vim's input queue mechanism with key info structures a.la
> > > libtermkey so that LeoNerd can fix termina
Paul Evans wrote:
> I would like this. For all systems. Everywhere.
>
> This is a large undertaking. This isn't a "send me a patch" request.
>
> I am talking about ripping out the byte-queue input system and replacing
> it with a structured keypress queue. The lot. Everything. Remove the
> "stu
1 - 100 din 105 matches
Mail list logo
