bug#13793: 24.3.50; M-x broken in viper and X

bug#13793: 24.3.50; M-x broken in viper and X

[Frank Fischer]

Meta bindings do not work if Emacs is started in X and viper is
enabled. To reproduce, type

  emacs -Q
  M-x viper RET
  M-x

the last command M-x shows 'M-x undefined'.

As far as I can tell, the reason is viper's trick with the ESC
key. viper binds (kbd "ESC") to a special command call
`viper-intercept-ESC-key`. The purpose is to make the plain ESC key
usable in terminal mode: viper, being a vi emulator, uses a plain ESC
key to exit insert mode. This special command does the following: If an
ESC event arrives, viper waits for a short period of time for another
event. If no other event arrives, viper assumes that a plain ESC key has
been pressed. Otherwise the the ESC key is interpreted as a prefix of
the second event. Thus, M-x in terminal first calls
`viper-intercept-ESC-key`, this functions waits for the second event,
the 'x', and then calls the binding of 'ESC x'.

In X mode this is not necessary, because the plain ESC key generates the
event 'escape, so it is distinguishable from a prefix ESC. Nevertheless,
the binding of ESC is still active, because viper has to support both, X
and terminal (suppose Emacs is started in server mode, one frame being
X, another being terminal). So in some sense, the trick to make viper
work well in terminal mode now causes a problem in X.

Until Emacs 24.2 this "trick" worked quite well. This changed
recently. I tried to find the changeset that introduced the bug, and I
think it is (I used the git repo)

  commit 11521f1228e447bb68ff7a48a30148b99323c04e
  Author: Stefan Monnier <monnier@iro.umontreal.ca>
  Date:   Mon Feb 11 14:21:23 2013 -0500

    Clean up read_key_sequence a bit; reread active keymaps after first
    event.

Sorry that I'm not (yet) able to figure out what went wrong exactly, but
I hope this information helps to find a solution.

Best regards,
Frank 




In GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2013-02-15 on dubnium, modified by Debian
 (emacs-snapshot package, version 2:20130215-1~ppa1~precise1)
Windowing system distributor `The X.Org Foundation', version
11.0.11103000 System Description:	Ubuntu 12.04.2 LTS

Configured using:
 `configure --build i686-linux-gnu --host i686-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.3.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3.50/site-lisp:/usr/share/emacs/site-lisp
 --without-compress-info --with-crt-dir=/usr/lib/i386-linux-gnu/
 --with-x=yes --with-x-toolkit=gtk3 --with-imagemagick=yes
 CFLAGS='-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'
 CPPFLAGS='-D_FORTIFY_SOURCE=2' LDFLAGS='-g -Wl,--as-needed
 -znocombreloc''

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Message

Minor modes in effect:
  mml-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
( <right> <right> <right> ) M-q C-c C-c n o <return> 
<up> <up> <up> <up> <up> <up> C-SPC <down> <down> <down> 
<down> <down> <down> C-w <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <down> <down> <down> C-c C-c 
<down> <down> C-c C-c <down> <down> <down> <down> <down> 
<down> <up> C-SPC <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> M-y M-w M-x 
C-g <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up

bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

> Meta bindings do not work if Emacs is started in X and viper is
> enabled. To reproduce, type

>   emacs -Q
>   M-x viper RET
>   M-x

> the last command M-x shows 'M-x undefined'.

I can reproduce it here, but it's tricky to investigate because of all
the various keymap trickery.  The thing I noticed is that in emacs-24,
`f1 k M-x' also tells me "M-x is undefined" although M-x does work.

> As far as I can tell, the reason is viper's trick with the ESC
> key. viper binds (kbd "ESC") to a special command call
> `viper-intercept-ESC-key`.

AFAICT in the GUI case, viper-intercept-ESC-key is not called when you
hit M-x (at least that's what trace-function-background told me, both in
trunk and in emacs-24).

The same commit caused a problem in Evil as well (see bug#13709), and
I hope the problem is the same and can be fixed in the same way, but I'm
also having trouble figuring out what's happening in that case.

If someone familiar with Evil or Viper's keymap tricks could investigate
a bit more to try and see where the behavior changes, I can then
hopefully see how it relates to my read-key-sequence changes.


        Stefan

bug#13709: bug#13793: 24.3.50; M-x broken in viper and X

[Frank Fischer]

On 02/24, Stefan Monnier wrote:
> The same commit caused a problem in Evil as well (see bug#13709), and
> I hope the problem is the same and can be fixed in the same way, but I'm
> also having trouble figuring out what's happening in that case.
> 
> If someone familiar with Evil or Viper's keymap tricks could investigate
> a bit more to try and see where the behavior changes, I can then
> hopefully see how it relates to my read-key-sequence changes.

Coincidentally, I'm involved with Evil, but I've never tried to debug
Emacs' C code. But I think I succeeded and can explain what's going
on. I will restrict to Evil, because I know it better than viper. I
start with a description of what Evil does and afterwards describe the
problem with the new code.

The problem, as I said, is that Evil needs to differentiate between a
plain ESC key and a meta key sequence. Evil does the following. It has
a special minor mode `evil-esc-mode` along with its keymap
`evil-esc-map`. This keymap has only one binding, (kbd "ESC") is bound
to a function `evil-esc`. This function is very simple (I removed some
code, but they main idea should become clear)

	(defun evil-esc (arg)
	  "Wait for further keys within `evil-esc-delay'.
	Otherwise send [escape]."
	  (interactive "P")
	  (if (sit-for evil-esc-delay t)
		  (push 'escape unread-command-events)
		(push last-command-event unread-command-events)
		;; preserve prefix argument
		(setq prefix-arg arg))
	  ;; disable interception for the next key sequence
	  (evil-esc-mode -1)
	  (setq this-command last-command)
	  (add-hook 'pre-command-hook #'evil-turn-on-esc-mode nil t))

