Re: `special' keys in keyboard macros

Re: `special' keys in keyboard macros

[Thomas Dickey]

Roland Winkler <Roland.Winkler@physik.uni-erlangen.de> wrote:

> PPS  It seems to me that it is not a problem of "emacs -nw" but of
> xterm that \C-? is always interpreted as backspace. I was long using

control/? sounds like code 128, which is of course the usual setting
for the backarrow key with Debian Linux.  If emacs chooses to treat
the stty erase value as backspace, that's understandable.  However,
backspace is properly a code 8.

> \C-? as a distinct key with "emacs (X)" but now I realized it
> doesn't work with "emacs -nw". Is there somewhere a list of
> keybindings one should avoid if compatibility between "emacs (X)"
> and "emacs -nw" is an issue?



-- 
Thomas E. Dickey
http://dickey.his.com
ftp://dickey.his.com

`special' keys in keyboard macros

[Roland Winkler]

In GNU Emacs 21.2.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-04-09 on tfkp12
configured using `configure  --prefix=/nfs/common --libexecdir=/nfs/common/lib --bindir=/nfs/common/lib/emacs/21.2/bin/i686-Linux --mandir=/nfs/common/share/man --infodir=/nfs/common/share/info --with-gcc --with-pop --with-x --with-x-toolkit=athena i386-pc-linux'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: nil

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:


I am having some problems with `special' keys like the return key
when I am defining and storing keyboard macros.

For example, I might want to define a keyboard macro that runs the
commands bound to the keys RET, left-arrow, right-arrow, up-arrow,
down-arrow, insert, delete and backspace.

When emacs runs in its own X window [for short: "emacs (X)"] I get
the keyboard macro

;; "emacs (X)"
(fset 'foo
   [return left right up down insert delete backspace])

On the other hand "emacs -nw" gives me for the same key sequence

;; "emacs -nw"
(fset 'bar
   "\C-m\C-[OD\C-[OC\C-[OA\C-[OB\C-[[2~\C-[[3~\C-?")

The problem is: "emacs -nw" cannot make use of the keyboard macro
foo and "emacs (X)" cannot make use of the macro bar either.

The problem applies to both my quickly hacked keyboard macros as
well as to my personalized keybindings that use the macro kbd (i.e.,
which string KEYS should be passed to kbd such that I get the same
keybindings using "emacs -nw" and "emacs (X)").

Roland

PS  Recently I rediscovered the beauty and efficiency of "emacs -nw"
when I am forced to use a slow modem connection.

PPS  It seems to me that it is not a problem of "emacs -nw" but of
xterm that \C-? is always interpreted as backspace. I was long using
\C-? as a distinct key with "emacs (X)" but now I realized it
doesn't work with "emacs -nw". Is there somewhere a list of
keybindings one should avoid if compatibility between "emacs (X)"
and "emacs -nw" is an issue?

Re: `special' keys in keyboard macros

[Richard Stallman]

    When emacs runs in its own X window [for short: "emacs (X)"] I get
    the keyboard macro

    ;; "emacs (X)"
    (fset 'foo
       [return left right up down insert delete backspace])

    On the other hand "emacs -nw" gives me for the same key sequence

    ;; "emacs -nw"
    (fset 'bar
       "\C-m\C-[OD\C-[OC\C-[OA\C-[OB\C-[[2~\C-[[3~\C-?")

    The problem is: "emacs -nw" cannot make use of the keyboard macro
    foo and "emacs (X)" cannot make use of the macro bar either.

The cause of this problem is obvious; what's amazing is that I never
thought of it until you pointed it out.

It seems that a solution might be to do the processing through
function-key-map before recording keys in the keyboard macro.  I
looked at the code, and this is not trivial, so I won't try to write
it now.  I think it would take a bit of hard debugging to make this
work right in all cases.  Basically, you'd need to make
read_key_sequence remove, from the keyboard macro being defined, the
characters it reads, and then record the translated versions of them.

To be entirely correct, the characters you record should not have been
translated through key-translation-map, only through function-key-map.

