M- commands no longer pass through
Hello, in the past week sometime, give or take, the default behaviour of evil seems to have change with respect to any key bindings *not* in the standard (normal, insert) maps. I first noticed this when trying to type M-q while writing; this key is globally bound to maybe-fill-paragraph, my own function. Now even M-x doesn't work. I have to switch to emacs mode first. The annoying thing is that C-h c M-q says M-q runs the command maybe-fill-paragraph but hitting M-q gives M-q is undefined Similar behaviour is observed for M-x, M-; and M-:, all of which are quite hard-coded into my emacs fingers and have no immediate evil equivalents in any case... Is there a change in the default configuration I have missed? I have gone through the git log but haven't noticed anything specific. I am using evil version 1.0-dev. Is there a variable I can tweak to allow these keystrokes to go through? Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 + Ma Gnus v0.6 + evil 1.0-dev : BBDB version 3.02 ($Date: 2013/02/16 14:37:17 $)
On Wed, Feb 20, 2013 at 9:07 AM, Eric S Fraga <[email protected]> wrote:
Is there a change in the default configuration I have missed? I have gone through the git log but haven't noticed anything specific. I am using evil version 1.0-dev. Is there a variable I can tweak to allow these keystrokes to go through?
The usual procedure to help pinpoint the specific changeset responsible is git bisect. Since you know the approximate timeframe, and it's only a week, it should be fast and easy to find the commit in question, and you'll likely have the answer before anyone in the know wakes up :). Then you can go from there and start asking pointed questions. Cheers, Maciej
Maciej Katafiasz <[email protected]> writes: [...]
The usual procedure to help pinpoint the specific changeset responsible is git bisect. Since you know the approximate timeframe, and it's only a week, it should be fast and easy to find the commit in question, and you'll likely have the answer before anyone in the know wakes up :). Then you can go from there and start asking pointed questions.
True enough, although in this case the exercise would have been fruitless given that the problem is with recent changes in Emacs :( I'll use git bisect next time! -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : Emacs 24.3.50.1: evil 1.0-dev, org 7.9.3e, Ma Gnus v0.6, bbdb 3.02
On 2013-02-20, Eric S Fraga <[email protected]> wrote:
Hello,
in the past week sometime, give or take, the default behaviour of evil seems to have change with respect to any key bindings *not* in the standard (normal, insert) maps. I first noticed this when trying to type M-q while writing; this key is globally bound to maybe-fill-paragraph, my own function. Now even M-x doesn't work. I have to switch to emacs mode first.
The annoying thing is that C-h c M-q says
M-q runs the command maybe-fill-paragraph
but hitting M-q gives
M-q is undefined
Similar behaviour is observed for M-x, M-; and M-:, all of which are quite hard-coded into my emacs fingers and have no immediate evil equivalents in any case...
Is there a change in the default configuration I have missed? I have gone through the git log but haven't noticed anything specific. I am using evil version 1.0-Devi. Is there a variable I can tweak to allow these keystrokes to go through?
The default behaviour of Evil did not change, at least not that I know of ;) May I ask which Emacs version you use? 24.3.1 or so? If this is the case, then I've realised this problem, too, two days or so ago. This problem only occurs in X mode, in terminal everything works fine. But we did not change anything w.r.t. to the escape key. I tried with viper and the same problem occurred. It seems as if the Emacs people changed something that makes trouble with the ESC key work-around for terminals (viper and evil use more or less the same trick). In the meantime you could disable the ESC workaround of evil (untested): (define-key evil-esc-map (kbd "ESC") nil) but then ESC in terminal mode won't work anymore. Currently I do not know what to do. I haven't look yet if there's already a bug report (or even a fix) for viper. Frank
Frank Fischer <[email protected]> writes:
On 2013-02-20, Eric S Fraga <[email protected]> wrote:
Hello,
in the past week sometime, give or take, the default behaviour of evil seems to have change with respect to any key bindings *not* in the standard (normal, insert) maps. I first noticed this when trying to type M-q while writing; this key is globally bound to maybe-fill-paragraph, my own function. Now even M-x doesn't work. I have to switch to emacs mode first.
[...]
The default behaviour of Evil did not change, at least not that I know of ;)
May I ask which Emacs version you use? 24.3.1 or so?
24.3.50.1 (I track emacs-snapshot on ubuntu).
If this is the case, then I've realised this problem, too, two days or so ago. This problem only occurs in X mode, in terminal everything works fine.
Ah ha! Hadn't thought it would be an Emacs issue.
In the meantime you could disable the ESC workaround of evil (untested):
(define-key evil-esc-map (kbd "ESC") nil)
This works. Thanks. However, I do use Emacs in terminal mode from my phone sometimes so will need to do this only on X. Easy enough to do! Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : Emacs 24.3.50.1: evil 1.0-dev, org 7.9.3e, Ma Gnus v0.6, bbdb 3.02
On 2013-02-20, Eric S Fraga <[email protected]> wrote:
Frank Fischer <[email protected]> writes:
On 2013-02-20, Eric S Fraga <[email protected]> wrote:
Hello,
in the past week sometime, give or take, the default behaviour of evil seems to have change with respect to any key bindings *not* in the standard (normal, insert) maps. I first noticed this when trying to type M-q while writing; this key is globally bound to maybe-fill-paragraph, my own function. Now even M-x doesn't work. I have to switch to emacs mode first.
After some discussion Stefan Monnier came up with a nice solution, which I've integrated into Evil. Because it is heavily untested it is currently in the branch `esc24.3`. The new code should work with Emacs 23, 24, 24.3, in terminal and X and a mixture of both (emacsclient). In other words, everywhere ;) Please test this patch and communicate any problems. Frank
Testing the patch, C-[ is not working anymore. Escape works correctly though. Is this a known problem with the esc24.3 branch? Alessandro Piras On 27 February 2013 09:53, Frank Fischer <[email protected]> wrote:
On 2013-02-20, Eric S Fraga <[email protected]> wrote:
Frank Fischer <[email protected]> writes:
On 2013-02-20, Eric S Fraga <[email protected]> wrote:
Hello,
in the past week sometime, give or take, the default behaviour of evil seems to have change with respect to any key bindings *not* in the standard (normal, insert) maps. I first noticed this when trying to type M-q while writing; this key is globally bound to maybe-fill-paragraph, my own function. Now even M-x doesn't work. I have to switch to emacs mode first.
After some discussion Stefan Monnier came up with a nice solution, which I've integrated into Evil. Because it is heavily untested it is currently in the branch `esc24.3`. The new code should work with Emacs 23, 24, 24.3, in terminal and X and a mixture of both (emacsclient). In other words, everywhere ;)
Please test this patch and communicate any problems.
Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On 2013-03-02, Alessandro Piras <[email protected]> wrote:
Testing the patch, C-[ is not working anymore. Escape works correctly though. Is this a known problem with the esc24.3 branch?
You mean really pressing Ctrl and [ simultaneously? (trying this on a German keyboard would really break your fingers, that's why I never test it ;)) In terminal or in X? If this happens in X I would not be too surpised, in terminal C-[ should really send the same event as ESC, so this should not happen in terminal. Frank
Hi Frank, Yes, I meant pressing Ctrl and [ simultaneously :-) I can understand what you mean about the german keyboard, it's as crazy on an italian keyboard, but I usually type using the US layout, and my laptop has a real US-ansi layout. This happens on X, everything works as expected on the terminal. As a half-baked fix, I put this in my evil configuration: (define-key input-decode-map (kbd "C-[") [escape]) It (kind of) works, but I noticed some inconsistencies when issuing C-[ in emacs state. Pressing C-[ two times (sorry for your fingers if you are going to test this!) in emacs state leads to this error message: ESC <escape> is undefined __ Alessandro Piras On 3 March 2013 11:39, Frank Fischer <[email protected]> wrote:
On 2013-03-02, Alessandro Piras <[email protected]> wrote:
Testing the patch, C-[ is not working anymore. Escape works correctly though. Is this a known problem with the esc24.3 branch?
You mean really pressing Ctrl and [ simultaneously? (trying this on a German keyboard would really break your fingers, that's why I never test it ;))
In terminal or in X? If this happens in X I would not be too surpised, in terminal C-[ should really send the same event as ESC, so this should not happen in terminal.
Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
On 2013-03-03, Alessandro Piras <[email protected]> wrote:
Hi Frank, Yes, I meant pressing Ctrl and [ simultaneously :-) I can understand what you mean about the german keyboard, it's as crazy on an italian keyboard, but I usually type using the US layout, and my laptop has a real US-ansi layout. This happens on X, everything works as expected on the terminal.
As a half-baked fix, I put this in my evil configuration:
(define-key input-decode-map (kbd "C-[") [escape])
This is dangerous, because several meta-key-translations are contained in `input-decode-map`. Furthermore `input-decode-map` is 'keyboard-local', so you have to ensure to modify this map on each frame. Furthermore, evil now uses more or less the same trick, so you could easily interfere with Evil. Because `input-decode-map` is keyboard-local (or better terminal-local), Evil now only modifies this map when the current frame is in a terminal and leaves it untouched in X (the philosophy is to tweak Emacs as less as possible, and in X not intercepting ESC should be fine for most users). This works because in X the plain escape key generates the 'escape event, which will eventually be converted to ESC in `function-key-map` unless it is bound to some command. Unfortunately C-[ generates the 'terminal' ESC event. IMO, the easiest fix is to instruct Evil to do its ESC magic in X, too. I've committed a change to esc24.3 that introduces the (customization) variable `evil-intercept-esc`. Setting this variable to 'always makes Evil intercept the ESC event in any frame, not only in terminal frames, i.e. something like (setq evil-intercept-esc 'always) should solve your problem and, hopefully, not break something else (by default this variable is t which means 'terminal-only'). Hope this helps, Frank
Hi again. This solution works perfectly when starting emacs in graphical mode "normally", thanks! I have a problem when starting it as a daemon though. I tried starting emacs with $ emacsclient --alternate-editor="" -c C-[ does not work, but esc does. Alessandro Piras On 7 March 2013 08:40, Frank Fischer <[email protected]> wrote:
On 2013-03-03, Alessandro Piras <[email protected]> wrote:
Hi Frank, Yes, I meant pressing Ctrl and [ simultaneously :-) I can understand what you mean about the german keyboard, it's as crazy on an italian keyboard, but I usually type using the US layout, and my laptop has a real US-ansi layout. This happens on X, everything works as expected on the terminal.
As a half-baked fix, I put this in my evil configuration:
(define-key input-decode-map (kbd "C-[") [escape])
This is dangerous, because several meta-key-translations are contained in `input-decode-map`. Furthermore `input-decode-map` is 'keyboard-local', so you have to ensure to modify this map on each frame. Furthermore, evil now uses more or less the same trick, so you could easily interfere with Evil.
Because `input-decode-map` is keyboard-local (or better terminal-local), Evil now only modifies this map when the current frame is in a terminal and leaves it untouched in X (the philosophy is to tweak Emacs as less as possible, and in X not intercepting ESC should be fine for most users). This works because in X the plain escape key generates the 'escape event, which will eventually be converted to ESC in `function-key-map` unless it is bound to some command. Unfortunately C-[ generates the 'terminal' ESC event.
IMO, the easiest fix is to instruct Evil to do its ESC magic in X, too. I've committed a change to esc24.3 that introduces the (customization) variable `evil-intercept-esc`. Setting this variable to 'always makes Evil intercept the ESC event in any frame, not only in terminal frames, i.e. something like
(setq evil-intercept-esc 'always)
should solve your problem and, hopefully, not break something else (by default this variable is t which means 'terminal-only').
Hope this helps, Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Hi again, I got it working, there was a problem in my custom file (evil-intercept-esc was being set to (quote always) instead of always... Sorry if I made you lose time with this last one! Thanks for the fix, seems perfect! Alessandro Piras On 11 March 2013 23:46, Alessandro Piras <[email protected]> wrote:
Hi again. This solution works perfectly when starting emacs in graphical mode "normally", thanks!
I have a problem when starting it as a daemon though. I tried starting emacs with $ emacsclient --alternate-editor="" -c C-[ does not work, but esc does.
Alessandro Piras
On 7 March 2013 08:40, Frank Fischer <[email protected]> wrote:
On 2013-03-03, Alessandro Piras <[email protected]> wrote:
Hi Frank, Yes, I meant pressing Ctrl and [ simultaneously :-) I can understand what you mean about the german keyboard, it's as crazy on an italian keyboard, but I usually type using the US layout, and my laptop has a real US-ansi layout. This happens on X, everything works as expected on the terminal.
As a half-baked fix, I put this in my evil configuration:
(define-key input-decode-map (kbd "C-[") [escape])
This is dangerous, because several meta-key-translations are contained in `input-decode-map`. Furthermore `input-decode-map` is 'keyboard-local', so you have to ensure to modify this map on each frame. Furthermore, evil now uses more or less the same trick, so you could easily interfere with Evil.
Because `input-decode-map` is keyboard-local (or better terminal-local), Evil now only modifies this map when the current frame is in a terminal and leaves it untouched in X (the philosophy is to tweak Emacs as less as possible, and in X not intercepting ESC should be fine for most users). This works because in X the plain escape key generates the 'escape event, which will eventually be converted to ESC in `function-key-map` unless it is bound to some command. Unfortunately C-[ generates the 'terminal' ESC event.
IMO, the easiest fix is to instruct Evil to do its ESC magic in X, too. I've committed a change to esc24.3 that introduces the (customization) variable `evil-intercept-esc`. Setting this variable to 'always makes Evil intercept the ESC event in any frame, not only in terminal frames, i.e. something like
(setq evil-intercept-esc 'always)
should solve your problem and, hopefully, not break something else (by default this variable is t which means 'terminal-only').
Hope this helps, Frank
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
participants (4)
-
Alessandro Piras -
Eric S Fraga -
Frank Fischer -
Maciej Katafiasz