The function waits for the next event. If it arrives, the (kbd "ESC")
event is unread, and evil-esc-mode is disabled so that it does not
call again `evil-esc`. If no next event arrives the event 'escape is
unread so whatever command is bound to 'escape will be called.
`evil-esc-mode` will be reenabled after the next command completed.
Note that an event like M-x (in the terminal) generates two events in
quick succession, namely (kbd "ESC") and "x", so the first case
happens. In GUI mode the function `evil-esc` is never called because
here M-x generates another event (some large integer). This event is
transformed to an ESC sequence, too, but not using `evil-esc` but
within the function `access_keymap_1` in file `keymap.c`.

If this function detects that the event is a meta event, it looks for
the prefix map of (kbd "ESC") in the keymap that has been passed to
the function in the "map" argument. Here comes the problem.

The function `follow_key` has been changed by the problematic commit.
Formerly severall keymaps have been passed in an array. Each keymap
has been checked in turn for a binding. One of the keymaps is
`evil-esc-map`. If this keymap is checked no binding is found. So the
next keymap is checked an it may contain a binding for M-x so this
binding is used.

After the commit all keymaps are collected in one single "super"
keymap, that contains all keymaps as "parents" (is this correct?). Now
`access_keymap_1` gets only called once for this super keymap. Again
this function tries to find (kbd "ESC") in this keymap. This will
return the binding of `evil-esc`, which is not a prefix keymap so no
binding will be found. Because of how keymaps work only the first
binding of (kbd "ESC") in one of the parent keymaps will be returned,
and this is `evil-esc`.

The get the old behaviour, `access_keymap_1` would have to check all
parent keymaps in turn. For each keymap that bind (kbd "ESC") to
another keymap it would have to check the second key.

I hope this helps. Sorry that I do not provide a patch, but currently
my "Emacs-C" is too bad for this.

Anyhow, the real problem is to "multiplex" the (kbd "ESC") event in
the terminal. Any solution that sends 'escape instead of (kbd "ESC")
if another event arrives within a short period should solve the
problem.

If my explanations are unclear, please tell ;)

Best regards,
Frank

bug#13709: bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

> The function `follow_key` has been changed by the problematic commit.
> Formerly severall keymaps have been passed in an array. Each keymap
> has been checked in turn for a binding. One of the keymaps is
> `evil-esc-map`. If this keymap is checked no binding is found. So the
> next keymap is checked an it may contain a binding for M-x so this
> binding is used.

Oh, I think I see what's going on.  So the Evil code (and Viper, since
it seems to use the same gymnastics) really relies on some pretty nasty
detail of the level at which the M-x => ESC x rewriting took place,
which was subtly changed.

That could also explain why `f1 f M-x' already didn't find the binding
in the old code.

> Anyhow, the real problem is to "multiplex" the (kbd "ESC") event in
> the terminal. Any solution that sends 'escape instead of (kbd "ESC")
> if another event arrives within a short period should solve the
> problem.

Now my question is: why do it with a minor-mode map rather than with
an input-decode-map (which would also save you from having to rely on
unread-command-events)?  Oh, yes, of course, that input-decode-map
binding would collide with the escape-sequence remappings.

How 'bout something like:

        (defvar evil-normal-esc-map (lookup-key input-decode-map [?\e]))
        (define-key input-decode-map
          [?\e] `(menu-item "" ,evil-normal-esc-map
                   :filter ,(lambda (map)
                              (if (sit-for evail-esc-delay) [escape] map))))

[ Modulo some dance à la evil-esc-mode to add/remove this binding so
  that code that adds escape sequences to this map never bumps into the
  [escape] mapping.  ]


        Stefan

bug#13709: bug#13793: 24.3.50; M-x broken in viper and X

[Frank Fischer]

