[vimpulse] Bug: TAB doesn't autocomplete in minibuffer.
One of the recent changes in vimpulse broke the behavior of the tab key in the minibuffer. It now inserts a TAB character instead of triggering the usual autocomplete function. __ Alessandro Piras
vimpulse-misc-keybindings:564 --- (global-set-key [tab] (or (key-binding [tab]) (key-binding "\C-i"))) --- I guess this doesn't take into account mode changes, i.e., it sets the tab key and when the binding changes (when changing to a minor or major mode that sets the tab key) the tab key still does what it was set to with the global set key. Alessandro Piras On 2 July 2010 12:54, Alessandro Piras <[email protected]> wrote:
One of the recent changes in vimpulse broke the behavior of the tab key in the minibuffer. It now inserts a TAB character instead of triggering the usual autocomplete function. __ Alessandro Piras
On 2010-07-02 14:17, Alessandro Piras wrote:
vimpulse-misc-keybindings:564 --- (global-set-key [tab] (or (key-binding [tab]) (key-binding "\C-i"))) --- I guess this doesn't take into account mode changes, i.e., it sets the tab key and when the binding changes (when changing to a minor or major mode that sets the tab key) the tab key still does what it was set to with the global set key.
It depends. If the mode does indeed bind the Tab /key/ (i.e., [tab], as in (define-key map [tab] 'cmd), it will work as expected. But if the mode binds the Tab /character/ (i.e., C-i, also known as "\t"), only the C-i key is bound, because the code above breaks the bond between [tab] and C-i. In the words of the Emacs manual (my emphasis): <TAB>, <RET>, <BS>, <LFD>, <ESC> and <DEL> started out as names for certain ASCII control characters, used so often that they have special keys of their own. For instance, <TAB> was another name for C-i. [...] If you do not want to distinguish between (for example) <TAB> and C-i, make just one binding, for the ASCII character <TAB> (octal code 011). IF YOU DO WANT TO DISTINGUISH, MAKE ONE BINDING FOR THIS ASCII CHARACTER, AND ANOTHER FOR THE "FUNCTION KEY" TAB. http://www.gnu.org/software/emacs/manual/html_node/emacs/Named-ASCII-Chars.h... Before the distinction is made, one can bind Tab by binding C-i. After the distinction is made, one can bind Tab only by binding [tab]. Minibuffer completion breaks because it binds Tab the first way. Commit [ee2d1f9527] fixes this. -- Vegard
On Fri, Jul 02, 2010 at 04:55:04PM +0200, Vegard Øye wrote:
On 2010-07-02 14:17, Alessandro Piras wrote:
vimpulse-misc-keybindings:564 --- (global-set-key [tab] (or (key-binding [tab]) (key-binding "\C-i"))) --- I guess this doesn't take into account mode changes, i.e., it sets the tab key and when the binding changes (when changing to a minor or major mode that sets the tab key) the tab key still does what it was set to with the global set key.
It depends. If the mode does indeed bind the Tab /key/ (i.e., [tab], as in (define-key map [tab] 'cmd), it will work as expected. But if the mode binds the Tab /character/ (i.e., C-i, also known as "\t"), only the C-i key is bound, because the code above breaks the bond between [tab] and C-i.
In the words of the Emacs manual (my emphasis):
<TAB>, <RET>, <BS>, <LFD>, <ESC> and <DEL> started out as names for certain ASCII control characters, used so often that they have special keys of their own. For instance, <TAB> was another name for C-i. [...] If you do not want to distinguish between (for example) <TAB> and C-i, make just one binding, for the ASCII character <TAB> (octal code 011). IF YOU DO WANT TO DISTINGUISH, MAKE ONE BINDING FOR THIS ASCII CHARACTER, AND ANOTHER FOR THE "FUNCTION KEY" TAB.
... with the the caveat that in the terminal (emacs -nw) there is no such distinction (as the section you quote also mentions). In any case, we should IMO most definitely NOT mess with global map at all. Currently the only exception seems to be vimpulse-misc-keybindings.el:580: (global-set-key "\C-c\C-o" 'open-line)) ; some may miss this command IIUC, it can be safely removed, as C-o is only rebound in `viper-vi-basic-map'.
http://www.gnu.org/software/emacs/manual/html_node/emacs/Named-ASCII-Chars.h...
Before the distinction is made, one can bind Tab by binding C-i. After the distinction is made, one can bind Tab only by binding [tab].
Minibuffer completion breaks because it binds Tab the first way. Commit [ee2d1f9527] fixes this.
Somewhat off-topic, I've found Viper's messing with minibuffer intolerable, have put the following in my init file: (remove-hook 'minibuffer-setup-hook 'viper-minibuffer-setup-sentinel) ... and live happily ever since ;-) (I also set viper-vi-style-in-minibuffer to nil before, don't remember if it still matters after removing the hook.) Štěpán
What does that hook do exactly? I may be interested :-) On 2 July 2010 16:57, Štěpán Němec <[email protected]> wrote:
On Fri, Jul 02, 2010 at 04:55:04PM +0200, Vegard Øye wrote:
On 2010-07-02 14:17, Alessandro Piras wrote:
vimpulse-misc-keybindings:564 --- (global-set-key [tab] (or (key-binding [tab]) (key-binding "\C-i"))) --- I guess this doesn't take into account mode changes, i.e., it sets the tab key and when the binding changes (when changing to a minor or major mode that sets the tab key) the tab key still does what it was set to with the global set key.
It depends. If the mode does indeed bind the Tab /key/ (i.e., [tab], as in (define-key map [tab] 'cmd), it will work as expected. But if the mode binds the Tab /character/ (i.e., C-i, also known as "\t"), only the C-i key is bound, because the code above breaks the bond between [tab] and C-i.
In the words of the Emacs manual (my emphasis):
<TAB>, <RET>, <BS>, <LFD>, <ESC> and <DEL> started out as names for certain ASCII control characters, used so often that they have special keys of their own. For instance, <TAB> was another name for C-i. [...] If you do not want to distinguish between (for example) <TAB> and C-i, make just one binding, for the ASCII character <TAB> (octal code 011). IF YOU DO WANT TO DISTINGUISH, MAKE ONE BINDING FOR THIS ASCII CHARACTER, AND ANOTHER FOR THE "FUNCTION KEY" TAB.
... with the the caveat that in the terminal (emacs -nw) there is no such distinction (as the section you quote also mentions).
In any case, we should IMO most definitely NOT mess with global map at all. Currently the only exception seems to be
vimpulse-misc-keybindings.el:580: (global-set-key "\C-c\C-o" 'open-line)) ; some may miss this command
IIUC, it can be safely removed, as C-o is only rebound in `viper-vi-basic-map'.
http://www.gnu.org/software/emacs/manual/html_node/emacs/Named-ASCII-Chars.h...
Before the distinction is made, one can bind Tab by binding C-i. After the distinction is made, one can bind Tab only by binding [tab].
Minibuffer completion breaks because it binds Tab the first way. Commit [ee2d1f9527] fixes this.
Somewhat off-topic, I've found Viper's messing with minibuffer intolerable, have put the following in my init file:
(remove-hook 'minibuffer-setup-hook 'viper-minibuffer-setup-sentinel)
... and live happily ever since ;-)
(I also set viper-vi-style-in-minibuffer to nil before, don't remember if it still matters after removing the hook.)
Štěpán
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On Fri, Jul 02, 2010 at 05:28:29PM +0100, Alessandro Piras wrote:
What does that hook do exactly? I may be interested :-)
Well, just have a look yourself -- I don't remember any more. :-) AFAIR it does all Viper's minibuffer setup, e.g. that horrible greenish/orangeish colour etc. What I wanted was to have the normal Emacs minibuffer, and removing that function from the hook did it. Having multiple modes in the minibuffer seemed a bit over the top to me, and IIRC I had also some problems with keybindings (Ido mode) etc. Štěpán -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail?
On 2 July 2010 16:57, Štěpán Němec <[email protected]> wrote:
Somewhat off-topic, I've found Viper's messing with minibuffer intolerable, have put the following in my init file:
(remove-hook 'minibuffer-setup-hook 'viper-minibuffer-setup-sentinel)
... and live happily ever since ;-)
(I also set viper-vi-style-in-minibuffer to nil before, don't remember if it still matters after removing the hook.)
On 2010-07-02 17:57, Štěpán Němec wrote:
In any case, we should IMO most definitely NOT mess with global map at all.
Agreed. I redid the solution right after I posted it to the mailing list. Commit [4dfbed1130] reads: ;; Keep <tab> separate from C-i by making an explicit binding for <tab>. (define-key viper-vi-basic-map [tab] (or (key-binding [tab]) (key-binding "\C-i"))) (define-key viper-vi-basic-map "\C-i" 'vimpulse-jump-forward) The global map is not changed -- the global binding is merely copied into the vi state map, to make a Tab key-specific binding. The distinction is thus limited to that map. -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-02 17:57, Štěpán Němec wrote:
In any case, we should IMO most definitely NOT mess with global map at all.
Agreed. I redid the solution right after I posted it to the mailing list. Commit [4dfbed1130] reads:
;; Keep <tab> separate from C-i by making an explicit binding for <tab>. (define-key viper-vi-basic-map [tab] (or (key-binding [tab]) (key-binding "\C-i"))) (define-key viper-vi-basic-map "\C-i" 'vimpulse-jump-forward)
The global map is not changed -- the global binding is merely copied into the vi state map, to make a Tab key-specific binding. The distinction is thus limited to that map.
Yes. I was OT1H just stating a principle :-), OTOH I was speaking about this:
Vegard Øye <[email protected]> writes:
On 2010-07-03 11:54, Štěpán Němec wrote:
Yes. I was OT1H just stating a principle :-), OTOH I was speaking about this:
Your attachment didn't make it through. I've disabled content filtering. Please resend.
Uhm... what content filtering? I remember sending patches in the past without problems... or not?
On 2010-07-03 13:27, Štěpán Němec wrote:
Vegard Øye <[email protected]> writes:
Your attachment didn't make it through. I've disabled content filtering. Please resend.
Uhm... what content filtering? I remember sending patches in the past without problems... or not?
There's a "content filtering" section in the administrative interface for screening attachments. Description: Content filtering works like this: when a message is received by the list and you have enabled content filtering, the individual attachments are first compared to the filter types. If the attachment type matches an entry in the filter types, it is discarded. Then, if there are pass types defined, any attachment type that does not match a pass type is also discarded. If there are no pass types defined, this check is skipped. After this initial filtering, any multipart attachments that are empty are removed. If the outer message is left empty after this filtering, then the whole message is discarded. Then, each multipart/alternative section will be replaced by just the first alternative that is non-empty after filtering if collapse_alternatives is enabled. Finally, any text/html parts that are left in the message may be converted to text/plain if convert_html_to_plaintext is enabled and the site is configured to allow these conversions. I just disabled it wholesale. Spam isn't an issue on this list, at least not for the time being. Anyhow, 0001-Remove-unnecessary-global-C-c-C-o-binding.patch was applied in commit [891b5848be]. :) -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-03 13:27, Štěpán Němec wrote:
Vegard Øye <[email protected]> writes:
Your attachment didn't make it through. I've disabled content filtering. Please resend.
Uhm... what content filtering? I remember sending patches in the past without problems... or not?
There's a "content filtering" section in the administrative interface for screening attachments. Description:
Content filtering works like this: when a message is received by the list and you have enabled content filtering, the individual attachments are first compared to the filter types. If the attachment type matches an entry in the filter types, it is discarded.
Then, if there are pass types defined, any attachment type that does not match a pass type is also discarded. If there are no pass types defined, this check is skipped.
After this initial filtering, any multipart attachments that are empty are removed. If the outer message is left empty after this filtering, then the whole message is discarded.
Then, each multipart/alternative section will be replaced by just the first alternative that is non-empty after filtering if collapse_alternatives is enabled.
Finally, any text/html parts that are left in the message may be converted to text/plain if convert_html_to_plaintext is enabled and the site is configured to allow these conversions.
Ooh, wow...
I just disabled it wholesale. Spam isn't an issue on this list, at least not for the time being.
Right. (The spam I've seen on Gmane was all plaintext anyway. ;-P)
Anyhow, 0001-Remove-unnecessary-global-C-c-C-o-binding.patch was applied in commit [891b5848be]. :)
Thanks.
On 2010-07-02 17:57, Štěpán Němec wrote:
On Fri, Jul 02, 2010 at 04:55:04PM +0200, Vegard Øye wrote:
http://www.gnu.org/software/emacs/manual/html_node/emacs/Named-ASCII-Chars.h...
... with the the caveat that in the terminal (emacs -nw) there is no such distinction (as the section you quote also mentions).
I tested it and it still worked, so I guess Windows XP doesn't have an "ordinary ASCII terminal". The section also states that "most modern terminals" recognize the distinction. Štěpán, do you have access to an ASCII terminal to experiment with? Does the order of binding [tab] and C-i matter? (Sorry about the separate posts.) -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-02 17:57, Štěpán Němec wrote:
On Fri, Jul 02, 2010 at 04:55:04PM +0200, Vegard Øye wrote:
http://www.gnu.org/software/emacs/manual/html_node/emacs/Named-ASCII-Chars.h...
... with the the caveat that in the terminal (emacs -nw) there is no such distinction (as the section you quote also mentions).
I tested it and it still worked, so I guess Windows XP doesn't have an "ordinary ASCII terminal". The section also states that "most modern terminals" recognize the distinction.
Štěpán, do you have access to an ASCII terminal to experiment with? Does the order of binding [tab] and C-i matter?
Well, IMHO "ASCII terminal" might be a little bit of a misnomer nowadays (most terminals seem to handle non-ascii just fine), but it's a fact well known and recognized that in a terminal TAB key sends a TAB character. So when I run Emacs in a terminal (i.e. emacs -nw), binding [tab] has no effect whatsoever, and binding C-i affects both the TAB key and the C-i combo. Are you saying that when you do C-h c C-i and C-h c <tab> in emacs -nw under Windows, you get different results? How does emacs -nw on Windows even look like? You're launching it inside cmd.com? I'm not sure what the "most modern terminals" mentioned in the text mean. I suspect "terminal" is just a synonym for "computer" there. If there's a way to somehow re-program a text terminal to send something different for <tab> and C-i, then I'm yet to hear about it (it might be possible, I'm no expert on terminals), but you certainly can't rely upon such behaviour.
(Sorry about the separate posts.)
I see nothing wrong 'bout that. Štěpán
On 2010-07-03 12:23, Štěpán Němec wrote:
Are you saying that when you do C-h c C-i and C-h c <tab> in emacs -nw under Windows, you get different results?
Yes. The first is bound to `vimpulse-jump-forward', the second to `indent-for-tab-command'. And when I jump back three times with C-o C-o C-o, I can jump forwards with C-i C-i C-i, but not with <tab> <tab> <tab>.
How does emacs -nw on Windows even look like?
Spartan. :) I'm attaching a 11 kB PNG file showing Emacs under cmd.exe. Let's see if it gets through.
If there's a way to somehow re-program a text terminal to send something different for <tab> and C-i, then I'm yet to hear about it (it might be possible, I'm no expert on terminals), but you certainly can't rely upon such behaviour.
And sure enough, Vim does not. Vim treats <Tab> and CTRL-I as the same key. In vanilla Vim, you can go to a newer jump position with <Tab>; and in my Vim, where I rebind <Tab> to <Esc>, I can exit Insert mode with CTRL-I. -- Vegard
Vegard Øye <[email protected]> writes:
On 2010-07-03 12:23, Štěpán Němec wrote:
Are you saying that when you do C-h c C-i and C-h c <tab> in emacs -nw under Windows, you get different results?
Yes. The first is bound to `vimpulse-jump-forward', the second to `indent-for-tab-command'. And when I jump back three times with C-o C-o C-o, I can jump forwards with C-i C-i C-i, but not with <tab> <tab> <tab>.
How does emacs -nw on Windows even look like?
Spartan. :)
I'm attaching a 11 kB PNG file showing Emacs under cmd.exe. Let's see if it gets through.
If there's a way to somehow re-program a text terminal to send something different for <tab> and C-i, then I'm yet to hear about it (it might be possible, I'm no expert on terminals), but you certainly can't rely upon such behaviour.
And sure enough, Vim does not. Vim treats <Tab> and CTRL-I as the same key. In vanilla Vim, you can go to a newer jump position with <Tab>; and in my Vim, where I rebind <Tab> to <Esc>, I can exit Insert mode with CTRL-I.
Yeah, that's an oft-mentioned Vim whim -- for some reason Bram decided to go with Tab key == Tab character even in the GUI (gvim).
participants (3)
-
Alessandro Piras -
Vegard Øye -
Štěpán Němec