help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Recording elisp macro instead of keyboard macros - where are the difficu


From: 杨朝晖
Subject: Recording elisp macro instead of keyboard macros - where are the difficulties?
Date: Thu, 25 Oct 2007 19:30:16 +0800
User-agent: KMail/1.9.7

After defining and using some keyboard macros and exposing to some elisp
code, I asked myself "what if keyboard macros are recorded as elisp code?".

Since it's not there, there must be some reason. So I did some searched, and
found some information:

There were others asking for the same functionality since the 1980's, in
this list and other places. But things does not change much. 

The best thing we have today is edit-kbd-macro, which explains keys in a
keyboard macro with associated commands and allows modification. The
downside is that it carries wrong explanations, e.g. saperating input from
interactive commands, treating them as 'self-insert-command' and 'newline'.

There was an effort to implement such a thing - some 'generate.el' found in
the elisp code archives dating back to 1989. That code still runs without
error in emacs22, but leaves out A LOT OF commands in the generated code,
mainly movement keys and isearch.


Then I looked into the code, with these findings:
1. edit-kbd-macro works with keyboard maps, so it's natural it cannot group
interactive commands with their inputs(args). And it's prone to keyboard
map changes.
2. generate.el works with command-history, which leaves out a lot of
commands itself.
3. The built-in keyboard macro recording and executing functionality is in
emacs's C source code ( around read_char, read_key_sequence, and
command_loop_{1,2} ).

So, there might be some not so easy solution:
1. provide another version of command-history (e.g.
detailed-command-history), that can be used to extract a complete operation
history.
2. modify the keyboard macro implementation to record lisp functions called
instead of key-strikes.

My question here is how difficult is it to implement 1 or 2 in emacs?
Option 1 seems not so difficult but I must be lacking enough knowledge about
emacs internals to judge. It would have been done if it were "not so
difficult".

Any ideas, suggestions, or flames? Please let them out :)

-- 
    regards,
yzhh




reply via email to

[Prev in Thread] Current Thread [Next in Thread]