On 02/25, Stefan Monnier wrote:
> > Anyhow, the real problem is to "multiplex" the (kbd "ESC") event in
> > the terminal. Any solution that sends 'escape instead of (kbd "ESC")
> > if another event arrives within a short period should solve the
> > problem.
> 
> Now my question is: why do it with a minor-mode map rather than with
> an input-decode-map (which would also save you from having to rely on
> unread-command-events)?  Oh, yes, of course, that input-decode-map
> binding would collide with the escape-sequence remappings.
> 
> How 'bout something like:
> 
>         (defvar evil-normal-esc-map (lookup-key input-decode-map [?\e]))
>         (define-key input-decode-map
>           [?\e] `(menu-item "" ,evil-normal-esc-map
>                    :filter ,(lambda (map)
>                               (if (sit-for evail-esc-delay) [escape] map))))

This is a really clever solution, thank you a lot. It looks much
better than the current one. The Evil code is naturally "inspired" by
viper's code, so the reasons for its current form are hidden in the
shadows of history ;)

I will build something like this into Evil, then we will see if it
breaks something.

> 
> [ Modulo some dance à la evil-esc-mode to add/remove this binding so
>   that code that adds escape sequences to this map never bumps into the
>   [escape] mapping.  ]

Maybe one question, because I'm not too familiar with translation
keymaps. What do you think is the best solution to this
add-escape-sequences-to-input-decode-map-problem? The only possibility
that comes into my mind would be to advice `define-key` so that
`evil-normal-esc-map` is temporarily put back into `input-decode-map`.
Is there a better way than using such an advice?

Once again, thank you a lot!

Frank

bug#13709: bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

>> [ Modulo some dance à la evil-esc-mode to add/remove this binding so
>> that code that adds escape sequences to this map never bumps into the
>> [escape] mapping.  ]

> Maybe one question, because I'm not too familiar with translation
> keymaps. What do you think is the best solution to this
> add-escape-sequences-to-input-decode-map-problem? The only possibility
> that comes into my mind would be to advice `define-key` so that
> `evil-normal-esc-map` is temporarily put back into `input-decode-map`.
> Is there a better way than using such an advice?

I guess an advice might work (it probably wouldn't need to put the map
back, just let-bind a variable that causes the filter function to return
evil-normal-esc-map without bothering to sit-for).
But it doesn't sound very appealing.

Maybe "enable evil-esc-mode in post-command-hook and disable it in
pre-command-hook" might work?


        Stefan

bug#13793: 24.3.50; M-x broken in viper and X

[Frank Fischer]

On 02/26, Stefan Monnier wrote:
> >> [ Modulo some dance à la evil-esc-mode to add/remove this binding so
> >> that code that adds escape sequences to this map never bumps into the
> >> [escape] mapping.  ]
> 
> > Maybe one question, because I'm not too familiar with translation
> > keymaps. What do you think is the best solution to this
> > add-escape-sequences-to-input-decode-map-problem? The only possibility
> > that comes into my mind would be to advice `define-key` so that
> > `evil-normal-esc-map` is temporarily put back into `input-decode-map`.
> > Is there a better way than using such an advice?
> 
> I guess an advice might work (it probably wouldn't need to put the map
> back, just let-bind a variable that causes the filter function to return
> evil-normal-esc-map without bothering to sit-for).
> But it doesn't sound very appealing.
> 
> Maybe "enable evil-esc-mode in post-command-hook and disable it in
> pre-command-hook" might work?

I'm a little bit afraid of situations where a new binding is defined
but pre-command-hook has not been called (to restore the original
definition of `input-decode-map`). For example if a new binding is
established in a hook or when Emacs starts. If evil is loaded before
that binding is defined, i.e. input-decode-map is already 'patched',
then it may fail. Of course one could start with an unpatched
input-decode-map and wait for the first post-command-hook.

So the question is: is it guaranteed that a post-command-hook will be
called when Emacs starts and before any user input, and that a call to
`define-key` will always be preceded by a pre-command-hook and
followed by a post-command-hook, no matter how it is called? This
includes any possibility to call `define-key` from a hook or so. I
just do not have the overview to give a reliable judgement on this.
IMO using an advice is more direct and simpler in this particular
situation, although I really don't like it.

Frank

bug#13709: bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

>> Maybe "enable evil-esc-mode in post-command-hook and disable it in
>> pre-command-hook" might work?
> I'm a little bit afraid of situations where a new binding is defined
> but pre-command-hook has not been called (to restore the original
> definition of `input-decode-map`). For example if a new binding is
> established in a hook or when Emacs starts. If evil is loaded before
> that binding is defined, i.e. input-decode-map is already 'patched',
> then it may fail. Of course one could start with an unpatched
> input-decode-map and wait for the first post-command-hook.

Agreed, using post/pre-command-hook is messy.  Other problems come up
with recursive edits (and minibuffers), where the pre-command-hook can
end up run twice without intervening post-command-hook and
post-command-hook can similarly be run twice without an intervening
pre-command-hook.

> So the question is: is it guaranteed that a post-command-hook will be
> called when Emacs starts and before any user input, and that a call to
> `define-key` will always be preceded by a pre-command-hook and
> followed by a post-command-hook, no matter how it is called?

No, basically with pre/post-command-hook, nothing is guaranteed.

> This includes any possibility to call `define-key` from a hook or
> so.  I just do not have the overview to give a reliable judgement on
> this.  IMO using an advice is more direct and simpler in this
> particular situation, although I really don't like it.

I think what we really care about is to detect "called from
read-key-sequence".  How 'bout:

(defvar evil-normal-esc-map (lookup-key input-decode-map [?\e]))
(define-key input-decode-map
  [?\e] `(menu-item "" ,evil-normal-esc-map
          :filter ,(λ (map)
                     (if (and (not evil-inhibit-escape)
                              (equal (this-single-command-keys) [?\e])
                              (sit-for 0.1))
                         [escape] map))))

So the special ESC=>escape mapping only takes place if the whole
last key-sequence so far is just [?\e], i.e. either we're still in
read-key-sequence, or the last read-key-sequence only read [?\e], which
should ideally never happen because it should have been mapped to [escape].


        Stefan

bug#13793: 24.3.50; M-x broken in viper and X

[Frank Fischer]

