From: Richard Stallman <rms@gnu.org>
To: yzhh <yezonghui@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: recording-elisp.el - try recording commands as elisp code
Date: Mon, 05 Nov 2007 01:20:04 -0500 [thread overview]
Message-ID: <E1IovJc-00052V-Sf@fencepost.gnu.org> (raw)
In-Reply-To: <fgk17d$ha6$1@ger.gmane.org> (message from yzhh on Sun, 04 Nov 2007 16:51:49 +0800)
However, two things I mentioned above are difficult to do right:
1. "recognize whether a string is killed during the recording". There are
quite a few sources for yanking, including the whole kill-ring. Tracking
them all is asking for trouble.
You're being too perfectionist.
Please stop asking whether you can "track them all",
and instead work on tracking common cases.
I am sure you will succeed. The only question is how far
you can carry it.
rms's approach want: (isearch-forward) (isearch-append-string "abc")
(isearch-yank-kill) (isearch-repeat-forward) (isearch-exit)
Well, isearch-append-string is imagined, the most close thing we have is
isearch-printing-char (WITH NO ARGS). AFAIK, this and
other "lack-of-support" reason rendered rms's approach impossible for now.
We can add isearch-append-string for this.
> Likewise, if a macro does a search with C-s C-s (using the default
> from before the macro), it is far better to generate a program that
> will use the default, rather than one which uses a constant.
That might be "kbd macro" thinking. For recorded lisp code, it's better to
modify it to receive an arg "interactively", than to receive it from
previous prepared "runtime environment" (in this case, the latest search
string).
That is a good idea. Please do it that way.
The same argument would apply to yanking something that was not
killed within the same macro.
We may provide an option "recording minibuffer editing on/off", or even
provide commands to switch it during the recording. But the real challenge
is not recording but replaying. Example: M-x previ TAB line RET
The recorded commands:
(execute-extended-command nil)
(insert "previ")
(minibuffer-complete)
(insert "line")
(previous-line 1 1)
can not be replayed directly, because running the first command will prompt
the user for input instead of continue running.
The code to set up an argument in the minibuffer needs to be converted
into computing the argument to pass to a function.
However, mere completion in most cases can be treated as a constant.
Thus, if the user types M-x que SPC SPC SPC RET, there is no need
for your code to go through the routine of completing `que'.
You should just generate a call to `query-replace-region'.
The only possible exceptions to that statement are cases where the
effect of the completion is very dynamic. I don't know whether any
such cases exist; I mention the possibility because I am not yet
convinced there are none.
Thus, the issue that complicates minibuffer args is not completion.
It is yanking.
next prev parent reply other threads:[~2007-11-05 6:20 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-01 21:27 recording-elisp.el - try recording commands as elisp code yzhh
2007-11-01 23:01 ` Juri Linkov
2007-11-02 5:39 ` yzhh
2007-11-02 20:46 ` Juri Linkov
2007-11-03 3:35 ` yzhh
2007-11-03 10:21 ` Reiner Steib
2007-11-04 5:02 ` yzhh
2007-11-02 2:06 ` Richard Stallman
2007-11-02 5:44 ` yzhh
2007-11-03 3:58 ` Richard Stallman
2007-11-03 7:14 ` yzhh
2007-11-02 6:14 ` yzhh
2007-11-02 20:45 ` Juri Linkov
2007-11-03 3:57 ` yzhh
2007-11-03 20:48 ` Richard Stallman
2007-11-04 8:51 ` yzhh
2007-11-04 16:48 ` Drew Adams
2007-11-05 5:40 ` yzhh
2007-11-06 2:16 ` Richard Stallman
2007-11-06 6:29 ` yzhh
2007-11-07 0:15 ` Richard Stallman
2007-11-06 16:33 ` Mathias Dahl
2007-11-06 22:28 ` Juri Linkov
2007-11-07 7:55 ` Richard Stallman
2007-11-05 6:20 ` Richard Stallman [this message]
2007-11-05 14:27 ` yzhh
2007-11-05 14:43 ` Stefan Monnier
2007-11-05 15:03 ` yzhh
2007-11-06 2:16 ` Richard Stallman
2007-11-06 8:28 ` Stefan Monnier
2007-11-05 6:20 ` Richard Stallman
2007-11-06 0:45 ` Juri Linkov
2007-11-06 6:12 ` yzhh
2007-11-07 0:15 ` Richard Stallman
2007-11-06 8:37 ` Richard Stallman
2007-11-06 22:28 ` Juri Linkov
2007-11-07 7:56 ` Richard Stallman
2007-11-02 21:28 ` Stefan Monnier
2007-11-03 4:23 ` yzhh
2007-11-03 3:58 ` Richard Stallman
2007-11-03 7:12 ` yzhh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1IovJc-00052V-Sf@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=yezonghui@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.