Re: Dear Bram
On Tue, 21 Oct 2014 20:49:40 +0200 Christian Brabandt cbli...@256bit.org 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-a and Ctrl-Shift-A indistinct), or modifies too much (using CSI u encoding for a plain Ctrl-c keypress, thus meaning termios doesn't recognise it and send a SIGTERM). I have re-raised this with Thomas just now; I'll see if we can get to a point where it's just in the middle, and therefore right. So what would be the preferred way to actually see those keys? Installing pangoterm? pangoterm, or continue prodding at xterm until it does the right thing :) Or provoke your preferred terminal's author into fixing it. More consensus among terminals = better. -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS signature.asc Description: PGP signature
Re: Dear Bram
I have now just personally run into yet another facet of this problem. Due to my mapping :map A-5 :b 5CR 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), which is the digit 5. Thus it triggers my mapping. This breaks EVEN in gvim. I start a brand new gvim, enter insert mode, try to type µ and immediately get E86: Buffer 5 does not exist This one also needs fixing. Please Bram? -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS signature.asc Description: PGP signature
Re: Dear Bram
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 A-5 :b 5CR I cannot type the Greek letter µ, often used as the micro SI prefix symbol. try: :map a-5 c-kMycr :help :digraphs :digraphs and note 0xb5 is decimal 181 -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 A-5 :b 5CR I cannot type the Greek letter µ, often used as the micro SI prefix symbol. try: :map a-5 c-kMycr :help :digraphs :digraphs and note 0xb5 is decimal 181 oops written too quickly, better: :imap a-5 c-kMy -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
On Oct 19, 2014 9:30 AM, Bee fo...@calcentral.com 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 A-5 :b 5CR I cannot type the Greek letter µ, often used as the micro SI prefix symbol. try: :map a-5 c-kMycr I think you're misunderstanding what Paul's saying. His A-5 mapping isn't supposed to insert µ. It's supposed to switch to buffer 5. The problem is that when he types µ, it triggers the A-5 mapping instead of inserting the character. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 A-5 :b 5CR I cannot type the Greek letter µ, often used as the micro SI prefix symbol. :help i_ctrl-k using the digraph name: :imap a-5 c-kMy :help i_ctrl-v :help i_ctrl-v_digit using hex: :imap a-5 c-vxb5 using decimal :imap a-5 c-v181 -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
On Sunday, October 19, 2014 6:43:23 AM UTC-7, James McCoy wrote: On Oct 19, 2014 9:30 AM, Bee fo...@calcentral.com 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 A-5 :b 5CR I cannot type the Greek letter µ, often used as the micro SI prefix symbol. try: :map a-5 c-kMycr I think you're misunderstanding what Paul's saying. His A-5 mapping isn't supposed to insert µ. It's supposed to switch to buffer 5. Yes, I did not understand. The problem is that when he types µ, it triggers the A-5 mapping instead of inserting the character. How to reproduce that? After creating Paul's mapping a-5 in insert mode produces µ. The :map should not effect insert mode. Paul did you also map? :imap a-5 c-o:b 5cr Even if I have both the :map and :imap and use in insert mode: ^vxb5 ( aka c-vxb5 ) or ^kMy ( aka c-kMy ) they always insert the µ character. Linux Mint 17 gvim 7.4.52 vim 7.4.463 -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
On Mon, 6 Oct 2014 19:59:45 +0200 Christian Brabandt cbli...@256bit.org 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 encoding any modified keypress, Unicode-printing or special, on a terminal. http://www.leonerd.org.uk/hacks/fixterms/ Does that mean, I can have xterm already configured in such a way, so that it outputs those special CSI sequences? What version does that need and how do I enable it? 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-a and Ctrl-Shift-A indistinct), or modifies too much (using CSI u encoding for a plain Ctrl-c keypress, thus meaning termios doesn't recognise it and send a SIGTERM). I have re-raised this with Thomas just now; I'll see if we can get to a point where it's just in the middle, and therefore right. -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS signature.asc Description: PGP signature
Re: Dear Bram
On Sat, 4 Oct 2014 12:37:45 -0700 /#!/JoePea trus...@gmail.com 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 sw...@ingo-karkat.de wrote: On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote: Not sure what your problem is. This works just fine: imap C-I Up It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. This, Bram, is exactly the thing I have been arguing at you for years now. You keep deflecting this down to make it sound like the terminal's fault, when we both know it isn't. You and I both know full well that terminals don't distinguish them; I accept that. That's why I designed a better system, in cooperation with Thomas Dickey (the current xterm author). I have a terminal now that distinguishes any and all possible combinations of keypresses, and programs that understand it. Most of the programs I run regularly now do understand this - I can type Ctrl-I and Ctrl-Shift-A and so on absolutely fine. Vim is one of the few programs remaining that doesn't. (see attached screenshot-1). Vim - I am talking specifically about vim here - conflates the possible keypresses of Ctrl-I vs Tab, of Ctrl-M(or is it Ctrl-J I forget) and Enter, of Ctrl-H and Backspace. It further conflates Ctrl-S and Ctrl-Shift-S, etc etc... And lets not get started on Unicode vs. Alt-letters. Blaming terminals for this is just deflecting from the fact that vim's internals aren't sufficiently generic to represent the possible keypresses, regardless of how they arrive. That 1980s-style terminals couldn't do it is one thing but that is no excuse that a 2014-style GTK/Win32-driven GUI program cannot. You cannot reply to the original poster of this email and claim that it works, until you can perform the following test IN GVIM to demonstrate it so. :imap Tab You typed tab :imap C-i You typed Ctrl-I :imap C-S-I You typed Ctrl-Shift-I Then press all three keypresses and show it inserting different text. Do this in gvim, so as to avoid any reason to blame the terminal. For me, right now in GTK2-driven gvim, I get the Ctrl-Shift-I version all three times. (see attached screenshot-2) Only when that works can you reply to the OP and say this works. -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS signature.asc Description: PGP signature
Re: Dear Bram
On Sat, 04 Oct 2014 15:43:34 +0200 Bram Moolenaar b...@moolenaar.net 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 to design a new scheme for universally encoding any modified keypress, Unicode-printing or special, on a terminal. http://www.leonerd.org.uk/hacks/fixterms/ To be clear - this is a small extension of the existing scheme that remains 100% backward compatible - any keypress that could be detected before, is still sent the same way. This just gives a new way to encode new keypresses that previously did not make sense. I then went and wrote a virtual terminal emulator library and GTK2-based wrapper program that uses it http://www.leonerd.org.uk/code/libvterm/ http://www.leonerd.org.uk/code/pangoterm/ I then wrote a keyboard input library and surrounding terminal UI system that uses it http://www.leonerd.org.uk/code/libtermkey/ http://www.leonerd.org.uk/code/libtickit/ All that remains to be done is for programs that attempt to interpret incoming keypresses be suitably adjusted so as to understand these new incoming byte sequences, and all will be sorted, and then finally OP will be able to type Ctrl-I properly, as was his want. I have been talking with the Neovim project on the subject of a modern UI toolkit for use in the terminal frontend. Whether or not they end up using libtickit for this, they are still aware of the improvements and modernisations I have been working on, and when the time comes for them to rebuild the terminal frontend properly I'm quite confident they'll be in a position to support all these modified keypresses. If you wanted the same support in core vim, all you'd need to do is implement the key encoding scheme, as given in the first link. I am done complaining. I am done fixing it. As far as I'm concerned it is now fixed. All that remains is for other people to come and join the party. Will you be one of them? -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS signature.asc Description: PGP signature
Re: Dear Bram
On 06-Oct-2014 12:41 +0200, Paul \leonerd\ Evans wrote: On Sat, 4 Oct 2014 12:37:45 -0700 /#!/JoePea trus...@gmail.com 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 sw...@ingo-karkat.de wrote: On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote: Not sure what your problem is. This works just fine: imap C-I Up It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. This, Bram, is exactly the thing I have been arguing at you for years now. You keep deflecting this down to make it sound like the terminal's fault, when we both know it isn't. You and I both know full well that terminals don't distinguish them; I accept that. That's why I designed a better system, in cooperation with Thomas Dickey (the current xterm author). I have a terminal now that distinguishes any and all possible combinations of keypresses, and programs that understand it. Most of the programs I run regularly now do understand this - I can type Ctrl-I and Ctrl-Shift-A and so on absolutely fine. Vim is one of the few programs remaining that doesn't. (see attached screenshot-1). Vim - I am talking specifically about vim here - conflates the possible keypresses of Ctrl-I vs Tab, of Ctrl-M(or is it Ctrl-J I forget) and Enter, of Ctrl-H and Backspace. It further conflates Ctrl-S and Ctrl-Shift-S, etc etc... And lets not get started on Unicode vs. Alt-letters. Blaming terminals for this is just deflecting from the fact that vim's internals aren't sufficiently generic to represent the possible keypresses, regardless of how they arrive. That 1980s-style terminals couldn't do it is one thing but that is no excuse that a 2014-style GTK/Win32-driven GUI program cannot. You cannot reply to the original poster of this email and claim that it works, until you can perform the following test IN GVIM to demonstrate it so. :imap Tab You typed tab :imap C-i You typed Ctrl-I :imap C-S-I You typed Ctrl-Shift-I Then press all three keypresses and show it inserting different text. Do this in gvim, so as to avoid any reason to blame the terminal. For me, right now in GTK2-driven gvim, I get the Ctrl-Shift-I version all three times. (see attached screenshot-2) Only when that works can you reply to the OP and say this works. To provide evidence that this issue indeed troubles many people (especially newcomers to Vim), here's an updated tally of related questions that regularly come up on Stack Overflow and related sites: https://www.google.com/search?q=site%3Astackoverflow.com%20%2B%22Ingo%20Karkat%22%20%22foremost%20Paul%20LeoNerd%20Evans%22 (about 32 results) https://www.google.com/search?q=site%3Asuperuser.com+%2B%22Ingo+Karkat%22+%22foremost+Paul+LeoNerd+Evans%22 (6 results) I'm happy to see that Paul is still pursuing this issue; Bram, why don't you get him and other developers finally started on designing and implementing a solution by briefly signaling a willingness to consider this for a future Vim 8.0?! -- regards, ingo -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
Paul Evans wrote: On Sat, 4 Oct 2014 12:37:45 -0700 /#!/JoePea trus...@gmail.com 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 sw...@ingo-karkat.de wrote: On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote: Not sure what your problem is. This works just fine: imap C-I Up It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. This, Bram, is exactly the thing I have been arguing at you for years now. You keep deflecting this down to make it sound like the terminal's fault, when we both know it isn't. You and I both know full well that terminals don't distinguish them; I accept that. That's why I designed a better system, in cooperation with Thomas Dickey (the current xterm author). I have a terminal now that distinguishes any and all possible combinations of keypresses, and programs that understand it. Most of the programs I run regularly now do understand this - I can type Ctrl-I and Ctrl-Shift-A and so on absolutely fine. Vim is one of the few programs remaining that doesn't. (see attached screenshot-1). Vim - I am talking specifically about vim here - conflates the possible keypresses of Ctrl-I vs Tab, of Ctrl-M(or is it Ctrl-J I forget) and Enter, of Ctrl-H and Backspace. It further conflates Ctrl-S and Ctrl-Shift-S, etc etc... And lets not get started on Unicode vs. Alt-letters. Blaming terminals for this is just deflecting from the fact that vim's internals aren't sufficiently generic to represent the possible keypresses, regardless of how they arrive. That 1980s-style terminals couldn't do it is one thing but that is no excuse that a 2014-style GTK/Win32-driven GUI program cannot. You cannot reply to the original poster of this email and claim that it works, until you can perform the following test IN GVIM to demonstrate it so. :imap Tab You typed tab :imap C-i You typed Ctrl-I :imap C-S-I You typed Ctrl-Shift-I Then press all three keypresses and show it inserting different text. Do this in gvim, so as to avoid any reason to blame the terminal. For me, right now in GTK2-driven gvim, I get the Ctrl-Shift-I version all three times. (see attached screenshot-2) Only when that works can you reply to the OP and say this works. 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 something different. Your page doesn't say how to switch between the old mode, where CTRL-I produces a 0x09 character, and one where it produces a different character. This is required for the terminal to be used with programs that do not support the new codes. One can't expect to have all programs that a user uses to suddenly accept the new characters, thus a switch between two modes is required. Vim could switch to the new mode and take care of a default set of mappings to the old meaning. That's a lot of work though. Also, I don't see any note about different language keyboards. There are many, and the mechanism should work for all, with proper documentation what happens for different keyboards. Also, I don't see anything for keypad keys, the numlock key and other keys that some keyboards have that change what other keys mean. -- hundred-and-one symptoms of being an internet addict: 226. You sit down at the computer right after dinner and your spouse says See you in the morning. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
Ingo Karkat wrote: On 06-Oct-2014 12:41 +0200, Paul \leonerd\ Evans wrote: On Sat, 4 Oct 2014 12:37:45 -0700 /#!/JoePea trus...@gmail.com 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 sw...@ingo-karkat.de wrote: On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote: Not sure what your problem is. This works just fine: imap C-I Up It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. This, Bram, is exactly the thing I have been arguing at you for years now. You keep deflecting this down to make it sound like the terminal's fault, when we both know it isn't. You and I both know full well that terminals don't distinguish them; I accept that. That's why I designed a better system, in cooperation with Thomas Dickey (the current xterm author). I have a terminal now that distinguishes any and all possible combinations of keypresses, and programs that understand it. Most of the programs I run regularly now do understand this - I can type Ctrl-I and Ctrl-Shift-A and so on absolutely fine. Vim is one of the few programs remaining that doesn't. (see attached screenshot-1). Vim - I am talking specifically about vim here - conflates the possible keypresses of Ctrl-I vs Tab, of Ctrl-M(or is it Ctrl-J I forget) and Enter, of Ctrl-H and Backspace. It further conflates Ctrl-S and Ctrl-Shift-S, etc etc... And lets not get started on Unicode vs. Alt-letters. Blaming terminals for this is just deflecting from the fact that vim's internals aren't sufficiently generic to represent the possible keypresses, regardless of how they arrive. That 1980s-style terminals couldn't do it is one thing but that is no excuse that a 2014-style GTK/Win32-driven GUI program cannot. You cannot reply to the original poster of this email and claim that it works, until you can perform the following test IN GVIM to demonstrate it so. :imap Tab You typed tab :imap C-i You typed Ctrl-I :imap C-S-I You typed Ctrl-Shift-I Then press all three keypresses and show it inserting different text. Do this in gvim, so as to avoid any reason to blame the terminal. For me, right now in GTK2-driven gvim, I get the Ctrl-Shift-I version all three times. (see attached screenshot-2) Only when that works can you reply to the OP and say this works. To provide evidence that this issue indeed troubles many people (especially newcomers to Vim), here's an updated tally of related questions that regularly come up on Stack Overflow and related sites: https://www.google.com/search?q=site%3Astackoverflow.com%20%2B%22Ingo%20Karkat%22%20%22foremost%20Paul%20LeoNerd%20Evans%22 (about 32 results) https://www.google.com/search?q=site%3Asuperuser.com+%2B%22Ingo+Karkat%22+%22foremost+Paul+LeoNerd+Evans%22 (6 results) I'm happy to see that Paul is still pursuing this issue; Bram, why don't you get him and other developers finally started on designing and implementing a solution by briefly signaling a willingness to consider this for a future Vim 8.0?! This has nothing to do with willingness. The solution provided will cause more trouble than it solves, and is very limited otherwise. In other words: it is not a good solution. 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 for existing mappings to keep working. It will still break when someone tries to overrule a mapping for Tab with a mapping for CTRL-I though. Hopefully that doesn't happen very often. -- hundred-and-one symptoms of being an internet addict: 227. You sleep next to your monitor. Or on top of it. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 stayed with that (and bug fixes continu on that version, but the new stuff is in Python3) Vim broke with Vi (see: set nocompatible) yet was successful. Vim8 with a 21st century input mechanism, can do the same. Road map: *Move official Vim8 (call it V8) onto GitHub. *Set design goals: - Keep it CharityWare (above all else) - New input engine - Wall to wall UTF-8 support - Wall to wall Python3 scripting. See who comes to work on it. Yes anyone who reads this will say: Ya right sounds easy, but it's way harder than that. I have NO ARGUMENT with that. BUT my guess is that if a guy with the authority of Bram Moolenaar says: We are going to break Vim to make it better for the future., people will listen. (Many who are much younger than both you and I, Bram, and have a lot more energy.) Respectfully, Michael LONGVAL, MD On Oct 6, 2014, at 11:54 AM, Bram Moolenaar b...@moolenaar.net wrote: 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 sw...@ingo-karkat.de wrote: On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote: Not sure what your problem is. This works just fine: imap C-I Up It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. This, Bram, is exactly the thing I have been arguing at you for years now. You keep deflecting this down to make it sound like the terminal's fault, when we both know it isn't. You and I both know full well that terminals don't distinguish them; I accept that. That's why I designed a better system, in cooperation with Thomas Dickey (the current xterm author). I have a terminal now that distinguishes any and all possible combinations of keypresses, and programs that understand it. Most of the programs I run regularly now do understand this - I can type Ctrl-I and Ctrl-Shift-A and so on absolutely fine. Vim is one of the few programs remaining that doesn't. (see attached screenshot-1). Vim - I am talking specifically about vim here - conflates the possible keypresses of Ctrl-I vs Tab, of Ctrl-M(or is it Ctrl-J I forget) and Enter, of Ctrl-H and Backspace. It further conflates Ctrl-S and Ctrl-Shift-S, etc etc... And lets not get started on Unicode vs. Alt-letters. Blaming terminals for this is just deflecting from the fact that vim's internals aren't sufficiently generic to represent the possible keypresses, regardless of how they arrive. That 1980s-style terminals couldn't do it is one thing but that is no excuse that a 2014-style GTK/Win32-driven GUI program cannot. You cannot reply to the original poster of this email and claim that it works, until you can perform the following test IN GVIM to demonstrate it so. :imap Tab You typed tab :imap C-i You typed Ctrl-I :imap C-S-I You typed Ctrl-Shift-I Then press all three keypresses and show it inserting different text. Do this in gvim, so as to avoid any reason to blame the terminal. For me, right now in GTK2-driven gvim, I get the Ctrl-Shift-I version all three times. (see attached screenshot-2) Only when that works can you reply to the OP and say this works. 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 something different. Your page doesn't say how to switch between the old mode, where CTRL-I produces a 0x09 character, and one where it produces a different character. This is required for the terminal to be used with programs that do not support the new codes. One can't expect to have all programs that a user uses to suddenly accept the new characters, thus a switch between two modes is required. Vim could switch to the new mode and take care of a default set of mappings to the old meaning. That's a lot of work though. Also, I don't see any note about different language keyboards. There are many, and the mechanism should work for all, with proper documentation what happens for different keyboards. Also, I don't see anything for keypad keys, the numlock key and other keys that some keyboards have that change what other keys mean. -- hundred-and-one symptoms of being an internet addict: 226. You sit down at the computer right after dinner and your spouse says See you in the morning. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/
Re: Dear Bram
On Mon, 06 Oct 2014 17:54:47 +0200 Bram Moolenaar b...@moolenaar.net 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 something different. Don't forget that users tomorrow want to rely on CTRL-I doing something differently to Tab. Your page doesn't say how to switch between the old mode, where CTRL-I produces a 0x09 character, and one where it produces a different character. This is required for the terminal to be used with programs that do not support the new codes. One can't expect to have all programs that a user uses to suddenly accept the new characters, thus a switch between two modes is required. Ahyes; I suppose it should probably use a mode setting, to enable it and default off until some application wanted to enable it. I'll give that some thought - hopefully Thomas and I can find a suitable mode number for it. In any case, I suspect that's going to be a minor cornercase of the specific keys of Ctrl-I, Ctrl-H and Ctrl-J overlapping with Tab/Backspace/Enter. The remaining ones, like Ctrl-Shift-A, Alt-letter, etc... are already key combinations that people won't be typing unless they mean it. And lets not forget that already for years, terminals have been sending such key events like Ctrl-Shift-Up as CSI 1;6 A and thus confusing most input systems pre-existing. Already vim handles these with the * hack. I'd love to see the if $TERM==xterm then use the * hack code replaced with a nice proper generic CSI parser, which will then understand these sequences. If nothing else, vim should at least recognise an incoming CSI 65;5u when it sees it as being Ctrl-A, rather than its current behaviour of getting confused, beeping, leaving insert mode, repeating the last t motion 65 times, then undoing my last 5 changes. That isn't helpful in the slightest. Even if you do nothing else from this discussion, I wouldn't mind if you made vim handle these CSI encodings a little better - undoing my last 5 changes is never what I wanted to happen :) There's surely no danger in interpreting these incoming sequences correctly /if/ you happen to see them - whether or not you see them is then up to the terminal. Vim could switch to the new mode and take care of a default set of mappings to the old meaning. That's a lot of work though. I'd be happy to write you a set of default :map/:map! commands to remap the new to the old, if that would work. Also, I don't see any note about different language keyboards. There are many, and the mechanism should work for all, with proper documentation what happens for different keyboards. Also, I don't see anything for keypad keys, the numlock key and other keys that some keyboards have that change what other keys mean. Numberlock has no bearing on this - numberlock is what is used to change the number keypad between cursor/application sense, and plain number sense. In effect, with numberlock on the numberpad should act identically to the regular number keys; with it off it should act identically to the cursor control keys. As to other language keyboards I'm not quite sure what concern you have here. Other language layouts add new Unicode symbols that wouldn't otherwise be accessible - this scheme already copes just fine with Unicode. E.g. if you now find yourself with a real Ä (U+00e4 / U+00c4) key, that's no problem. U+00c4 is 196 decimal. Ctrl-Ä, for example, is then represented by CSI 196;5u. Does this answer your concern, or is there still something remaining here? -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
On Mon, 06 Oct 2014 18:11:19 +0200 Bram Moolenaar b...@moolenaar.net 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 for existing mappings to keep working. It will still break when someone tries to overrule a mapping for Tab with a mapping for CTRL-I though. Hopefully that doesn't happen very often. That sounds like an excellent first step. Doubly-so would be if, even on a terminal, I could write one of my many hacky 'map the byte sequences' fixes, to teach vim how to read the incoming keypresses. I.e. if I could then :map ^[[105;5u Ctrl-i :map ^[[73;5u Ctrl-I then at least vim would recognise that I had typed a Ctrl-i, instead of undoing my last 5 changes. I mean, I could write that map right this very second, but without the feature named above I'd have nothing to map it /to/ on the RHS. On a more general note though, I find the idea of using :map on byte sequences to teach vim about new keypresses that aren't programmed in to be unsatisfactory. It gets upset with timing, and it doesn't apply during 'paste mode. Would it be possible to define a more robust mechanism for doing these kinds of fixes? -- Paul LeoNerd Evans leon...@leonerd.org.uk http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS signature.asc Description: PGP signature
Re: Dear Bram
Paul Evans wrote:
On Mon, 06 Oct 2014 17:54:47 +0200
Bram Moolenaar b...@moolenaar.net 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 something different.
Don't forget that users tomorrow want to rely on CTRL-I doing something
differently to Tab.
Your page doesn't say how to switch between the old mode, where CTRL-I
produces a 0x09 character, and one where it produces a different
character. This is required for the terminal to be used with programs
that do not support the new codes. One can't expect to have all
programs that a user uses to suddenly accept the new characters, thus
a switch between two modes is required.
Ahyes; I suppose it should probably use a mode setting, to enable it
and default off until some application wanted to enable it. I'll give
that some thought - hopefully Thomas and I can find a suitable mode
number for it.
It might very well make the difference between nobody switching over
and this becoming a widespread feature.
In any case, I suspect that's going to be a minor cornercase of the
specific keys of Ctrl-I, Ctrl-H and Ctrl-J overlapping with
Tab/Backspace/Enter. The remaining ones, like Ctrl-Shift-A, Alt-letter,
etc... are already key combinations that people won't be typing unless
they mean it. And lets not forget that already for years, terminals
have been sending such key events like Ctrl-Shift-Up as CSI 1;6 A and
thus confusing most input systems pre-existing. Already vim handles
these with the * hack. I'd love to see the if $TERM==xterm then use
the * hack code replaced with a nice proper generic CSI parser, which
will then understand these sequences.
If nothing else, vim should at least recognise an incoming
CSI 65;5u
:map Esc[65;5u {whatever}
when it sees it as being Ctrl-A, rather than its current behaviour of
getting confused, beeping, leaving insert mode, repeating the last t
motion 65 times, then undoing my last 5 changes. That isn't helpful in
the slightest.
Even if you do nothing else from this discussion, I wouldn't mind if
you made vim handle these CSI encodings a little better - undoing my
last 5 changes is never what I wanted to happen :) There's surely no
danger in interpreting these incoming sequences correctly /if/ you
happen to see them - whether or not you see them is then up to the
terminal.
I haven't heard anybody ask for ignore unrecognized keys (which
technically means CSI sequences). I don't think it's much of a problem.
But it would be possible to optionally do this.
Vim could switch to the new
mode and take care of a default set of mappings to the old meaning.
That's a lot of work though.
I'd be happy to write you a set of default :map/:map! commands to remap
the new to the old, if that would work.
Also, I don't see any note about different language keyboards. There
are many, and the mechanism should work for all, with proper
documentation what happens for different keyboards. Also, I don't see
anything for keypad keys, the numlock key and other keys that some
keyboards have that change what other keys mean.
Numberlock has no bearing on this - numberlock is what is used to
change the number keypad between cursor/application sense, and plain
number sense. In effect, with numberlock on the numberpad should act
identically to the regular number keys; with it off it should act
identically to the cursor control keys.
As to other language keyboards I'm not quite sure what concern you have
here. Other language layouts add new Unicode symbols that wouldn't
otherwise be accessible - this scheme already copes just fine with
Unicode. E.g. if you now find yourself with a real Ä (U+00e4 / U+00c4)
key, that's no problem. U+00c4 is 196 decimal. Ctrl-Ä, for example, is
then represented by CSI 196;5u. Does this answer your concern, or is
there still something remaining here?
Just like key combinations with CTRL, ALT and SHIFT may be used for
something else, different keyboard layouts provide different keys that
users may want to use for something else. And these should match the
labels on the keys, of course. It might be something that's
added later, but it must certainly be thought of from the start. E.g.
for the modifiers that are possible. E.g. Mac has the CMD key.
Note that the SHIFT modifier must be supported, but depending on what
key it's used with it may be included in the base character. That's one
of the areas where things get complicated: is CTRL-I the I key with
SHIFT and CTRL pressed or not? This gets even more complicated for
keyboard layouts where special characters are not on same keys. Where
CTRL-8 means something on one keyboard, another keyboard has it on
CTRL-9. A user could set it up for one keyboard layout, but sharing
that to users on
Re: Dear Bram
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 much invested in Python 2.6 however, so they stayed with that (and bug fixes continu on that version, but the new stuff is in Python3) Very many people have not made the switch from Pyton 2 to Python 3. Now most systems have to provide both 2 and 3, and libraries come in two versions. In my opinion this indicates the break in compatibility was a not a good choice. Also because the advantages of being incompatible are quite small. Vim broke with Vi (see: set nocompatible) yet was successful. Vim is Vi compatible when needed. I don't think Vim would have got this far without that. Vim8 with a 21st century input mechanism, can do the same. Road map: *Move official Vim8 (call it V8) onto GitHub. That gives close to nothing extra. Certainly for end users. *Set design goals: - Keep it CharityWare (above all else) - New input engine I have seen no reason for this. Most likely it's just going to replace one problem with another. - Wall to wall UTF-8 support Vim already supports utf-8 very well. Of course there are improvements possible, but so are there for many other features. E.g. better support for plugins. - Wall to wall Python3 scripting. Already present. [...] -- hundred-and-one symptoms of being an internet addict: 232. You start conversations with, Have you gotten an ISDN line? /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 terminal. http://www.leonerd.org.uk/hacks/fixterms/ Does that mean, I can have xterm already configured in such a way, so that it outputs those special CSI sequences? What version does that need and how do I enable it? Best, Christian -- Zu Dorlar einem Dorf an der Lahn nicht weit von Gießen haben fast alle Leute rote Haare. -- Georg Christoph Lichtenberg -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 Record) system. Although I have been using Vim for a long time, I still have not gotten used to the hjkl directional mapping. (I am 50, so I reserve the right to be cranky about stuff...) I have modified my .vimrc to give me an inverted-T in normal mode (jkl with i on top), but I want to be able to move around in insert mode with corresponding Ctrl- modified map. We all know where this goes.. As a tool Vim is very impressive, fast and infinitely customizable. It is however hamstrung to a certain degree by it's origins. (I don't think it was bad engineering... it had to be made to work with the technology of the moment.) I think that if Vim were to be fixed (some will say it isn't broken... I disagree) it would be used by many more people. To all those who have contributed to Vim, I say Thank You. We all just want to make it a better tool. Not sure what your problem is. This works just fine: imap C-I Up imap C-J Left imap C-k Down imap C-l Right It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. Perhaps you were complaining about terminal emulators? -- If evolution theories are correct, humans will soon grow a third hand for operating the mouse. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 work and dedication to this fine tool! Michael Longval, MD On Oct 4, 2014, at 09:43, Bram Moolenaar b...@moolenaar.net wrote: 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 Record) system. Although I have been using Vim for a long time, I still have not gotten used to the hjkl directional mapping. (I am 50, so I reserve the right to be cranky about stuff...) I have modified my .vimrc to give me an inverted-T in normal mode (jkl with i on top), but I want to be able to move around in insert mode with corresponding Ctrl- modified map. We all know where this goes.. As a tool Vim is very impressive, fast and infinitely customizable. It is however hamstrung to a certain degree by it's origins. (I don't think it was bad engineering... it had to be made to work with the technology of the moment.) I think that if Vim were to be fixed (some will say it isn't broken... I disagree) it would be used by many more people. To all those who have contributed to Vim, I say Thank You. We all just want to make it a better tool. Not sure what your problem is. This works just fine: imap C-I Up imap C-J Left imap C-k Down imap C-l Right It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. Perhaps you were complaining about terminal emulators? -- If evolution theories are correct, humans will soon grow a third hand for operating the mouse. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 trus...@gmail.com 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 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. H for text object, moving between windows after pressing c-w uses IJKL, IJKL instead of HJKL after pressing Z in normal, etc. Basically every use case. I've got a couple left to do when I find some spare time for it. I need to redo them all non-recursively. IJKL makes so much incredible sense. But yeah, I use Ctrl+i to move the cursor, so pressing tab moves the cursor, which is annoying, so I've gotten used to Ctrl+n for autocompletion and Ctrl+t for tabbing, but as soon as this issue is fixed, I will gladly put my tab key back into use for tabbing and autocompletion. /#!/JoePea On Oct 3, 2014 4:41 PM, Michael Longval mlong...@gmail.com 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 Record) system. Although I have been using Vim for a long time, I still have not gotten used to the hjkl directional mapping. (I am 50, so I reserve the right to be cranky about stuff...) I have modified my .vimrc to give me an inverted-T in normal mode (jkl with i on top), but I want to be able to move around in insert mode with corresponding Ctrl- modified map. We all know where this goes.. As a tool Vim is very impressive, fast and infinitely customizable. It is however hamstrung to a certain degree by it's origins. (I don't think it was bad engineering... it had to be made to work with the technology of the moment.) I think that if Vim were to be fixed (some will say it isn't broken... I disagree) it would be used by many more people. To all those who have contributed to Vim, I say Thank You. We all just want to make it a better tool. Michael Longval -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups vim_dev group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/2bp9UdfZ63M/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups vim_dev group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/2bp9UdfZ63M/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 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. H for text object, moving between windows after pressing c-w uses IJKL, IJKL instead of HJKL after pressing Z in normal, etc. Basically every use case. I've got a couple left to do when I find some spare time for it. I need to redo them all non-recursively. IJKL makes so much incredible sense. But yeah, I use Ctrl+i to move the cursor, so pressing tab moves the cursor, which is annoying, so I've gotten used to Ctrl+n for autocompletion and Ctrl+t for tabbing, but as soon as this issue is fixed, I will gladly put my tab key back into use for tabbing and autocompletion. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
... 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 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 mlong...@gmail.com wrote: ... 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 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 --- You received this message because you are subscribed to a topic in the Google Groups vim_dev group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/2bp9UdfZ63M/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote: Not sure what your problem is. This works just fine: imap C-I Up It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. No, even GVIM does not differentiate between C-I and Tab; that's what's causing so many people grief, and is the motivation for redesigning Vim's input handling. ,[ demo ] | :imap C-I C-I | :imap Tab Tab | :imap C-I | i Tab Tab ` -- regards, ingo -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 sw...@ingo-karkat.de wrote: On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote: Not sure what your problem is. This works just fine: imap C-I Up It does require gvim, since a terminal doesn't make a difference between Tab and CTRL-I. No, even GVIM does not differentiate between C-I and Tab; that's what's causing so many people grief, and is the motivation for redesigning Vim's input handling. ,[ demo ] | :imap C-I C-I | :imap Tab Tab | :imap C-I | i Tab Tab ` -- regards, ingo -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups vim_dev group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/2bp9UdfZ63M/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 Vim for a long time, I still have not gotten used to the hjkl directional mapping. (I am 50, so I reserve the right to be cranky about stuff...) I have modified my .vimrc to give me an inverted-T in normal mode (jkl with i on top), but I want to be able to move around in insert mode with corresponding Ctrl- modified map. We all know where this goes.. As a tool Vim is very impressive, fast and infinitely customizable. It is however hamstrung to a certain degree by it's origins. (I don't think it was bad engineering... it had to be made to work with the technology of the moment.) I think that if Vim were to be fixed (some will say it isn't broken... I disagree) it would be used by many more people. To all those who have contributed to Vim, I say Thank You. We all just want to make it a better tool. Michael Longval -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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. H for text object, moving between windows after pressing c-w uses IJKL, IJKL instead of HJKL after pressing Z in normal, etc. Basically every use case. I've got a couple left to do when I find some spare time for it. I need to redo them all non-recursively. IJKL makes so much incredible sense. But yeah, I use Ctrl+i to move the cursor, so pressing tab moves the cursor, which is annoying, so I've gotten used to Ctrl+n for autocompletion and Ctrl+t for tabbing, but as soon as this issue is fixed, I will gladly put my tab key back into use for tabbing and autocompletion. /#!/JoePea On Oct 3, 2014 4:41 PM, Michael Longval mlong...@gmail.com 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 Record) system. Although I have been using Vim for a long time, I still have not gotten used to the hjkl directional mapping. (I am 50, so I reserve the right to be cranky about stuff...) I have modified my .vimrc to give me an inverted-T in normal mode (jkl with i on top), but I want to be able to move around in insert mode with corresponding Ctrl- modified map. We all know where this goes.. As a tool Vim is very impressive, fast and infinitely customizable. It is however hamstrung to a certain degree by it's origins. (I don't think it was bad engineering... it had to be made to work with the technology of the moment.) I think that if Vim were to be fixed (some will say it isn't broken... I disagree) it would be used by many more people. To all those who have contributed to Vim, I say Thank You. We all just want to make it a better tool. Michael Longval -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups vim_dev group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/2bp9UdfZ63M/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Dear Bram
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 enough to become reality. The day the
option appears in Vim, I'll put it at the top of my .vimrc :-)
So we add an option that breaks mappings? No, not a good plan.
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 the codes for Tab
key and C-I are distinguishable.
Also, I'm not familiar with all the inner workings of Vim, so
the suggestions below might be laughable to those with better
understanding. So I thought I'd try to clarify it some more.
Worst-case, I figure at least you'll get a laugh :-)
Today, users that have both :map Tab and :map C-I will find
that the most recently defined map clobbers the other, because
Vim aliases them even in the definition of the mappings. I'd
like to see Vim eliminate the enforced aliasing at this layer
(the :map layer) for several reasons.
I think new users do not find this aliasing intuitive. There is
no intuitive reason why pressing CTRL-I should be the same thing
as pressing Tab, unless you have a priori knowledge of terminal
history.
If a terminal has a separate Tab key with a key code that is
distinguishable from the key code for CTRL-I, I'd like those
keys to remain distinguishable as Vim processes them. As much
as possible, I'd like each key on my keyboard to be uniquely
recognizable to Vim, so that I get maximum value out of these
keys. Personally, I don't get any benefit from the fact that
the Tab key is just another way of pressing CTRL-I. Though
people have found a way to get some benefit out of this aliasing
that is forced upon us by many current terminals, it seems like
a mis-feature for Vim to force it as well. Users that want two
keys to be aliases can give them identical mappings. But users
that want to treat them separately can't do it as long as Vim
aliases them under the hood.
A terminal that sends identical key codes for different key
presses is not as flexible as one that sends unique codes. We
have to deal with terminals as they exist today, which means we
have to handle hardware aliasing of Tab and CTRL-I (for
example). What if Vim were to handle this in the early stages
of terminal input, by decoding a given key code into a set of
keys aliases specific to the terminal's capabilities? So for
this particular terminal, ASCII code 9 would be translated to
the set {Tab, C-I}. Mappings would match if the mapping's
key is in the set of aliases returned from the terminal layer.
So if the user has mapped only one of Tab and C-I, Vim will
use that mapping. Vim might search mappings in reverse order of
definition so that a more recent mapping will win out in the
event of a tie. That way, a user can control on a per-mapping
basis which alias will win out in a given mapping mode.
I hope that the suggested changes above would be transparent to
most users, but there would be ways that users could detect
things were different (for example, by setting a mapping for
C-I and trying to query that same mapping using Tab). I
don't see a way to make it 100% transparent without leaving some
vestige of baked-in aliasing, which I feel should ideally be
removed everywhere except in the early terminal-handling stages;
that way, when we get terminals without inherent aliasing, we
can be rid of the aliasing problem entirely.
So the purpose of the option I was proposing was to
control whether Vim would continue to alias certain key
combinations at the point of mapping.
It's already implemented that a key-with-modifiers that is not
mapped falls back to the key-without-modifiers. There is no
reason to make it more complicated for the user who hasn't
read all the documentation of all options (hint: nobody has).
It's interesting that Vim treats a key-with-modifiers that has
no mapping as that same key without modifiers. I'm not sure I
understand how that works, nor why it's considered desirable. I
especially don't see how having that fall-back makes things less
complicated for users that haven't read the documentation. In
my way of thinking, the intuitive behavior for a keyboard is
that two different keys generally perform two different
behaviors (unless they are labeled the same, such as the two
Enter keys on a typical PC keyboard).
If Vim were changed to distinguish key names like Tab and
C-I throughout most of the code base, and to deal with
terminals that do not have unique key codes by return a set of
aliases for a given key press, I suspect that most users would
not notice any negative effects. If that level of compatibility
were good enough, then we wouldn't need any
Re: Dear Bram
Michael Henry wrote: On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar b...@moolenaar.net 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 encouraging to me. I read this as 100% compatibility out-of-the-box, which is a fine (and longstanding) goal for Vim. I'd be happy to have a Vim option to control this feature. It could default to providing 100% compatible key processing. If the user changes this option, he would get clean support for key modifiers with some slight backward incompatibilities. For example, the aliasing of control keys (e.g., CTRL-I being equivalent to Tab) is a historical artifact that I suspect has no value to the vast majority of users. If there were no compatibility concern and it's weren't *already* true that CTRL-I aliases Tab, would anyone seriously argue that we ought to *add* that feature to Vim? I suspect not. To me, that's a convincing argument to do the simplest possible kind of backward compatibility, since very few users actually need the old behavior. 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 enough to become reality. The day the option appears in Vim, I'll put it at the top of my .vimrc :-) So we add an option that breaks mappings? No, not a good plan. It's already implemented that a key-with-modifiers that is not mapped falls back to the key-without-modifiers. There is no reason to make it more complicated for the user who hasn't read all the documentation of all options (hint: nobody has). -- ARTHUR: What does it say? BROTHER MAYNARD: It reads ... Here may be found the last words of Joseph of Aramathea. He who is valorous and pure of heart may find the Holy Grail in the arrggghhh... ARTHUR: What? BROTHER MAYNARD: The Arrggghhh... Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Oct 28, 2013 3:41 PM, Bram Moolenaar b...@moolenaar.net wrote: Michael Henry wrote: On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar b...@moolenaar.net 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 encouraging to me. I read this as 100% compatibility out-of-the-box, which is a fine (and longstanding) goal for Vim. I'd be happy to have a Vim option to control this feature. It could default to providing 100% compatible key processing. If the user changes this option, he would get clean support for key modifiers with some slight backward incompatibilities. For example, the aliasing of control keys (e.g., CTRL-I being equivalent to Tab) is a historical artifact that I suspect has no value to the vast majority of users. If there were no compatibility concern and it's weren't *already* true that CTRL-I aliases Tab, would anyone seriously argue that we ought to *add* that feature to Vim? I suspect not. To me, that's a convincing argument to do the simplest possible kind of backward compatibility, since very few users actually need the old behavior. 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 enough to become reality. The day the option appears in Vim, I'll put it at the top of my .vimrc :-) So we add an option that breaks mappings? No, not a good plan. It's already implemented that a key-with-modifiers that is not mapped falls back to the key-without-modifiers. There is no reason to make it more complicated for the user who hasn't read all the documentation of all options (hint: nobody has). I have. Though can't say I remember it all. -- ARTHUR: What does it say? BROTHER MAYNARD: It reads ... Here may be found the last words of Joseph of Aramathea. He who is valorous and pure of heart may find the Holy Grail in the arrggghhh... ARTHUR: What? BROTHER MAYNARD: The Arrggghhh... Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/\\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
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 package library once we start using it. With some lag, greater as this library will likely be optional, but add. If this is handled similarly to the way Vim deals with other features, a hypothetical extra library would be required only for users that enable the feature. As I routinely rebuild Vim anyway, I'd be delighted to install an extra library or two to gain this feature. Once the feature becomes well-supported and its worth proven, distro maintainers will get requests to enable this feature in Vim, and they'll start packaging any dependent libraries accordingly. But even if they cannot be convinced to support this feature, users like myself will still have the benefits (which are substantial, IMO). Michael Henry -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar b...@moolenaar.net 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 encouraging to me. I read this as 100% compatibility out-of-the-box, which is a fine (and longstanding) goal for Vim. I'd be happy to have a Vim option to control this feature. It could default to providing 100% compatible key processing. If the user changes this option, he would get clean support for key modifiers with some slight backward incompatibilities. For example, the aliasing of control keys (e.g., CTRL-I being equivalent to Tab) is a historical artifact that I suspect has no value to the vast majority of users. If there were no compatibility concern and it's weren't *already* true that CTRL-I aliases Tab, would anyone seriously argue that we ought to *add* that feature to Vim? I suspect not. To me, that's a convincing argument to do the simplest possible kind of backward compatibility, since very few users actually need the old behavior. 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 enough to become reality. The day the option appears in Vim, I'll put it at the top of my .vimrc :-) Michael Henry -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Sat, 26 Oct 2013 18:46:22 -0700 /#!/JoePea trus...@gmail.com 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 tab :echo hellocr Let me describe how the current behavior works and two possible ways the future behavior would work. Currently, pressing tab or pressing c-i will echo hello. *1) The first way this could work in the future*, when vim differentiates ever key combination, is that pressing tab or pressing c-i would continue to echo hello. However, the user could override the default c-i behavior by adding a new map in which case c-i would take on an all-new behavior: map tab :echo hellocr map c-i :echo worldcr c-i would no longer echo hello, it would echo world. The same would apply to other aliases. I feel this would be best. The /vast/ majority of vim users (at least, if #vim on Freenode is anything to go by) would find that more intuitive and correct; most aren't even aware of the Tab == C-i identity anyway. Those few people who do rely on C-i actually meaning the same as Tab will know enough to double-map them anyway. Most new users to vim are also new to terminals, and therefore they (like me) won't know that pressing tab is the same as pressing c-i. They'll discover this after having pulled their hair out over a c-i mapping in their vimrc. Indeed. 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 agree this might be tricky and not fully supported in terminals at first, but we should at least have this new functionality fully supported in graphical Vim. As Paul said, it's likely that if vim implements this new functionality, many terminal developers will incorporate support for the new key sequences within due time. If at least one terminal emulator supports it, I'll be extremely happy! Hell, if all else fails, you can just copy-paste my libtermkey sources directly into the vim tree - I specifically allow that sort of thing by it having the MIT licence. In case that isn't sufficient I will specifically state that now: I will allow you to copy the libtermkey sources into vim, alter or modify them, and use them in any way you see fit in order to make this feature work. Initial research on a new blank vim looks promising. While it won't recognise the keys you press, it does at least allow storing of 'map's for them: C-S-i Again C-i World Tab Hello C-m Again C-j World Enter Hello Curiously, while it can handle é vs M-C and A-C, it does seem to consider M- and A- distinct: M-C World A-C Hello é Again -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Dear Bram
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 b...@moolenaar.net 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 encouraging to me. I read this as 100% compatibility out-of-the-box, which is a fine (and longstanding) goal for Vim. I'd be happy to have a Vim option to control this feature. It could default to providing 100% compatible key processing. If the user changes this option, he would get clean support for key modifiers with some slight backward incompatibilities. For example, the aliasing of control keys (e.g., CTRL-I being equivalent to Tab) is a historical artifact that I suspect has no value to the vast majority of users. If there were no compatibility concern and it's weren't *already* true that CTRL-I aliases Tab, would anyone seriously argue that we ought to *add* that feature to Vim? I suspect not. To me, that's a convincing argument to do the simplest possible kind of backward compatibility, since very few users actually need the old behavior. 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. Also some users (including me) are used to use Ctrl-I and Tab interchangeably. It is not much problem to restore old status if C-i and Tab started to have different meaning even without any options for backwards compatibility, thus I would not object against patch that will diversify them. I do not get though why C-B and C-S-B should ever have the same meaning though, and it is what is meant by “100% backwards compatibility”. 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 enough to become reality. The day the option appears in Vim, I'll put it at the top of my .vimrc :-) I doubt that adding some option will simplify implementation. This option (if implemented) is also much likely a candidate for resetting when 'compatible' is reset. Thus adding it at the very top is not a good idea if you have `set nocompatible` there. And it is good to have `:scriptencoding utf-8` as the very first line in the vimrc. Michael Henry -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Sun, 27 Oct 2013 10:38:09 -0700 (PDT) ZyX zyx@gmail.com 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 write a :map from F12, but some terminals lack an F12 key. Vim has no problem storing maps from keys it knows the terminal cannot possibly generate. If users are mapping from keys their terminal cannot type that is their problem. I do not get though why C-B and C-S-B should ever have the same meaning though, and it is what is meant by “100% backwards compatibility”. Indeed. I doubt very much anyone has ever tried to map from C-S-B, for example, without being quite aware that it wasn't C-B. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Dear Bram
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 not all. This is not simply historical artifact. You can't. Does that matter? Some people write a :map from F12, but some terminals lack an F12 key. Vim has no problem storing maps from keys it knows the terminal cannot possibly generate. If users are mapping from keys their terminal cannot type that is their problem. I'll tell you what the real problem is. It's bare-faced arrogance like this that all users who don't fit into the ideas of the vocal few obviously have a problem. I think he's saying that if your terminal cannot tell a C-I from a Tab, then neither will Vim be able to. And that if a user tries mapping them separately but the terminal cannot actually send a Tab that differs from C-I then it is the user's fault for using a dumb terminal while trying to use this feature in Vim. I'll tell you one good reason why people are mapping keys from their terminal that that cannot physically type, and that is keyboard remote control (synergy, virtual machine environments, etc.). I, for one, have all my F-keys mapped up onto other keys because the host system I am using to remote control intercepts all the F- keys before they get passed onto the remote system, so I have to map them up. And you'll be able to continue doing this. Nobody is suggesting removing the ability to: :nmap A-F1 F1 :nmap A-F2 F2 etc. (or the reverse, I'm not 100% sure what you mean by map them up) What is being suggested is that you could do: :nnore Tab :echo helloCR :nnore C-I :echo worldCR If you want C-I and Tab to do the same thing, then do this instead: :nmap C-I Tab or this: :nnore C-I :DoSomethingCR :nnore Tab :DoSomethingCR Additionally, TAB, for example, in Japan can be a language input modifier key for switching between kanji/kana and Roman alphabet. Some keyboards have an additional dedicated key for this but not all do. On a remote link you may have to use Ctrl+I to get a tab character to come out as the tab key locally can be intercepted at a very low level by Japanese (or other foreign) operating systems. I do not believe I am the only one who uses keyboard/mouse remote control to another system and edits a file in ViM, nor am I the only one who uses a computer in more than one language and uses VIM keyboard mappings to circumvent local system inadequacies with regards to multi-lingual support. However, as I guarantee that most of these other people don't hang out on #vim for most of their lives I take the view that the vast majority of ViM users (including myself) would be annoyed if their keyboard mappings just suddenly stopped working because of a few who can't see beyond their English- only QWERTY-compliant wire-connected keyboards. I'm not sure whether there are more people surprised by the inability to map C-I separate from Tab, or whether there are more that would be frustrated that they must now manually map C-I to Tab. But I do know the first seems more logical to fix than the second. Since the second is the current behavior, then I suppose I'd support either having an option to turn this on (probably part of cpoptions), or better, falling back to the current behavior if no mappings exist. And yes, I mean NO mappings (of that synonymous pair). Because if you define a mapping for Tab and want C-I to trigger it, you could define a second C-I mapping in the same place. But if you want to keep the default behavior of Tab and still want to map C-I to something, you should not need to use two mappings to accomplish that. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
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 trus...@gmail.com 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 first commented this to vim-dev@). Thank you for being so persistent! We've yet to even receive agreement /that/ the problem really exists, let along agreement on /how/ to fix it, or heaven forbid, a patch to actually fix it. To provide evidence that this issue indeed troubles many people (especially newcomers to Vim), I've been meticulously tagging all related questions that regularly come up on Stack Overflow and related sites (by referencing Paul's name in my answers): https://www.google.com/search?q=site%3Astackoverflow.com%20%2B%22Ingo%20Karkat%22%20%22foremost%20Paul%20LeoNerd%20Evans%22 (about 29 results) https://www.google.com/search?q=site%3Asuperuser.com+%2B%22Ingo+Karkat%22+%22foremost+Paul+LeoNerd+Evans%22 (3 results) That's more than 30 confused and eventually disappointed users (over the past ~ 1.5 years). To regain momentum, I think it would help if Bram would briefly signal a willingness to consider this for a future Vim 8.0. Then, after a re-evaluation of the floated proposals, we'd hopefully agree on an approach and have some volunteers start implementing on a branch off 7.4. I'd be certainly willing to comment and try out patches. My personal motivation is that I'm running out of keys for short custom mappings :-) 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. 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. -- An indication you must be a manager: You feel sorry for Dilbert's boss. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
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, greater as this library will likely be optional, but add. -- An indication you must be a manager: You feel sorry for Dilbert's boss. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/\\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Sat, 26 Oct 2013 21:50:57 +0200 Bram Moolenaar b...@moolenaar.net 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 come in a CSI sequence, where the second numeric argument encodes the modifiers. CSI P1; P2 u--- Modified Unicode character P1 CSI 1; P2 [ABCDFH] --- Modified Up/Down/Right/Left/End/Home CSI 1; P2 [PQRS] --- Modified F1/F2/F3/F4 CSI P1; P2 ~--- Modified function key -- where the first few numbers encode 2 Ins 3 Del 5 PageUp 6 PageDown In each case P2 encodes 1 + modifier state as a bitmask, 1 = Shift, 2 = Alt, 4 = Ctrl; so P2 1 unmodified 2 S- 3 A- 4 A-S- 5 C- 6 C-S- 7 C-A- 8 C-A-S- All is explained on http://www.leonerd.org.uk/hacks/fixterms/ I don't /actually/ care so much whether I can map Ctrl-Shift-I or not, in vim; what I do care about is that vim understands THE BASIC PARSING OF A CSI SEQUENCE and doesn't go beep, leave insert mode, undo the last 5 changes now just because it got confused and saw a CSI nnn;5u encoding of a Ctrl-letter sequence. So please; even if vim doesn't do /anything/ with that modifier, I would like vim to be able to RECOGNISE a CSI sequence, and know that it DOES NOT STOP until the first character in the range 0x40-0x7e - no matter how many other digits or other symbols were found first. Without that, it means every single time my finger happens to slip and I type some unrecognised Ctrl- sequence currently, I instantly leave insert mode, undo the past 5 changes, and if I so much as press a -single- extra key now I am likely to branch the undo history and prevent my being able to redo those falsely-undone changes back in. This is getting /incredibly/ frustrating. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Dear Bram
On Sun, 27 Oct 2013 01:58:32 +0100 Paul LeoNerd Evans leon...@leonerd.org.uk 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 come in a CSI sequence, where the second numeric argument encodes the modifiers. CSI P1; P2 u--- Modified Unicode character P1 CSI 1; P2 [ABCDFH] --- Modified Up/Down/Right/Left/End/Home ... You already know this one Bram - vim /already/ recognises modified arrow keys when TERM=xterm. Just extend that logic to the remaining CSI-encoded keys, and accept CSI u as modified unicode and we're done. Just please don't hardcode it to only TERM=xterm, but accept it always. Or at the very least, also accept it under TERM=screen, TERM=tmux, or any other situation where it is likely these keys will come up; but ideally all terminals. Don't make it conditional. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Dear Bram
On Sat, Oct 26, 2013 at 12:50 PM, Bram Moolenaar b...@moolenaar.net 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 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 tab :echo hellocr Let me describe how the current behavior works and two possible ways the future behavior would work. Currently, pressing tab or pressing c-i will echo hello. *1) The first way this could work in the future*, when vim differentiates ever key combination, is that pressing tab or pressing c-i would continue to echo hello. However, the user could override the default c-i behavior by adding a new map in which case c-i would take on an all-new behavior: map tab :echo hellocr map c-i :echo worldcr c-i would no longer echo hello, it would echo world. The same would apply to other aliases. *2) The second way this could work in the future* is that all possible keys/combos that can be mapped never act as aliases to another key. If you make a single mapping map tab :echo hello.cr then tab will echo hello but c-i will not. In fact, c-i will do nothing at all because it is a new combination available to be mapped that has never been used before. Personally, I prefer the second possibility because it's cleaner, but the first possibility would be more backwards compatible. That being said, if we went with the second possibility, it'd wouldn't be a huge hassle for people to rewrite their mappings to use the literal keys instead of aliases, plus new users will never get confused because literal key mappings are simply intuitive. Most new users to vim are also new to terminals, and therefore they (like me) won't know that pressing tab is the same as pressing c-i. They'll discover this after having pulled their hair out over a c-i mapping in their vimrc. 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 agree this might be tricky and not fully supported in terminals at first, but we should at least have this new functionality fully supported in graphical Vim. As Paul said, it's likely that if vim implements this new functionality, many terminal developers will incorporate support for the new key sequences within due time. If at least one terminal emulator supports it, I'll be extremely happy! -- An indication you must be a manager: You feel sorry for Dilbert's boss. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/\\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups vim_dev group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/2bp9UdfZ63M/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Tue, 15 Oct 2013 14:01:16 -0700 /#!/JoePea trus...@gmail.com 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-facing black-box behaviour vim ought to be capable of providing on a terminal, but I've no idea how to go about making it do so. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Tue, 15 Oct 2013 12:03:41 -0700 (PDT) ZyX zyx@gmail.com 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 input queue internals are updated to support arbitrary key sequences, then it becomes trivial to attach something like my libtermkey to feed that input queue from the terminal. http://www.leonerd.org.uk/code/libtermkey/ The first hurdle is getting anyone sufficiently close-to-core to accept /that/ the problem needs fixing, and only thereafter to accept /how/. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Dear Bram
On Oct 16, 2013 4:43 PM, Paul LeoNerd leon...@leonerd.org.uk wrote: On Tue, 15 Oct 2013 12:03:41 -0700 (PDT) ZyX zyx@gmail.com 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 input queue internals are updated to support arbitrary key sequences, then it becomes trivial to attach something like my libtermkey to feed that input queue from the terminal. http://www.leonerd.org.uk/code/libtermkey/ The first hurdle is getting anyone sufficiently close-to-core to accept /that/ the problem needs fixing, and only thereafter to accept /how/. As far as I see discussion always stucks at discussing backward compatibility. My suggestion is that as we cannot make an agreement backward compatibility should be kept fully (regarding things like CTRL-I vs TAB, not undistinguishable CTRL-L and CTRL-SHIFT-L) and code should be written. Not continue discussing WTF we are going to do with tabs. Not trying to push backwards incompatibility. And not writing code that will be tricky like having something to specify here we mean Tab, here we mean CTRL-I and here we mean any of them which will likely mean having a bunch of hacks in mapping processing code. All these may be written later if needed. It is better to not have an agreement on what to do with Tabs and have a patch to the input system then both not have an agreement and not have patch. Also if you do not introduce incompatibility, but have written a patch without Bram explicitly writing that this patch will be accepted once written you have rather good chances to make it accepted with the support from community. If you do introduce incompatibility this will be more tricky. Also did not Bram already agree on the existence of the problem? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
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 LeoNerd leon...@leonerd.org.ukwrote: On Tue, 15 Oct 2013 14:01:16 -0700 /#!/JoePea trus...@gmail.com 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-facing black-box behaviour vim ought to be capable of providing on a terminal, but I've no idea how to go about making it do so. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
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 tab :echo does something *or* map c-i :echo does something to achieve the same exact thing. For the sake of simplicity, IMHO, users should be able to write exactly the same VimL (Vim Script), *but* the results would *not* achieve the same thing. The mappings would be taken literally. For example, the user can do map tab :echo does something *and* map c-i :echo does something *else* to achieve two different things. Simple. The user need not know anything about the inner implementation of vim, and there need not be anything new to learn about writing VimL (Vim Script) except that your mappings are taken literally and no mapping identifier is *ever* and alias to another identifier. Plain and simple. */#!/*JoePea On Wed, Oct 16, 2013 at 8:46 AM, Nikolay Pavlov zyx@gmail.com wrote: On Oct 16, 2013 4:43 PM, Paul LeoNerd leon...@leonerd.org.uk wrote: On Tue, 15 Oct 2013 12:03:41 -0700 (PDT) ZyX zyx@gmail.com 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 input queue internals are updated to support arbitrary key sequences, then it becomes trivial to attach something like my libtermkey to feed that input queue from the terminal. http://www.leonerd.org.uk/code/libtermkey/ The first hurdle is getting anyone sufficiently close-to-core to accept /that/ the problem needs fixing, and only thereafter to accept /how/. As far as I see discussion always stucks at discussing backward compatibility. My suggestion is that as we cannot make an agreement backward compatibility should be kept fully (regarding things like CTRL-I vs TAB, not undistinguishable CTRL-L and CTRL-SHIFT-L) and code should be written. Not continue discussing WTF we are going to do with tabs. Not trying to push backwards incompatibility. And not writing code that will be tricky like having something to specify here we mean Tab, here we mean CTRL-I and here we mean any of them which will likely mean having a bunch of hacks in mapping processing code. All these may be written later if needed. It is better to not have an agreement on what to do with Tabs and have a patch to the input system then both not have an agreement and not have patch. Also if you do not introduce incompatibility, but have written a patch without Bram explicitly writing that this patch will be accepted once written you have rather good chances to make it accepted with the support from community. If you do introduce incompatibility this will be more tricky. Also did not Bram already agree on the existence of the problem? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ -- -- 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 --- You received this message because you are subscribed to a topic in the Google Groups vim_dev group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/2bp9UdfZ63M/unsubscribe. To unsubscribe from this group and all its topics, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
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 Tab and
C-i the same while allowing to map them separately.
I think that these problems should have separate solutions. To solve 1. we must
solve two problems
1. Have an agreement for new escaping scheme for byte queue. I may suggest
taking some unused 80{C1}{C2} sequence and agreeing that
80{C1}{C2}{CMod}{Key}ETX means that
1. User pressed key named {Key} which is either a key name (like Up) or a
character in encoding with the exception that it cannot be control character.
Key name obviously must be normalized.
2. This key was pressed with modifiers {CMod} which contains a bit field:
Bit idx Meaning
7 Always 1. Does not allow byte to be zero.
6 Shift
5 Control
4 Alt
3 Win
2 Reserved (X11 definitely has something to fill it with, but I do
not know what. Super?)
1 Reserved.
0 Reserved.
// 0. ETX is simply an end-of-key marker.
3. Any key that can be represented with already existing 80{C1}{C2}
sequence *must* be represented with it. Control-{latin letter} without
additional modifiers *must* be represented with control character. Latin letter
without modifiers except for shift *must* be represented as itself. And so on:
existing scheme should be kept for compatibility.
2. Second problem is pure technical: someone must sit down and code this. Maybe
use some terminal library, maybe not. The main idea of p. 1. is that we need
*no* changes if we *not* want to support new functionality (this is mainly
needed not because someone may not want, but because we may be unable to find
developers to code this functionality into specific supported GUI).
Solving top 2. (backward compatibility) issue with the above agreement on
backwards compatibility in escaping may be deferred until there is an agreement
while continuing to work on more urgent problem with not mappable sequences. As
I mostly use ,{key} mappings and not control sequences I do not have a strong
opinion on what to do with this: Tab=C-i and Tab≠C-i are both fine,
though I got used to use Tab for completion and C-i as an opposite for
C-o (for consistency). Do not think this will change as built-in
functionality.
If we solve top 1. solving top 2. will be much more trivial unless found
agreement will be something insane, like DWIM behavior based on statistics of
Tab hits after typing C-i.
--
--
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
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Mon, Oct 14, 2013 at 6:32 AM, Paul LeoNerd leon...@leonerd.org.ukwrote: On Sun, 13 Oct 2013 14:00:15 -0700 (PDT) Joseph Pea trus...@gmail.com 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 This has been dragging on for years now (I think it was 8 years ago that I first commented this to vim-dev@). We've yet to even receive agreement /that/ the problem really exists, let along agreement on /how/ to fix it, or heaven forbid, a patch to actually fix it. Personally, I'm in favor of extending the existing modifier byte sequence (mentioned by Bram). I also like the idea of using up to 128 bit integers, and making sure that the higher bits are usually zero, and then use variable length encoding (also mentioned by Bram, with this reference link: code.google.com/apis/protocolbuffers/docs/encoding.html). I have a suggestion. Maybe vim can participate in Google Summer of Code and find students to work on this through a summer-long effort. Considering Bram's relation to Google, I'm sure Vim would have no problem being accepted as a participating organization in the Google Summer of Code. I think you, Paul Evans, would be a good choice for the mentor who would guide the students through the effort. It'd be a win-win situation because Google would get to help the open source community (let alone the best text editor ever [IMHO]), vim would get an awesome upgrade, everyone would be able to use every key possible to make Vim truly theirs, and Bram would be happy the students got supported for their academic efforts. * /#!/*JoePea -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dear Bram
On Sun, 13 Oct 2013 14:00:15 -0700 (PDT) Joseph Pea trus...@gmail.com 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 This has been dragging on for years now (I think it was 8 years ago that I first commented this to vim-dev@). We've yet to even receive agreement /that/ the problem really exists, let along agreement on /how/ to fix it, or heaven forbid, a patch to actually fix it. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature
Re: Dear Bram
I 18th this effort. I've been using Vim since May this year and have run into this innocently trying to map c-i, c-h, and c-bs. Paul Evans suggested to use a modifiedunicode option (along with some other options) to enable the new features: :set nomodifiedunicode :map Tab ONE :map Ctrl-I TWO :set modifiedunicode and Bram said that it would be too complicated. I agree. Bram followed by suggesting a mapping prefix X- for the new mappings we all want: :map X-C-[ :echo CTRL-[CR :map X-C-I :echo CTRL-ICR But I also think that's still to complicated. The simplest solution (that Benjamin Haskell suggests in his previously mentioned table) is to make the keys map exactly how the user wants. map tab :echo tab key pressed map c-i :echo control plus I pressed map c-s-i :echo control shift I pressed map escc :echo escape c pressed map a+c :echo alt plus c pressed map é :echo eh? Users of the new vim will just simply have to change their mappings accordingly. If you were doing: map c-i :echo the real tab Well, don't.. Change it to: map tab :echo the real tab That's not too much to ask for, especially since the influx of new users aren't aware of these problems when they start using vim and will try literal mappings because it's intuitive. They will not map c-i thinking oh, now I've modified what tab does. No. They'll instead be thinking why on earth does ctrl+i not work. rrrghh? and pull their hair out. If you're someone who's used to doing map c-[ echo I've changed the escape key Well, then you'll just have to adapt. We live in a much more modern world. Adding options like modifiedunicode or prefixed map identifiers like x-c-[ is unnecessary. My .vimrc should simply *just work* the way i intend and expect when I map c-[. How this all gets implemented in the inner workings of vim is irrelevant when considering how .vimrc should behave. Doing imap c-bs :Whatevercr in .vimrc works just fine in gVim, as it should in console vim. So, basically, nothing needs to change in the way that I can currently write my .vimrc file (no new settings, no new mapping identifiers, just everything works). 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! -- -- 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 --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Supporting more key modifiers (was: Re: Dear Bram)
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 b...@moolenaar.net 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. 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 this work with Vim is a separate issue, I'll not go into that here. Actually, that's exactly the issue that is being addressed. Vim shouldn't have to address it -- in theory termcap/terminfo were supposed to do this, but they didn't really do so well. Which is why we now have difficulty telling the difference between ESCo and A-o, as well as things like ESC vs C-[. Ultimately the proposal is that we let the raw keyboard input (for terminals) be handled by libtermkey, and it figures out if what was pressed was ESC or c-[ or C-[o vs ESCo vs A-o. It then passes a stream of information to vim, which vim interprets properly. And yes, by default there would be a mapping (either explicit or pseudo-builtin) that treats ESC and C-[ as the same, but that can then be changed by the user, just as they can now with any other mapping. Then we need a way to make the extra information available to be used in mappings, without breaking it for users relying on the current way. The only breakage I can foresee is if someone actually does a :map c-i fooinstead of :map Tab foo -- then, yes, you'd end up with different behavior. I think this is within the realm of acceptable change, particularly if it's clearly stated in the release notes (and yes, I think this is a Vim 8 thing). Some things that are no acceptable: - Have a setting to enable the new way. This will break existing stuff and make users pull their hair out because they don't know this setting exists. Forget it. I actually agree -- it should be just the way things work. And if it's done right then it won't break anything (beyond the above). - Change the input queue from a stream of bytes to some list of structs. This isn't adding any functionality and breaks all kinds of mapping and termcode handling, register execution, etc. Forget it. The termcode handling will be replaced by this, so that's not an issue. Mapping is also not an issue beyond the above. Registers are more of an issue. No doubt. Can we think on this to come up with a solution? Perhaps the register needs to become more like a :map, with special keys expressed specially? Otherwise I think we're stuck since you cannot differentiate between ESC and c-[, and there's no way to express things like c-space. What we can do is extend the existing modifier byte sequence. This is a bit tricky, but it should work. So we add a new byte sequence with the raw key encoded, plus modifiers. Thus for CTRL-[ you get the [ key with the CTRL modifier. Which is precisely what libtermkey emits, and how it can differentiate between ctrl-[ and alt-ctrl-[, etc. Really what happens is that the terminal input buffer starts to look a great deal more like events that the GUI versions get. Instead of ESCo you get o with alt depressed. To be very clear -- some of this will depend on a terminal with the proper support being used. But anything that's built on libvterm already has that, as well as xterm. But if you don't have those then moving to this new scheme should not break ANYTHING. Your term would still send ESCo and libtermkey would tell vim it saw o with alt. But if you do have a terminal with the right support, or you're using the GUI... well, to quote a bit from :help design-multi-platform, Support all the keys on the keyboard for mapping. It would be great to get closer to that. Tom Sorensen -- 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
Re: Supporting more key modifiers (was: Re: Dear Bram)
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 Tab Ctrl-I Ctrl-Shift-I Escape C Alt+C é Yes I am aware that on current byte-driven terminals there is no way without using timing information to distinguish all these three cases in the latter triplet here. This should not stop GUI systems from distinguishing them however. Can someone (Bram?) tell us if Bram's proposed solution would allow us to map those triplets independently as wanted? I'm not familiar enough about vim's byte queue system to tell if the modifier byte really answers our needs here. Thanks. Philippe -- 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
Re: Dear Bram
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 Shift+ the top row of my typical US 105-key or variant: S-~ ! S-@ # $ % S-^ * ( ) S-_ + Backspace Why the Shift modifier on ~, @, ^, and _, but not !, #, $, etc? (Guessing hysterical raisins.) That sounds like a buggy implementation. Due to all the vagueness of what shift means in the context of Unicode (is ! really ! or is it Shift-1) my specification called for explicitly ignoring the state of the Shift key in the terminal, at the time the modified Unicode sequence is created. If that isn't happening, I vote bug. Didn't realize ECMA-48 existed, though. Thanks. It's essential in these matters. :) Once you read the spec part for CSI, you realise how short and neat the entire scheme really is, how extensible it is provided you actually have a real CSI parser and not a dumb string-prefix matcher a.la. termcap/terminfo/curses combinations. modifyOtherKeys: 2 Except that on its own now breaks most other applications, because xterm is too keen to use the CSI encoding scheme on normal keypresses, such as Ctrl-D. xterm doesn't yet send the correct and useful sequences here, but it is not difficult to fix its code to do so - I have been in occasional contact with Thomas Dickey on this issue; I need to poke him again sometime soon to check he's properly looking into it. Cool. Works as advertised (i.e. currently not in anything other than the `demo` program, but still interesting to see the ability is built in). I am also recently informed by Thomas Dickey that formatOtherKeys: 1 sends a slightly nicer CSI u rather than CSI 27~ encoding What is needed is a hybrid scheme, whereby the simplest key encoding is used in a nicer way; where Ctrl-D would send the single 0x04 byte (so kernel's pty driver can recognise here's an EOF), but Ctrl-Shift-D sends CSI 68;5 u to encode it correctly. How do Tab and Ctrl-i fit into this scheme? What's the simplest key encoding? Tab 0x08 (ASCII HT) Ctrl-ICSI 105;5u (i == 105 decimal in ASCII) Ctrl-Shift-I CSI 73;5u (I == 73 decimal in ASCII) Note that, due to what I said above, we have to ignore the shift key in these CSI u sequences; the distinction between Ctrl-I and Ctrl-Shift-I is simply that one is lowercase and one is capital. how would using libtermkey be anything less than a huge PITA when working on multiple systems that aren't so configured? Or is this a chicken-and-egg problem? (Nothing is configured to send anything other than 70's-style C-i == Tab, so nothing ever will be.) Rightnow, xterm will send the same byte for Tab, Ctrl-I or Ctrl-Shift-I. Setting modifyOtherKeys to 2 will send real keypresses that it can tell, but now everything else cannot. Ultimately, yes. It is chicken and egg, in order for -everything- to work in a happy shiney way. But even without terminal changes, applications can benefit from using libtermkey now. So to answer your question on how would using libtermkey be anything less than a huge PITA - it isn't. It already recognises, via its terminfo-driven parser, every keypress that terminfo/curses already recognises. It cannot be worse. It is strictly better than, because of the full CSI parser I mentioned above. Thanks. This paragraph combined with the first section about parsing unknown CSI sequences is plenty convincing. (trimmed rest) Another thought occurs to me. Run vim in xterm. It recognises Ctrl-Left, because vim handles TERM=xterm specially to recognise this case. Run vim in screen in xterm. It doesn't recognise Ctrl-Left, instead interpreting it as Escape, 1; (ignored), 5C. Deletes 5 lines of text and enters insert mode. Mass fail. Run libtermkey's demo either in xterm or in screen-in-xterm. Observe that Ctrl-Left works IN BOTH CASES. This is because it always applies its CSI parser, so always understands xterm-alike CSI encoding of Ctrl-Left (et.al.). This fact -alone- should be enough to convince you. :) -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Supporting more key modifiers (was: Re: Dear Bram)
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 this work with Vim is a separate issue, I'll not go into that here. 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 not most terminal emulators. I think this is a great move on xterm's part (having a more-or-less consistent set of escapes for modifiers). But, it's still a chicken-and-egg problem. Once it's in xterm, it takes a while (if ever) to filter down to derivatives. And even under xterm the setting that allows this to work isn't the default. I almost didn't send this, since I don't think the lack of terminal support should be a show stopper (If any terminal supports it, Vim should use that support), but claiming that it's a done deal because xterm added a feature to support it a few years ago is naïve. -- Best, 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
Re: Supporting more key modifiers (was: Re: Dear Bram)
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 not most terminal emulators. I think this is a great move on xterm's part (having a more-or-less consistent set of escapes for modifiers). But, it's still a chicken-and-egg problem. Once it's in xterm, it takes a while (if ever) to filter down to derivatives. And even under xterm the setting that allows this to work isn't the default. I almost didn't send this, since I don't think the lack of terminal support should be a show stopper (If any terminal supports it, Vim should use that support), but claiming that it's a done deal because xterm added a feature to support it a few years ago is naïve. This is regrettable, yes. But not entirely true. Until xterm added the extended CSI notation using the 2nd parameter for modifiers in e.g. CSI 1;5C for Ctrl-Left, no terminal in the world did it. Now, apart from rxvt which uses its own scheme, prettymuch every terminal does it, and does it -that way-. These things aren't completely set in stone, but they do take a long long time to filter around. I'm very keen to try to shepherd people into one standard and consistently-designed way of doing things. That rxvt does modified keys differently is regrettable, and a consequence of splintered reinvention of wheels. I'm very keen to try not to let that happen any more. It's to this end I tried initially writing this spec for modified keypresses: http://www.leonerd.org.uk/hacks/fixterms/ It comes a little whiney and amateur at the moment, because I'm no good at the social engineering side of trying to motivate a world-full of 1970's-era engineers into trying to fix a big problem. :) But the technical details are there, awaiting someone with better writing skills than I to neaten it up a bit. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Dear Bram
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 compatibility, without *needlessly* or *significantly* lowering efficiency, and without *unnecessarily* wasting people's time. Ah, sorry then. Yes I felt it a bit like a resistance to change. I've unfortunately seen this happen too often... thanks for setting me back on the right track :) So, to move it to the next stage, is anyone in a position to volunteer to write up a more specific design (which probably needs to be written with reference both to this email discussion and the Vim source code)? Also, is anyone in a position to volunteer to help with implementation once we have a design? I'd volunteer but I think the new post from Bram doesn't let a lot of room for work to do on the design part... I think he outlined a specific task to do (extend the existing modifier byte sequence) and put a big no on all the alternatives discussed. All-in-all if this answers the needs we have I'm for it, and it looks as a fairly easy task to do (compared to the struct rewrite). Philippe -- 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
Re: Dear Bram
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
there are many other problems to solve: right hand sides of mappings,
feedkeys(), registers for macro recordings (which indirectly affect
buffers, as registers must be able to be put and yanked), representation
in strings, and more (I just thought of the :normal command, and I'm
sure there is still more...). I pointed out that if you use the
structure to solve all these problems, memory efficiency is most
certainly a concern.
My response, to both that specific proposal and that general approach is
that I don't think it is a good way, because it is massively
backwards-incompatible and a lot of work.
But as a community member, I'd prefer it if it affected my code and
plugins as little as possible, and I consider it essential that Vim
doesn't become significantly less efficient because of this. And if it
were me considering an implementation, I'd certainly be looking for the
option that was the least work! YMMV.
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 mean I wouldn't care if vim went as far as
doubling its memory usage and broke backward compatibility if what I
gain in exchange is modernity, but I guess not everyone is like me. I
just think old hardware should use old software and that new hardware
should use new software, I understand backward compatibility is what
makes a software like vim able to run on my toaster, but I wouldn't
mind using an older version of vim on that toaster.
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:
if has('enhanced_input') == 0
echom 'Vim wasn't compiled with +enhanced_input, the plugin's
default mappings (C-i, etc) were remaped'
call s:UseOldMappings()
endif
I think this would please everyone. People wanting vim not to change a
single bit can, people wanting it to evolve can. Of course there's
still all the issues discussed above to solve, but at least I think
with this proposal things we'll get less resistance ;)
Thanks,
Philippe
--
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
Re: Dear Bram
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_compatible by default, or smth like that. Maybe this was already proposed tho. -- 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
Re: Dear Bram
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 wants to keep Vim in the 1970s. We all want this. In fact, people who don't want this probably wouldn't get involved in the discussion--unless we looked like we were going to introduce some horribly backwardly incompatible change that would affect them nastily. 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 compatibility, without *needlessly* or *significantly* lowering efficiency, and without *unnecessarily* wasting people's time. That said, I think there is a compromise. Unless you saw something that I didn't see, I don't think there is any resistance that necessitates a compromise. I think it goes without saying that we'll need some kind of compatibility mode, whether it's by means of a +feature, an 'option', or just some carefully thought-out behaviours. Some of these issues have already been raised and solutions brainstormed (including your recent suggestions, as well as in earlier mails by me and others). Of course there's still all the issues discussed above to solve, but at least I think with this proposal things we'll get less resistance ;) As I said, I don't think there is any resistance to the idea. We're just discussing how to do it. As someone suggested earlier, it would be best to discuss and draft some documentation for this stuff before doing the hard implementation work. Having something solid will help, and a checklist of issues/concerns along with their solutions. So, to move it to the next stage, is anyone in a position to volunteer to write up a more specific design (which probably needs to be written with reference both to this email discussion and the Vim source code)? Also, is anyone in a position to volunteer to help with implementation once we have a design? 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
Re: Dear Bram
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 thatTab andCTRL-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
Supporting more key modifiers (was: Re: Dear Bram)
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 keyboard problem. As Bram said it is internally set as CTRL-I = Tab and people requesting having structured input mechanism, all I can think of is to break apart all internal linkages and revert to the their original settings: I found that CTRL-M and Enter both have the same keymap code 0x0d, and both Tab and CTRL-I gives 0x09, maybe that is why vim gives the same output. [...] 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. 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 this work with Vim is a separate issue, I'll not go into that here. Then we need a way to make the extra information available to be used in mappings, without breaking it for users relying on the current way. Some things that are no acceptable: - Have a setting to enable the new way. This will break existing stuff and make users pull their hair out because they don't know this setting exists. Forget it. - Change the input queue from a stream of bytes to some list of structs. This isn't adding any functionality and breaks all kinds of mapping and termcode handling, register execution, etc. Forget it. What we can do is extend the existing modifier byte sequence. This is a bit tricky, but it should work. So we add a new byte sequence with the raw key encoded, plus modifiers. Thus for CTRL-[ you get the [ key with the CTRL modifier. When this new modifier is not mapped, it is discarded and the following translated codes are used normally, just like now. Thus without any mappings that use the new modifier it is guaranteed to work as before. When executing a register where the new modifiers are missing it works just like before. When a new modifier is mapped, it is replaced by what it's mapped to, AND the following old style byte sequence is consumed. An alternative is to let the termcap handling translate the new modifer into the old style key. That works because mappings are applied both to the raw escape sequences and on the key codes they are converted to. We also need a way to specify mappings with the new modifier, perhaps using a special modifier X, thus you could do: :map X-C-[ :echo CTRL-[CR :map X-C-I :echo CTRL-ICR -- Not too long ago, compress was something you did to garbage... /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- 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
Re: Dear Bram
The whole situation is pretty arbitrary. E.g. ./demo's output under a
modifyOtherKeys:2 UXTerm, compressed to one row, for Shift+ the top row of my
typical US 105-key or variant:
S-~ ! S-@ # $ % S-^ * ( ) S-_ + Backspace
Why the Shift modifier on ~, @, ^, and _, but not !, #, $, etc? (Guessing
hysterical raisins.)
This can't explain ~, but...
My guess is that these are keys which are low enough in ASCII that they
can be control keys. There should be 32 of them. A-Z makes 26, plus the
three above which are @ ^ and _, then there's [ ] and \, and that's it.
I guess you can test the theory and see if { } and | appear with shift
modifiers--though I guess they may not, since they actually generate
different characters. Still, would be interesting to know.
Maybe ~ by some other convention does something special with control.
IIRC, it is right down the other end of ASCII, at 126 or something.
Maybe it's equivalent to another one of the keys, if ctrl-a is the same
as ctrl-A, maybe ctrl-~ is equivalent to whatever is at
codepoint...126-32=94, which is definitely one of those symbols above...
It's strange, in my terminal, pressing ctrl-~ seems to do nothing,
whereas control with other 'non-control' characters makes a beep.
At any rate, since it's only these few keys which can be control
characters in the first place, it makes sense that these have the
special treatment, and the others don't.
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
Re: Dear Bram
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 ECMA-48 (whereas xterm extends it), inextensible beyond Ctrl and Shift, and arbitrary (happening to pick three ASCII characters seemingly at random, to represent the Shift, Ctrl and Ctrl+Shift states). And AFAIK, Vim doesn't deal with this. Does libtermkey or does it only do CSI stuff? It doesn't at the moment, but if someone wants to do the research into what sequences it sends, and write some code in the library (similar to driver-csi.c and driver-ti.c), I could add that in sure. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature
Re: Dear Bram
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 keyboard problem. As Bram
said it is internally set as CTRL-I = Tab and people requesting
having structured input mechanism, all I can think of is to break
apart all internal linkages and revert to the their original settings:
I found that CTRL-M and Enter both have the same keymap code 0x0d,
and both Tab and CTRL-I gives 0x09, maybe that is why vim gives
the same output.
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
A shortcut table could be made to map between Enter and L-CTRL
+M, and load when vim starts.
So the new process would be:
detecting Scan Codes -- map between Scan Codes to alias like
Enter or Tab
Different keyboards from different countries maybe need different Scan-
Codes-to-alias mapping layouts, and therefore many layout files.
I know it is more complicated than getting the keycode conveniently
from the system, but this is all I know to my understanding.
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.
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.
Sorry again if I gave useless suggestions.
Stephen
--
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
Re: Dear Bram
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 layouts) QWERTY.vim QWERTZ.vim AZERTY.vim QZERTY.vim Dvorak.vim Colemak.vim JCUKEN.vim Neo.vim Turkish.vim . . OR (Keyboard layout by Country Name) and there would be 4 files: QWERTYsequence.vim QWERTZsequence.vim QWERTYstructured.vim QWERTZstructured.vim OR (specific for your country) CzechQWERTYsequence.vim CzechQWERTZsequence.vim CzechQWERTYstructured.vim CzechQWERTZstructured.vim OR simply (having advantage of adding new keyboard layouts in future but disadvantage of difficult to find which is which when changing them in command) CzechLayoutA1.vim CzechLayoutA2.vim CzechLayoutB1.vim CzechLayoutB2.vim In .vimrc, there would be: set keyboardlayout= Maybe a step forward to change the layout on-the-fly by the following command (when changing keyboard setting in X window system): :set keyboardlayout=... I am not a programmer, but the concept is to make vim a converter and convert keys on-the-fly: Input --- vim(search and map in the layout file) --- output The concept is inspired by the following plugins: VimIM : Vim Input Method ywvim : Another input method(IM) for VIM, supports all modes and the Keyboard layout system in Windows because when inputting Chinese we rely heavily on mapping different keys so as to generate one Chinese character. All we need would be desiging 2 sets of clear layout files for every different kind of keyboard layout Hope this help. On Feb 21, 5:53 pm, Milan Vancura mi...@ucw.cz 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 function as a string in vimscript? Etc.. These are the kinds of issues I was trying to raise. Hi. Wouldn't be it same as now, only used more often? There is already a possibility to write F4 or S-Space. The only problem is that, at least the second, we can't press strongly enough to push it to vim :-) But, on the other hand, you are right there still will be (and must be) ambiguities. We can't do anything about that, in general - it's a user who must decide how does he want to understand his keyboard. For example: I, as Czech, have some Czech accented letters accessible via modifier+key on my keyboard. To make the example more specific, think about Mod5+s as s with hook (U0161) and redefined my keymap so Capslock key acts as Mod5. It's up to me, and only me, if I define some vim mapping as :map Mod5+S ...rhs... - or - :map U0161 ...rhs... Both do the same on my current keyboard but start to behave differently if I change my keyboard setting in X window system, of course. If I switched to another kind of Czech keyboard (called typewriter one), U0161 appears at a key of number 3 and Mod5 would be on right Alt or not defined at all. As I wrote above, we can't do anything about that, as far as I know. Milan -- Milan Vancura, Prague, Czech Republic, Europe -- 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
Re: Dear Bram
Hi. 2011/2/23 Stephen Lee stephenletter...@gmail.com: 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 layouts) QWERTY.vim ... Hum, as a user of a home-made variant of dvorak-bépo (because my keyboard, a kinesis, is *not* practical to use with standard bépo), I hope it's going to be easy to set up and modify such a setting, because you are not going to give an exhaustive list of all layouts… Cheers, P! -- Français, English, 日本語, 한국어 -- 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
Re: Dear Bram
On Feb 22, 8:55 pm, Adrien Pied Piérard axiopl...@gmail.com wrote: Hi. 2011/2/23 Stephen Lee stephenletter...@gmail.com: 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 layouts) QWERTY.vim ... Hum, as a user of a home-made variant of dvorak-bépo (because my keyboard, a kinesis, is *not* practical to use with standard bépo), I hope it's going to be easy to set up and modify such a setting, because you are not going to give an exhaustive list of all layouts… I'm really not sure how the discussion got to be about keyboard layouts. The proposal at hand is to replace Vim's input mechanism so that ANY key, modified or otherwise, coming from ANY keyboard, will work with Vim as a user would expect. Nobody is talking about forcing specific keyboard layouts. -- 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
Re: Dear Bram
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.. These are the kinds of issues I was trying to raise. Hi. Wouldn't be it same as now, only used more often? There is already a possibility to write F4 or S-Space. The only problem is that, at least the second, we can't press strongly enough to push it to vim :-) But, on the other hand, you are right there still will be (and must be) ambiguities. We can't do anything about that, in general - it's a user who must decide how does he want to understand his keyboard. For example: I, as Czech, have some Czech accented letters accessible via modifier+key on my keyboard. To make the example more specific, think about Mod5+s as s with hook (U0161) and redefined my keymap so Capslock key acts as Mod5. It's up to me, and only me, if I define some vim mapping as :map Mod5+S ...rhs... - or - :map U0161 ...rhs... Both do the same on my current keyboard but start to behave differently if I change my keyboard setting in X window system, of course. If I switched to another kind of Czech keyboard (called typewriter one), U0161 appears at a key of number 3 and Mod5 would be on right Alt or not defined at all. As I wrote above, we can't do anything about that, as far as I know. Milan -- Milan Vancura, Prague, Czech Republic, Europe -- 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
Re: Dear Bram
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.. These are the kinds of issues I was trying to raise. Well, I don't see what the problem is? Just do it like today, maybe with some expansions e.g C-AS-ITabsomecharsU-234. I mean this is simple key-as-text representation and then text-representation- to-struct creation no? For example, the user records a macro into register q that is then displayed as ihelloTabworlldEscLeftLeftx. He then edits the macro in a buffer, yanks it into register q, and when @q is executed all it does is interpret the string? We'll probably need some escape mechanism to differentiate between the text Tab and the tab key, but this looks fairly easy to find no? Wether it being a special byte before the block or some \ or whatever. Maybe I'm oversimplifying it but it'd help if you were more specific about the issues the new design have. To me it looks like we just need to agree on a new set of conventions by describing how the new system would work for all the current (and future) macros/registers/ whatever scenarios. I suggest maybe we make some kind of new design draft which would answer all the issues raised (memory size/1970 support/macros concerns) ? Philippe -- 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
Re: Dear Bram
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, but lists of keypresses.
They need the same amount of expressive power to work properly.
Yes. And the scheme I created is no less expressive than the byte
queues. In fact it is more expressive, able to disambiguate neatly
situations that cannot normally be represented - see also my other mail
on the thread a few minutes ago.
Yeah, there was never anything lacking in your scheme in terms of
expressive power. It's just that it's not only the input queue that
would need to use it. It's a lot more.
When macros are recorded, registers, which usually are primarily lists
of characters, are used to store keypresses. Likewise, for feedkeys() to
work, its input, a string, needs to be able to represent keypresses.
And I'm sure there are plenty more subtleties.
Yes - again, my point of these structures is that they exactly _do_
represent these keypresses.
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.. These are the kinds of issues I was trying to raise.
The bottom line, though, is that changing to a struct-based approach
could make the job absolutely huge, requiring reworking and/or
redesigning how maps, registers, etc. all work. And it might not even be
possible since, e.g. registers need to be able to do both characters and
keys.
But every character -can- be represented as a key - namely, the key that
generates it.
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!
Let me again repeat my structure:
struct keypress {
unsigned int is_special : 1;
unsigned int modifiers : 10;
unsigned int codepoint : 21;
};
Any character has a Unicode codepoint (cp). That's represented by
Well, a codepoint in whatever encoding you are using.
{ 0, 0, cp }
Any keypress has a symbolic key number, taken from some arbitrary
enumeration - I care not where.
{ 1, mod, key }
Now, we can also represent those modified Unicode keys such as Ctrl-I
and Shift-Space which previously were impossible:
{ 0, MOD_CTRL, 'i' }/* Ctrl-I */
{ 0, MOD_SHIFT, ' ' } /* Shift-Space */
Yeah. The benefit here is that different keyboard layouts can be
represented, e.g. keyboards which have single keys for accented
characters can represent those keys with modifiers, easily.
OK - well, if you feel confident that the existing prefix-escape
mechanism can completely an unambiguously represent all these possible
keystrokes, then sure, that way might result in less code change
overall.
I think with some careful design it could, which may well require some
reworking of how it's currently done. There is the issue, of course,
that 80 is a valid character in some encodings, too, and I don't know
if this is accounted for. It needs to be. So maybe the escape mechanism
needs to be a bit more formal (if it can be--but maybe there's no way
around this, or maybe that's a longer-term consideration). Definitely
the issues have to be bashed out. I still think this would be the
easiest and best way forward, though. But it's far from my call!
Regarding that whole meta issue that you raised earlier--I think, yes,
using an 8-bit-high representation for meta is completely out of the
question. Part of the input code should be transforming that to a proper
Vim-internal escape sequence for terminals that use it. Same for other
things. The input code should transform input into Vim's internal
representation which should be carefully designed not to be ambiguous,
etc., but which, nevertheless, is at its most fundamental, a byte stream
so it can be used in the input queue, mappings, registers, strings and
even buffers.
But do make quite sure it can represent them. Specifically consider the
two tricky special-cases I suggested - repeated here again:
Tab { 1, 0, KEY_TAB }
Ctrl-I { 0, MOD_CTRL, 'i' }
Ctrl-Shift-I { 0, MOD_CTRL, 'I' }
Escape C { 1, 0, KEY_ESCAPE }, { 0, 0, 'C' }
Alt+C{ 0, MOD_ALT, 'C' }
é{ 0, 0, 0xe9 }
Yes. This
Re: Dear Bram
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 macros, mappings or registers
simply store a list of bytes or a list of structures shouldn't change
anything: you just need an explicit mapping between a displayed
keypress and a byte or a struct (S-Up can map internally to \x80\xFD
\xAA or { 1, MOD_SHIFT, KEY_UP } and it shouldn't matter).
Structures just look more sane as they're more generic/expressive and
accurate about the problem, they also are easier to expand on.
Philippe
--
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
Re: Dear Bram
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 suggest the possibility for more similar options,
ways to optionally extend the featureset beyond its existing capability,
without upsetting people who rely on the current behaviour, limits and
all.
Wether we use structures or the byte 80 for special key is
implementation detail, I mean wether macros, mappings or registers
simply store a list of bytes or a list of structures shouldn't change
anything: you just need an explicit mapping between a displayed
keypress and a byte or a struct (S-Up can map internally to \x80\xFD
\xAA or { 1, MOD_SHIFT, KEY_UP } and it shouldn't matter).
Structures just look more sane as they're more generic/expressive and
accurate about the problem, they also are easier to expand on.
Another thought occurs to me: UTF-8 sequences vs. Alt keys.
I don't know if it's an accident of implementation, but I have never
been able to get them all working. Lets consider this example
é is U+00e9 in Unicode, encodes to two UTF-8 bytes C3 A9
C is U+0043 in Unicode, encodes to one UTF-8 byte 43
If vim simply uses an 8th-bit-high to indicate Alt+ prefix on simple
ASCII, then what does
C3
mean? Is it the first of two UTF-8 bytes, or is it Alt+C ?
Alternatively, perhaps we'll represent it as a two-byte sequence with an
Escape prefix. Now we've conflated someone typing Escape C from
someone typing Alt+C. Again, in the 1970s that may be what it was, but
these days it's far from clear from GUIs, that this behaviour is what's
wanted. Again, a simple 'set' option should default this:
:set noaltisescape (defaults to :set altisescape)
The reason I suggested a simple neat orthogonal structure representation
is that it can disambiguate all of the following cases in a clear
logical way; a way that can be easily fed from GUI events, and fed into
map tables or other internals.
Tab { 1, 0, KEY_TAB }
Ctrl-I { 0, MOD_CTRL, 'i' }
Ctrl-Shift-I { 0, MOD_CTRL, 'I' }
Escape C { 1, 0, KEY_ESCAPE }, { 0, 0, 'C' }
Alt+C{ 0, MOD_ALT, 'C' }
é{ 0, 0, 0xe9 }
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: Dear Bram
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 instance, the right hand
sides of mappings are not primarily characters, but lists of keypresses.
They need the same amount of expressive power to work properly.
Yes. And the scheme I created is no less expressive than the byte
queues. In fact it is more expressive, able to disambiguate neatly
situations that cannot normally be represented - see also my other mail
on the thread a few minutes ago.
http://groups.google.com/group/vim_dev/msg/7bb4cc9b127cddb3
When macros are recorded, registers, which usually are primarily lists
of characters, are used to store keypresses. Likewise, for feedkeys() to
work, its input, a string, needs to be able to represent keypresses.
And I'm sure there are plenty more subtleties.
Yes - again, my point of these structures is that they exactly _do_
represent these keypresses.
The bottom line, though, is that changing to a struct-based approach
could make the job absolutely huge, requiring reworking and/or
redesigning how maps, registers, etc. all work. And it might not even be
possible since, e.g. registers need to be able to do both characters and
keys.
But every character -can- be represented as a key - namely, the key that
generates it. Let me again repeat my structure:
struct keypress {
unsigned int is_special : 1;
unsigned int modifiers : 10;
unsigned int codepoint : 21;
};
Any character has a Unicode codepoint (cp). That's represented by
{ 0, 0, cp }
Any keypress has a symbolic key number, taken from some arbitrary
enumeration - I care not where.
{ 1, mod, key }
Now, we can also represent those modified Unicode keys such as Ctrl-I
and Shift-Space which previously were impossible:
{ 0, MOD_CTRL, 'i' }/* Ctrl-I */
{ 0, MOD_SHIFT, ' ' } /* Shift-Space */
It would be much simpler to extend the current approach which uses
an 'escape mechanism' for representing special keys. Just hit qq and
type some arrow keys, q to end recording, and then inspect register q
and you'll see what's going on here. Vim uses a byte 80 followed by
two more bytes to represent special keys.
IMHO, what needs to be done is for this to be tidied up and made
consistent and documented so that these codes can be more readily
generated, interpreted, and even viewed and understood by users (e.g.
when I do :registers, it would be nice to see S-Up rather than
80fd^D, when appropriate). Included in this is a clear specification
of what control characters mean, e.g. does ^I (09) mean tab or
control-I? And which of those keys can or does use the escape mechanism?
OK - well, if you feel confident that the existing prefix-escape
mechanism can completely an unambiguously represent all these possible
keystrokes, then sure, that way might result in less code change
overall.
But do make quite sure it can represent them. Specifically consider the
two tricky special-cases I suggested - repeated here again:
Tab { 1, 0, KEY_TAB }
Ctrl-I { 0, MOD_CTRL, 'i' }
Ctrl-Shift-I { 0, MOD_CTRL, 'I' }
Escape C { 1, 0, KEY_ESCAPE }, { 0, 0, 'C' }
Alt+C{ 0, MOD_ALT, 'C' }
é{ 0, 0, 0xe9 }
Then the behaviour of mappings needs to be defined--if there is a
mapping for ^I (09) and I push tab, will it be triggered? If in a
terminal which can't distinguish control-I and tab, and a ^I is
received, should the mapping for Tab or control-I be triggered? If
there's a mapping for ^I as well as Tab, which has precedence?
I propose a pair of boolean settings, with the following defaults:
:set nomodifiedunicode
:set altisescape
Under these settings,
:map Ctrl-I ... vs :map Tab ... shall have the same effect, each
overwriting the effects of the other; last one wins.
Pressing the Tab key or Ctrl-I shall both invoke the last mapping
registered.
:map EscapeC ... vs :map Alt+C ... shall behave similarly, each
overwrites the other. Typing either key sequence will invoke the
last map to be registered.
If a user decides I want to use those extra Ctrl- keys, they can set
in their .vimrc
:set modifiedunicode
At this point,
:map Ctrl-I and :map Tab shall fill two -different-
slots of the mapping list, and typing either key will activate the
indicated mapping.
If a user further decides I want the Alt modifier to not mean Escape
prefixing, then
:set noaltisescape
At which point,
:map EscapeC and :map Alt+C shall also be different.
The only remaining ambiguity to be answered is, what happens in the
following case:
:set nomodifiedunicode
:map Tab ONE
:map Ctrl-I TWO
:set modifiedunicode
now press Tab or Ctrl-I
Re: Dear Bram
On 17-Feb-2011 17:48, Paul LeoNerd Evans wrote: On Fri, Feb 04, 2011 at 07:14:29PM +0100, Bram Moolenaar wrote: Send me a patch and I'll look into it. This is a large undertaking. This isn't a send me a patch request. I would love to have this, too, if only because after so many happy years with Vim (a heartfelt thanks to Bram and all developers!), I'm running out of keys for my custom mappings :-) Though I'm too ignorant of the internals (and can therefore only offer to do some testing), I agree that this probably cannot be done in a single patch. But, with the Mercurial repository, it should be easy to create a feature branch that allows devs to collaborate and test this, and only have this merged in after it's done (hopefully in time for Vim 7.4 / 8.0?). -- regards, ingo -- 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
Re: Dear Bram
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 stuck in the 1970s all the world is a DEC-style glass virtual terminal input queue, and replace it with one that has structures; remembers modifiers, etc.. With a structure we can properly represent Ctrl-I as being the letter I with a control key, totally separate from the Tab. Having done this, we can feed in the input events from a terminal in EXACTLY the same way it currently works. We can take events out to match them up to map/etc.. much neater. We can feed events in from GTK or similar GUIs, without having to go near legacy 1970s terminal technology, meaning that GTK (et.al) users can map Tab, Ctrl-I and Ctrl-Shift-I, all independently of each other. 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. Main problem is that this won't be backwards compatible, currently CTRL-I is the same as Tab. I don't know how to make this work without breaking backwards compatibilty. Having done this, I can then quite easily send you a patch to use libtermkey if that is wanted, because then it will be able to recognise Tab, Ctrl-I and Ctrl-Shift-I even over terminal from a properly-configured xterm. But that is PURELY an extension mechanism. My primary request is to fix the underlying queue mechanism. This is an issue that has been dragging on for years now - 7 or 8 years by my count. 7 or 8 years I have been sitting in #vim on Freenode; in all that time almost every week we'll get someone or other asking how they can map some key or other, that we have to keep explaining No, sorry, you can't. Not even in GTK.. Actually, in the GUI many key combinations do work. Not all though. I am happy to sit and discuss it with you for potentially hours if necessary. What I cannot do is send a patch - it's not a small simple few-lines fix like that. I think it is about time we ended this unfortunate situation, and properly fixed the real underlying mechanism. Yours, with my real name, -- Paul LeoNerd Evans -- A cow comes flying over the battlements, lowing aggressively. The cow lands on GALAHAD'S PAGE, squashing him completely. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- 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
Re: Dear Bram
Please, please, PLEASE make this happen. On Feb 17, 11:48 am, Paul LeoNerd Evans leon...@leonerd.org.uk 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 terminal input and Gvim and everyone will be happy. Thanks. Send me a patch and I'll look into it. If you want a more useful response, use your real name and include more information about what you actually want, what system, etc. Hi Bram, 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 stuck in the 1970s all the world is a DEC-style glass virtual terminal input queue, and replace it with one that has structures; remembers modifiers, etc.. With a structure we can properly represent Ctrl-I as being the letter I with a control key, totally separate from the Tab. Having done this, we can feed in the input events from a terminal in EXACTLY the same way it currently works. We can take events out to match them up to map/etc.. much neater. We can feed events in from GTK or similar GUIs, without having to go near legacy 1970s terminal technology, meaning that GTK (et.al) users can map Tab, Ctrl-I and Ctrl-Shift-I, all independently of each other. Having done this, I can then quite easily send you a patch to use libtermkey if that is wanted, because then it will be able to recognise Tab, Ctrl-I and Ctrl-Shift-I even over terminal from a properly-configured xterm. But that is PURELY an extension mechanism. My primary request is to fix the underlying queue mechanism. This is an issue that has been dragging on for years now - 7 or 8 years by my count. 7 or 8 years I have been sitting in #vim on Freenode; in all that time almost every week we'll get someone or other asking how they can map some key or other, that we have to keep explaining No, sorry, you can't. Not even in GTK.. I am happy to sit and discuss it with you for potentially hours if necessary. What I cannot do is send a patch - it's not a small simple few-lines fix like that. I think it is about time we ended this unfortunate situation, and properly fixed the real underlying mechanism. Yours, with my real name, -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460http://www.leonerd.org.uk/ signature.asc 1KViewDownload -- 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
Re: Dear Bram
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
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
Re: Dear Bram
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, but lists of keypresses. They need the same amount of expressive power to work properly. When macros are recorded, registers, which usually are primarily lists of characters, are used to store keypresses. Likewise, for feedkeys() to work, its input, a string, needs to be able to represent keypresses. And I'm sure there are plenty more subtleties. The bottom line, though, is that changing to a struct-based approach could make the job absolutely huge, requiring reworking and/or redesigning how maps, registers, etc. all work. And it might not even be possible since, e.g. registers need to be able to do both characters and keys. It would be much simpler to extend the current approach which uses an 'escape mechanism' for representing special keys. Just hit qq and type some arrow keys, q to end recording, and then inspect register q and you'll see what's going on here. Vim uses a byte 80 followed by two more bytes to represent special keys. IMHO, what needs to be done is for this to be tidied up and made consistent and documented so that these codes can be more readily generated, interpreted, and even viewed and understood by users (e.g. when I do :registers, it would be nice to see S-Up rather than 80fd^D, when appropriate). Included in this is a clear specification of what control characters mean, e.g. does ^I (09) mean tab or control-I? And which of those keys can or does use the escape mechanism? Then the behaviour of mappings needs to be defined--if there is a mapping for ^I (09) and I push tab, will it be triggered? If in a terminal which can't distinguish control-I and tab, and a ^I is received, should the mapping for Tab or control-I be triggered? If there's a mapping for ^I as well as Tab, which has precedence? All these kinds of questions need clear answers, and sensible specifications and design need to address them, avoid ambiguity, and take care to require as little as possible work for users, plugin authors, etc. to update their code and mappings. Then the input code needs to be reworked in all the GUIs and in the terminal handling to generate the appropriate internal codes, consistently across all the different GUIs, etc., in line with that specification/design. 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
Re: Dear Bram
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-date technology and/or design constraints. Since the changes may be huge, I concur with the suggestion of creating a branch, and having discussions *and* documentation on its evolution. You raised some very interesting questions, and I hope that other people who know about the internals give their point of view too. As far as memory usage is concerned, I am now very egoistic and believe that I have enough RAM to run vim. If I don't, then I'll use vi, or an old version of vim. I used to collect and use old hardware, but I'm now getting my job done and bringing home the bacon thanks to vim on machines with more memory that I could think of not so long ago… Anyway, Cheers, P! -- Français, English, 日本語, 한국어 -- 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
Re: Dear Bram
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, 3:14 am, Bram Moolenaar b...@moolenaar.net wrote: 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 stuck in the 1970s all the world is a DEC-style glass virtual terminal input queue, and replace it with one that has structures; remembers modifiers, etc.. With a structure we can properly represent Ctrl-I as being the letter I with a control key, totally separate from the Tab. Having done this, we can feed in the input events from a terminal in EXACTLY the same way it currently works. We can take events out to match them up to map/etc.. much neater. We can feed events in from GTK or similar GUIs, without having to go near legacy 1970s terminal technology, meaning that GTK (et.al) users can map Tab, Ctrl-I and Ctrl-Shift-I, all independently of each other. 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. Main problem is that this won't be backwards compatible, currently CTRL-I is the same as Tab. I don't know how to make this work without breaking backwards compatibilty. Having done this, I can then quite easily send you a patch to use libtermkey if that is wanted, because then it will be able to recognise Tab, Ctrl-I and Ctrl-Shift-I even over terminal from a properly-configured xterm. But that is PURELY an extension mechanism. My primary request is to fix the underlying queue mechanism. This is an issue that has been dragging on for years now - 7 or 8 years by my count. 7 or 8 years I have been sitting in #vim on Freenode; in all that time almost every week we'll get someone or other asking how they can map some key or other, that we have to keep explaining No, sorry, you can't. Not even in GTK.. Actually, in the GUI many key combinations do work. Not all though. I am happy to sit and discuss it with you for potentially hours if necessary. What I cannot do is send a patch - it's not a small simple few-lines fix like that. I think it is about time we ended this unfortunate situation, and properly fixed the real underlying mechanism. Yours, with my real name, -- Paul LeoNerd Evans -- A cow comes flying over the battlements, lowing aggressively. The cow lands on GALAHAD'S PAGE, squashing him completely. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net --http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features --http://www.Vim.org/sponsor/\\\ \\\ an exciting new programming language --http://www.Zimbu.org /// \\\ help me help AIDS victims --http://ICCF-Holland.org /// -- 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
Re: Dear Bram
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 leon...@leonerd.org.uk wrote: 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 internals of implementation. So long as it is capable of knowing that Enter is not Ctrl-M is not Ctrl-Shift-M, I am happy. Main problem is that this won't be backwards compatible, currently CTRL-I is the same as Tab. I don't know how to make this work without breaking backwards compatibilty. :set oldterminalmode :map Ctrl-I Tab :map Ctrl-M CR For that matter, make it default to this 1970s-like legacy behaviour and if people want the ability to map newly-recognised keys, :set newterminalmode Actually, in the GUI many key combinations do work. Not all though. Well, then lets make them all work. Please? Seriously - I am not the only person here. There is a constant stream of users on #vim, every week you can guarantee someone will want to map Ctrl-I or Shift-Space or Shift-Enter or some other key combination that seems perfectly logical to any outside observer, to want to map. Every week we have to tell them no. I'm getting tired of it, when there isn't any technical reason why it can't be done, only it hasn't been done this way so far. So can we please have a plan? If you care deeply about retaining 1970s-like semantics, I'd be happy for a compromise solution. Some boolean setting that defaults to a value whereby these aliases do occur, where Ctrl-I and Ctrl-Shift-I -are- synonymous with Tab. But implemented in a way where I or whichever knowledgable user can say Yes vim, I know that Ctrl-I used to mean Tab in the 1970s but I would like an extra Ctrl key now and 'I' looks a good choice - let me have it. And then I could toggle setting, and map it. Yes, I'm aware that not -every- terminal can represent that. Yes I'm aware if I ever go use a real DEC VT220 glass teletype I've now lost the ability to type it. But that should be -my- problem - right now vim pointlessly restricts a whole selection of possible key mappings from GTK or Mac OS X or Win32 or proper xterms or all sorts of other places, simply for the backward-looking legacy of retaining compatibility with what the behaviour used to be in a time before many vim users were even born. I think it's about time we opened this up a bit, and allowed users to map the keypresses they want to. -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460http://www.leonerd.org.uk/ signature.asc 1KViewDownload -- 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
Re: Dear Bram
On Fri, Feb 04, 2011 at 08:05:34AM -0800, 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 second this request. -- Erik Falor Registered Linux User #445632 http://counter.li.org pgpxwDA2P4dyt.pgp Description: PGP signature