On 02/26, Stefan Monnier wrote:
> I think what we really care about is to detect "called from
> read-key-sequence".  How 'bout:
> 
> (defvar evil-normal-esc-map (lookup-key input-decode-map [?\e]))
> (define-key input-decode-map
>   [?\e] `(menu-item "" ,evil-normal-esc-map
>           :filter ,(λ (map)
>                      (if (and (not evil-inhibit-escape)
>                               (equal (this-single-command-keys) [?\e])
>                               (sit-for 0.1))
>                          [escape] map))))
> 
> So the special ESC=>escape mapping only takes place if the whole
> last key-sequence so far is just [?\e], i.e. either we're still in
> read-key-sequence, or the last read-key-sequence only read [?\e], which
> should ideally never happen because it should have been mapped to [escape].

Sounds good to me. At least, I can't think of a problematic situation,
currently. Let's how it works in practise.

Thank you for your efforts. I would never have thought of this
solution on my own.

Best regards,
Frank

bug#13709: bug#13793: 24.3.50; M-x broken in viper and X

[Frank Fischer]

On 02/26, Frank Fischer wrote:
> 
> Sounds good to me. At least, I can't think of a problematic situation,
> currently. Let's how it works in practise.

Ok, now I have problem. The keymap `input-decode-map` is
keyboard-local (according to the documentation). This means (and this
makes sense because the ESC prefix map in `input-decode-map` is
different for each keyboard) we have to 'patch' it for each new
keyboard. Unfortunately, I'm not sure how to do this right.
Currently I use an `after-make-frame-functions` hook and a
`delete-terminal-functions` hook (although the latter may not be
required) to save the original prefix map in the terminal parameter
`evil-esc-map` and change `input-decode-map` accordingly. I hope that
this sets the correct values for each "keyboard".

Is this the correct way to do? Or is it completely wrong ;)

Best regards,
Frank

bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

>> Sounds good to me.  At least, I can't think of a problematic situation,
>> currently.  Let's how it works in practise.
> Ok, now I have problem. The keymap `input-decode-map` is
> keyboard-local (according to the documentation).

Indeed it is, but that shouldn't be too hard to handle.

> This means (and this makes sense because the ESC prefix map in
> `input-decode-map` is different for each keyboard) we have to 'patch'
> it for each new keyboard.

Yes.

> Unfortunately, I'm not sure how to do this right.
> Currently I use an `after-make-frame-functions` hook and a
> `delete-terminal-functions` hook (although the latter may not be
> required) to save the original prefix map in the terminal parameter
> `evil-esc-map` and change `input-decode-map` accordingly. I hope that
> this sets the correct values for each "keyboard".

> Is this the correct way to do? Or is it completely wrong ;)

That sounds fine.  It would be better to use make-terminal-functions, but
you'd have to invent that hook first ;-(
BTW, you can take advantage of this opportunity to only install this
hack on tty terminals.


        Stefan

bug#13709: bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 3572 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Stefano Zacchiroli]

Heya, just checking back about the status of this bug report. I'm
affected by it and I've been stuck with Emacs 23 since its first arrival
(or else I can jump back on Emacs 24.3.x ditching viper all together,
which might even be a good thing for my saneness :-))

From the bug log it's not clear to me if a tentative solution is
available somewhere already or not. If so, I'll be happy to testdrive it
and give all the feedback you might need.  At present, unfortunately,
I'm not knowledgeable enough into Emacs internals to propose a patch, so
sorry for this patch-less ping.

Thank you all for maintaining Emacs!
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

> Heya, just checking back about the status of this bug report. I'm
> affected by it and I've been stuck with Emacs 23 since its first arrival
> (or else I can jump back on Emacs 24.3.x ditching viper all together,
> which might even be a good thing for my saneness :-))

I don't understand all of what Viper does with the ESC key, nor do
I know what are the different cases where ESC has to behave in
a specific way, so it's difficult for me to come up with
a trustworthy patch.

Could you try the patch below under X11 and under a tty, ideally even
using emacsclient to create new X11 and tty frames?

Michael, could you also take a look at this patch?


        Stefan


=== modified file 'lisp/emulation/viper-cmd.el'
--- lisp/emulation/viper-cmd.el	2013-06-18 20:24:44 +0000
+++ lisp/emulation/viper-cmd.el	2013-06-22 21:40:32 +0000
@@ -996,93 +996,7 @@
 	(suspend-emacs))
     (viper-change-state-to-emacs)))
 
-\f
-;; Intercept ESC sequences on dumb terminals.
-;; Based on the idea contributed by Marcelino Veiga Tuimil <mveiga@dit.upm.es>
-
-;; Check if last key was ESC and if so try to reread it as a function key.
-;; But only if there are characters to read during a very short time.
-;; Returns the last event, if any.
-(defun viper-envelop-ESC-key ()
-  (let ((event last-input-event)
-	(keyseq [nil])
-	(inhibit-quit t))
-    (if (viper-ESC-event-p event)
-	(progn
-	  ;; Some versions of Emacs (eg., 22.50.8 (?)) have a bug, which makes
-          ;; even a single ESC into a fast keyseq. To guard against this, we
-	  ;; added a check if there are other events as well.  Keep the next
-	  ;; line for the next time the bug reappears, so that will remember to
-	  ;; report it.
-	  ;;(if (and (viper-fast-keysequence-p) unread-command-events)
-	  (if (viper-fast-keysequence-p) ;; for Emacsen without the above bug
-	      (progn
-		(let (minor-mode-map-alist emulation-mode-map-alists)
-		  (viper-set-unread-command-events event)
-		  (setq keyseq (read-key-sequence nil 'continue-echo))
-		  ) ; let
-		;; If keyseq translates into something that still has ESC
-		;; at the beginning, separate ESC from the rest of the seq.
-		;; In XEmacs we check for events that are keypress meta-key
-		;; and convert them into [escape key]
-		;;
-		;; This is needed for the following reason:
-		;; If ESC is the first symbol, we interpret it as if the
-		;; user typed ESC and then quickly some other symbols.
-		;; If ESC is not the first one, then the key sequence
-		;; entered was apparently translated into a function key or
-		;; something (e.g., one may have
-		;; (define-key function-key-map "\e[192z" [f11])
-		;; which would translate the escape-sequence generated by
-		;; f11 in an xterm window into the symbolic key f11.
-		;;
-		;; If `first-key' is not an ESC event, we make it into the
-		;; last-command-event in order to pretend that this key was
-		;; pressed.  This is needed to allow arrow keys to be bound to
-		;; macros.  Otherwise, viper-exec-mapped-kbd-macro will think
-		;; that the last event was ESC and so it'll execute whatever is
-		;; bound to ESC. (Viper macros can't be bound to
-		;; ESC-sequences).
-		(let* ((first-key (elt keyseq 0))
-		       (key-mod (event-modifiers first-key)))
-		  (cond ((and (viper-ESC-event-p first-key)
-			      (not (viper-translate-all-ESC-keysequences)))
-			 ;; put keys following ESC on the unread list
-			 ;; and return ESC as the key-sequence
-			 (viper-set-unread-command-events (viper-subseq keyseq 1))
-			 (setq last-input-event event
-			       keyseq (if (featurep 'emacs)
-					  "\e"
-					(vector (character-to-event ?\e)))))
-			((and (featurep 'xemacs)
-			      (key-press-event-p first-key)
-			      (equal '(meta) key-mod))
-			 (viper-set-unread-command-events
-			  (vconcat (vector
-				    (character-to-event (event-key first-key)))
-				   (viper-subseq keyseq 1)))
-			 (setq last-input-event event
-			       keyseq (vector (character-to-event ?\e))))
-			((eventp first-key)
-			 (setq last-command-event
-			       (viper-copy-event first-key)))
-			))
-		) ; end progn
-
-	    ;; this is escape event with nothing after it
-	    ;; put in unread-command-event and then re-read
-	    (viper-set-unread-command-events event)
-	    (setq keyseq (read-key-sequence nil))
-	    ))
-      ;; not an escape event
-      (setq keyseq (vector event)))
-    keyseq))
-
-
-
 ;; Listen to ESC key.