Re: `special' keys in keyboard macros

[Stefan Monnier]

> To be entirely correct, the characters you record should not have been
> translated through key-translation-map, only through function-key-map.

It is not possible to do this 100% correctly.
Maybe we can record the pre-processed keys and temporarily bind
function-key-map and key-translation-map to nil while executing
a macro, but that seems risky as well.
Another possibility is to record commands names instead of keys.

All in all, it seems that a "quick" 90% solution might be the best
available option.


        Stefan

Re: `special' keys in keyboard macros

[Richard Stallman]

    Maybe we can record the pre-processed keys and temporarily bind
    function-key-map and key-translation-map to nil while executing
    a macro, but that seems risky as well.

You are right that we would want to turn off processing of
function-key-map when replaying a macro, if it records the results
of function-key-map translation.

key-translation-map is a different story entirely.  It should be
handled as now: processed when executing the macro.

    Another possibility is to record commands names instead of keys.

That is possible, but I tend to think it is the wrong approach.

Re: `special' keys in keyboard macros

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Another possibility is to record commands names instead of keys.
> 
> That is possible, but I tend to think it is the wrong approach.

I agree.  

For example, it is not sufficient to record just commands names for
commands like self-insert-command and digit-argument which make no
sense "out of context".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: `special' keys in keyboard macros

[Roland Winkler]

On     Oct 15 2003 Kim F. Storm wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> >     Another possibility is to record commands names instead of keys.
> > 
> > That is possible, but I tend to think it is the wrong approach.
> 
> I agree.  
> 
> For example, it is not sufficient to record just commands names for
> commands like self-insert-command and digit-argument which make no
> sense "out of context".

I think it would be neat to have some better support for converting
"dirty", quickly hacked keyboard macros into "clean" elisp commands.
The command edit-kbd-macro gives some idea how the keys are
translated into commands. But for more complex keyboard macros (such
as those using recursive edit during execution of the macro) it will
be rather tricky to provide an automated mechanism for converting
keyboard macros into elisp commands. Up to now, I do not even have
an idea what kind of new features might be useful to support such a
conversion.

In any case, it appears to me that this is a rather different issue
than what I addressed in the bug report.

Roland

Re: `special' keys in keyboard macros

[Robert J. Chassell]

Roland Winkler <Roland.Winkler@physik.uni-erlangen.de> wrote

    I think it would be neat to have some better support for
    converting "dirty", quickly hacked keyboard macros into "clean"
    elisp commands.

A decade or more ago, David Gillespie included a function that
converted key strokes to Emacs Lisp in his Emacs Calc mode.  Instead
of running `kmacro-start-macro/ kmacro-start-macro' and end up with a
keyboard macro, you would run this function the same way (possibly
bound to the same keys) and end up with an Emacs Lisp defun.

Unfortunately, I cannot find the feature any more.  It is not in any
recent version of Calc, nor any other place I have looked.  Nor can I
remember what it is called, except that I think it had `edit' in its
name.

Someone with more access to old Emacs Lisp libraries might find it.  
Or maybe it is hidden in the current Emacs Calc code and I just have
not seen it.

As with the RMIME libraries I mentioned earlier, this code is not
likely to come with proper papers (although it was, if I remember
rightly, part of Calc mode -- so maybe it does have papers).  In any
case, the defuns produced were not the best; and would need
enhancement to emulate the current `kmacro-start-macro/
kmacro-start-macro' tools.

But you should be able to look at the code and run the function as it
is, and see what it does -- it could be a help.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: `special' keys in keyboard macros

[Richard Stallman]

    I think it would be neat to have some better support for converting
    "dirty", quickly hacked keyboard macros into "clean" elisp commands.
    The command edit-kbd-macro gives some idea how the keys are
    translated into commands. But for more complex keyboard macros (such
    as those using recursive edit during execution of the macro) it will
    be rather tricky to provide an automated mechanism for converting
    keyboard macros into elisp commands.

It is a reasonable feature to add, and in fact Multics Emacs had such
a feature.  However, I think that many of the features in etc/TODO are
more important than this.