-;; If a sequence of keys starting with ESC is issued with very short delays,
-;; interpret these keys in Emacs mode, so ESC won't be interpreted as a Vi key.
 (defun viper-intercept-ESC-key ()
   "Function that implements ESC key in Viper emulation of Vi."
   (interactive)
@@ -1090,13 +1004,7 @@
   ;; minor-mode map(s) have been temporarily disabled so the ESC
   ;; binding to viper-intercept-ESC-key doesn't hide the binding we're
   ;; looking for (Bug#9146):
-  (let* ((event (viper-envelop-ESC-key))
-	 (cmd (cond ((equal event viper-ESC-key)
-		     'viper-intercept-ESC-key)
-		    ((let ((emulation-mode-map-alists nil))
-		       (key-binding event)))
-		    (t
-		     (error "Viper bell")))))
+  (let* ((cmd 'viper-intercept-ESC-key))
 
     ;; call the actual function to execute ESC (if no other symbols followed)
     ;; or the key bound to the ESC sequence (if the sequence was issued

=== modified file 'lisp/emulation/viper-keym.el'
--- lisp/emulation/viper-keym.el	2013-01-01 09:11:05 +0000
+++ lisp/emulation/viper-keym.el	2013-06-22 21:43:10 +0000
@@ -192,7 +192,7 @@
   :type 'string
   :group 'viper)
 
-(defvar viper-ESC-key (kbd "ESC")
+(defconst viper-ESC-key [escape]
   "Key used to ESC.")
 
 

=== modified file 'lisp/emulation/viper.el'
--- lisp/emulation/viper.el	2013-03-12 02:08:21 +0000
+++ lisp/emulation/viper.el	2013-06-22 21:54:55 +0000
@@ -660,7 +660,7 @@
 undone.
 It also can't undo some Viper settings."
   (interactive)
-
+  (viper-setup-ESC-to-escape nil)
   ;; restore non-viper vars
   (setq-default
    next-line-add-newlines
@@ -825,6 +825,58 @@
   (add-hook 'viper-post-command-hooks 'set-viper-state-in-major-mode t))
 
 
+;;; Handling of tty's ESC event
+
+;; On a tty, an ESC event can either be the user hitting the escape key, or
+;; some element of a byte sequence used to encode for example cursor keys.
+;; So we try to recognize those events that correspond to the escape key and
+;; turn them into `escape' events (same as used under GUIs).  The heuristic we
+;; use to distinguish the two cases is based, as usual, on a timeout, and on
+;; the fact that the special ESC=>escape mapping only takes place if the whole
+;; last key-sequence so far is just [?\e], i.e. either we're still in
+;; read-key-sequence, or the last read-key-sequence only read [?\e], which
+;; should ideally never happen because it should have been mapped to [escape].
+
+(defun viper--tty-ESC-filter (map)
+  (if (and (equal (this-single-command-keys) [?\e])
+           (sit-for (/ viper-fast-keyseq-timeout 1000)))
+      [escape] map))
+
+(defun viper--lookup-key (map key)
+  "Kind of like `lookup-key'.
+Two differences:
+- KEY is a single key, not a sequence.
+- the result is the \"raw\" binding, so it can be a `menu-item', rather than the
+  binding contained in that menu item."
+  (catch 'found
+    (map-keymap (lambda (k b) (if (equal key k) (throw 'found b))) map)))
+
+(defun viper-catch-tty-ESC ()
+  "Setup key mappings of current terminal to turn a tty's ESC into `escape'."
+  (when (memq (terminal-live-p (frame-terminal)) '(t pc))
+    (let ((esc-binding (viper-uncatch-tty-ESC)))
+      (define-key input-decode-map
+        [?\e] `(menu-item "" ,esc-binding :filter viper--tty-ESC-filter)))))
+
+(defun viper-uncatch-tty-ESC ()
+  "Don't hack ESC into `escape' any more."
+  (let ((b (viper--lookup-key input-decode-map ?\e)))
+    (and (eq 'menu-item (car-safe b))
+         (eq 'viper--tty-ESC-filter (nth 4 b))
+         (define-key input-decode-map [?\e] (setq b (nth 2 b))))
+    b))
+
+(defun viper-setup-ESC-to-escape (enable)
+  (if enable
+      (add-hook 'tty-setup-hook 'viper-catch-tty-ESC)
+    (remove-hook 'tty-setup-hook 'viper-catch-tty-ESC))
+  (let ((seen ()))
+    (dolist (frame (frame-list))
+      (let ((terminal (frame-terminal frame)))
+        (unless (memq terminal seen)
+          (push terminal seen)
+          (with-selected-frame frame
+            (if enable (viper-catch-tty-ESC) (viper-uncatch-tty-ESC))))))))
 
 ;; This sets major mode hooks to make them come up in vi-state.
 (defun viper-set-hooks ()
@@ -837,6 +889,8 @@
   (if (eq (default-value 'major-mode) 'fundamental-mode)
       (setq-default major-mode 'viper-mode))
 
+  (viper-setup-ESC-to-escape t)
+
   (add-hook 'change-major-mode-hook 'viper-major-mode-change-sentinel)
   (add-hook 'find-file-hooks 'set-viper-state-in-major-mode)
 
@@ -847,13 +901,6 @@
   (defvar emerge-startup-hook)
   (add-hook 'emerge-startup-hook 'viper-change-state-to-emacs)
 
-  ;; Zap bad bindings in flyspell-mouse-map, which prevent ESC from working
-  ;; over misspelled words (due to the overlay keymaps)
-  (defvar flyspell-mode-hook)
-  (defvar flyspell-mouse-map)
-  (add-hook 'flyspell-mode-hook
-	    (lambda ()
-              (define-key flyspell-mouse-map viper-ESC-key nil)))
   ;; if viper is started from .emacs, it might be impossible to get certain
   ;; info about the display and windows until emacs initialization is complete
   ;; So do it via the window-setup-hook

=== modified file 'lisp/faces.el'
--- lisp/faces.el	2013-05-15 23:55:41 +0000
+++ lisp/faces.el	2013-06-22 20:22:31 +0000
@@ -2126,7 +2126,8 @@
 		       type)
 	(when (fboundp term-init-func)
 	  (funcall term-init-func))
-	(set-terminal-parameter frame 'terminal-initted term-init-func)))))
+        (set-terminal-parameter frame 'terminal-initted term-init-func)
+	(run-hooks 'tty-setup-hook)))))
 
 ;; Called from C function init_display to initialize faces of the
 ;; dumped terminal frame on startup.

bug#13793: 24.3.50; M-x broken in viper and X

[Stefano Zacchiroli]

On Sat, Jun 22, 2013 at 05:56:28PM -0400, Stefan Monnier wrote:
> Could you try the patch below under X11 and under a tty, ideally even
> using emacsclient to create new X11 and tty frames?

Hi Stefan, I've just tried the patch (sorry for the delay, but in the
process I stumbled upon #14596 and I was short on time, found only now
the workaround for that).

The patch works in fixing the M-x issue, which now works fine in both
console (emacsclient -t) and GUI (emacsclient -c) clients.

Unfortunately, the patch has a very nasty side-effect: it makes
impossible to leave insert mode in console clients. Hitting ESC result
(after the expected brief delay) in "ESC-" being shown in the Emacs
minibuffer, but the nothing else happens. The key remains shown there
indefinitely, whereas Viper remains in insert mode (<I> shown in the
line just above the minibuffer). Hitting some other key then makes the
"ESC-" message going away (presumably because ESC-that_char is not
mapped to anything meaningful), but that's hit. There's no way to leave
insert mode.

On the other hand, everything works fine in the GUI clients, where both
M-x and entering/leaving insert mode work as expected.

For the sake of debugging, I've also tried to open in parallel the same
buffer in a side-by-side console and GUI clients. It is possible to
enter insert mode in the console client, and then use the GUI client to
leave it. This was probably obvious to you, but it shows to me that the
issue is in the interaction with the client, and not a sticky property
of the underlying buffer.

Thanks a lot for a first stab at the patch, I really appreciate.

Hope this feedback helps,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

> Unfortunately, the patch has a very nasty side-effect: it makes
> impossible to leave insert mode in console clients. Hitting ESC result
> (after the expected brief delay) in "ESC-" being shown in the Emacs
> minibuffer, but the nothing else happens.

Hmm... I don't see this here:

   % emacs -Q
   M-x viper-mode
   5 n
   i test ESC

Please, note that the patch includes a change to lisp/faces.el which is
a preloaded file, so you either need to regenerate (aka "redump")
src/emacs after byte-compiling the new lisp/faces.el or to manually call
M-x load-libbrary RET faces RET after starting `emacs'.


        Stefan

bug#13793: 24.3.50; M-x broken in viper and X

[Stefano Zacchiroli]

On Tue, Jun 25, 2013 at 12:17:27PM -0400, Stefan Monnier wrote:
> Please, note that the patch includes a change to lisp/faces.el which is
> a preloaded file, so you either need to regenerate (aka "redump")
> src/emacs after byte-compiling the new lisp/faces.el or to manually call
> M-x load-libbrary RET faces RET after starting `emacs'.

That was it. By doing so I can confirm that the patch works with various
combinations of daemon/non-daemon, console/GUI, etc.

Thanks for it!
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

>> Please, note that the patch includes a change to lisp/faces.el which is
>> a preloaded file, so you either need to regenerate (aka "redump")
>> src/emacs after byte-compiling the new lisp/faces.el or to manually call
>> M-x load-libbrary RET faces RET after starting `emacs'.

> That was it. By doing so I can confirm that the patch works with various
> combinations of daemon/non-daemon, console/GUI, etc.

Thanks for testing it.
Michael, what's your opinion on the patch?


        Stefan

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 1658 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 1700 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Stefano Zacchiroli]

On Tue, Jul 02, 2013 at 03:55:50AM -0400, Michael Kifer wrote:
>             Stefan
> 
> actually, I just updated to the latest version of emacs from bzr and it breaks
> Viper completely.
> Even M-x does not work: says M-x is undefined.
> I thought the previous reports were talking only about terminal windows.

Is that with or without Stefan's patch? I'm using right now an Emacs
development snapshot from yesterday, with Stefan's patch applied, and
everything works fine here.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 1376 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Glenn Morris]

Michael Kifer wrote:

>     Even M-x does not work: says M-x is undefined.

Probably `make bootstrap' will fix that.

PS any chance you could use plain text email rather than html?

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

On 07/02/2013 11:47 AM, Glenn Morris wrote:
> Michael Kifer wrote:
>
>>      Even M-x does not work: says M-x is undefined.
> Probably `make bootstrap' will fix that.

of course I did that.

> PS any chance you could use plain text email rather than html?

It should be sending both plain text and html and your mail client 
should be deciding what to display.

bug#13793: 24.3.50; M-x broken in viper and X

[Glenn Morris]

Michael Kifer wrote:

>> Probably `make bootstrap' will fix that.
>
> of course I did that.

I misunderstood, you are just seeing the reported viper problem.
(I thought you meant that emacs -Q M-x did not work.)

>> PS any chance you could use plain text email rather than html?
>
> It should be sending both plain text and html and your mail client
> should be deciding what to display.

No, all previous messages from you on this subject have been html-only.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13793#19
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13793#51
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13793#57
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13793#72
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13793#75
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13793#81

The latest was ok:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13793#87

bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

> However, I am concerned how it works under XEmacs.

Not sure how to get it to work in both, indeed.  The faces.el patch is
not indispensable (we could probably come up with some other hook for
it), but I'm not sure if XEmacs provides something equivalent to
input-decode-map.

> actually, I just updated to the latest version of emacs from bzr and it
> breaks Viper completely.

Right, that's what this discussion is all about.

> Even M-x does not work: says M-x is undefined.
> I thought the previous reports were talking only about terminal windows.

No, the previous reports are about GUI frames,


        Stefan

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 10946 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

> I missed that bug report.  Can you point me to the relevant message?
> I should be able to take a look next weekend. 

You can see for yourself, the bug number is in the subject:
http://debbugs.gnu.org/13793


        Stefan

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 1325 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 10952 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 10919 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Glenn Morris]

Michael Kifer wrote:

>     ok. I committed your patch along with some of my other changes. <br>

You haven't committed anything to the Emacs repo AFAICS.
Maybe you forgot to push the changes, or something.

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

[-- Attachment #1: Type: text/html, Size: 5494 bytes --]

bug#13793: 24.3.50; M-x broken in viper and X

[Glenn Morris]

Michael Kifer wrote:

>     revno: 113293<br>
>     committer: Michael Kifer <a class="moz-txt-link-rfc2396E" href="mailto:kifer@cs.stonybrook.edu">&lt;kifer@cs.stonybrook.edu&gt;</a><br>
>     branch nick: trunk<br>
>     timestamp: Fri 2013-07-05 18:50:16 -0400<br>
>     message:<br>
>     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * faces.el&nbsp; (tty-run-terminal-initialization): function

(As you can see, this is still html-only and hard to read.)

That revision is not in the Emacs repository.
Here is revision 113293 in Emacs:

http://lists.gnu.org/archive/html/emacs-diffs/2013-07/msg00065.html

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

On 07/06/2013 05:01 PM, Glenn Morris wrote:
> Michael Kifer wrote:
>
>>      revno: 113293<br>
>>      committer: Michael Kifer <a class="moz-txt-link-rfc2396E" href="mailto:kifer@cs.stonybrook.edu">&lt;kifer@cs.stonybrook.edu&gt;</a><br>
>>      branch nick: trunk<br>
>>      timestamp: Fri 2013-07-05 18:50:16 -0400<br>
>>      message:<br>
>>      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * faces.el&nbsp; (tty-run-terminal-initialization): function
> (As you can see, this is still html-only and hard to read.)

Yeah, need to check. It is supposed to send in both formats.

>
> That revision is not in the Emacs repository.
> Here is revision 113293 in Emacs:
>
> http://lists.gnu.org/archive/html/emacs-diffs/2013-07/msg00065.html

Hmm. Where could it be?

   /home/kifer/gnu/emacs/trunk> bzr info

    Repository tree (format: 2a)
    Location:
       shared repository: /home/kifer/gnu/emacs
       repository branch: .

    Related branches:
      parent branch: bzr+ssh://kifer@bzr.savannah.gnu.org/emacs/trunk/

Will check later where it went.

bug#13793: 24.3.50; M-x broken in viper and X

[Stephen Berman]

On Sat, 06 Jul 2013 17:16:11 -0400 Michael Kifer <michael.kifer@stonybrook.edu> wrote:

> On 07/06/2013 05:01 PM, Glenn Morris wrote:
>> Michael Kifer wrote:
>>
>>>      revno: 113293<br>
>>>      committer: Michael Kifer <a class="moz-txt-link-rfc2396E"
>>> href="mailto:kifer@cs.stonybrook.edu">&lt;kifer@cs.stonybrook.edu&gt;</a><br>
>>>      branch nick: trunk<br>
>>>      timestamp: Fri 2013-07-05 18:50:16 -0400<br>
>>>      message:<br>
>>>      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * faces.el&nbsp;
>>> (tty-run-terminal-initialization): function
>> (As you can see, this is still html-only and hard to read.)
>
> Yeah, need to check. It is supposed to send in both formats.
>
>>
>> That revision is not in the Emacs repository.
>> Here is revision 113293 in Emacs:
>>
>> http://lists.gnu.org/archive/html/emacs-diffs/2013-07/msg00065.html
>
> Hmm. Where could it be?
>
>   /home/kifer/gnu/emacs/trunk> bzr info
>
>    Repository tree (format: 2a)
>    Location:
>       shared repository: /home/kifer/gnu/emacs
>       repository branch: .
>
>    Related branches:
>      parent branch: bzr+ssh://kifer@bzr.savannah.gnu.org/emacs/trunk/
>
> Will check later where it went.

Could it be that your checkout of trunk is not a bound branch?  bzr
infor on mine, which is bound, looks like this:

steve@rosalinde:~/bzr/emacs/trunk> bzr info
Repository checkout (format: 2a)
Location:
  repository checkout root: .
        checkout of branch: bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk/
         shared repository: /data/steve/bzr/emacs

Related branches:
  public branch: bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk
  parent branch: bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk/
  submit branch: /data/steve/bzr/emacs/todos

while bzr info on my quickfixes branch, which is not bound, looks like
your trunk info:

steve@rosalinde:~/bzr/emacs/quickfixes> bzr info
Repository tree (format: 2a)
Location:
  shared repository: /data/steve/bzr/emacs
  repository branch: .

Related branches:
  parent branch: bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk/

Steve Berman

bug#13793: 24.3.50; M-x broken in viper and X

[Stephen Berman]

On Sat, 06 Jul 2013 23:27:30 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Sat, 06 Jul 2013 17:16:11 -0400 Michael Kifer
> <michael.kifer@stonybrook.edu> wrote:
>
>> On 07/06/2013 05:01 PM, Glenn Morris wrote:
>>> Michael Kifer wrote:
>>>
>>>>      revno: 113293<br>
>>>>      committer: Michael Kifer <a class="moz-txt-link-rfc2396E"
>>>> href="mailto:kifer@cs.stonybrook.edu">&lt;kifer@cs.stonybrook.edu&gt;</a><br>
>>>>      branch nick: trunk<br>
>>>>      timestamp: Fri 2013-07-05 18:50:16 -0400<br>
>>>>      message:<br>
>>>>      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * faces.el&nbsp;
>>>> (tty-run-terminal-initialization): function
>>> (As you can see, this is still html-only and hard to read.)
>>
>> Yeah, need to check. It is supposed to send in both formats.
>>
>>>
>>> That revision is not in the Emacs repository.
>>> Here is revision 113293 in Emacs:
>>>
>>> http://lists.gnu.org/archive/html/emacs-diffs/2013-07/msg00065.html
>>
>> Hmm. Where could it be?
>>
>>   /home/kifer/gnu/emacs/trunk> bzr info
>>
>>    Repository tree (format: 2a)
>>    Location:
>>       shared repository: /home/kifer/gnu/emacs
>>       repository branch: .
>>
>>    Related branches:
>>      parent branch: bzr+ssh://kifer@bzr.savannah.gnu.org/emacs/trunk/
>>
>> Will check later where it went.
>
> Could it be that your checkout of trunk is not a bound branch?  bzr
> infor on mine, which is bound, looks like this:
>
> steve@rosalinde:~/bzr/emacs/trunk> bzr info
> Repository checkout (format: 2a)
> Location:
>   repository checkout root: .
>         checkout of branch: bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk/
>          shared repository: /data/steve/bzr/emacs
>
> Related branches:
>   public branch: bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk
>   parent branch: bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk/
>   submit branch: /data/steve/bzr/emacs/todos
>
> while bzr info on my quickfixes branch, which is not bound, looks like
> your trunk info:
>
> steve@rosalinde:~/bzr/emacs/quickfixes> bzr info
> Repository tree (format: 2a)
> Location:
>   shared repository: /data/steve/bzr/emacs
>   repository branch: .
>
> Related branches:
>   parent branch: bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk/


I should have added that you can check whether your trunk checkout is
bound by looking at
/home/kifer/gnu/emacs/trunk/.bzr/branch/branch.conf -- here is mine:

parent_location = bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk/
public_branch = bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk
bound_location = bzr+ssh://srb@bzr.savannah.gnu.org/emacs/trunk/
bound = True
submit_branch = file:///data/steve/bzr/emacs/todos/

Steve Berman

bug#13793: 24.3.50; M-x broken in viper and X

[Michael Kifer]

On 07/06/2013 05:01 PM, Glenn Morris wrote:
> Michael Kifer wrote:
>
>>      revno: 113293<br>
>>      committer: Michael Kifer <a class="moz-txt-link-rfc2396E" href="mailto:kifer@cs.stonybrook.edu">&lt;kifer@cs.stonybrook.edu&gt;</a><br>
>>      branch nick: trunk<br>
>>      timestamp: Fri 2013-07-05 18:50:16 -0400<br>
>>      message:<br>
>>      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * faces.el&nbsp; (tty-run-terminal-initialization): function
> (As you can see, this is still html-only and hard to read.)
>
> That revision is not in the Emacs repository.
> Here is revision 113293 in Emacs:
>
> http://lists.gnu.org/archive/html/emacs-diffs/2013-07/msg00065.html
ok, the commit seems to be there now.

bug#13793: 24.3.50; M-x broken in viper and X

[Stefan Monnier]

> ok. I committed your patch along with some of my other changes. 

Thank you Michael,


        Stefan