From: yzhh <yezonghui@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: recording-elisp.el - try recording commands as elisp code
Date: Sun, 04 Nov 2007 16:51:49 +0800 [thread overview]
Message-ID: <fgk17d$ha6$1@ger.gmane.org> (raw)
In-Reply-To: E1IoPv2-0004iy-5b@fencepost.gnu.org
Richard Stallman wrote:
> It was suggested:
>
> > I think it is enough to convert the isearch exit event with the
> > last search string to the calls of search-forward, search-backward,
> > re-search-forward and re-search-backward.
>
> That is a good approach for the simple cases. But if the user yanks
> into the search, it is important to at least try to reproduce the
> effect of the yanking. Even if it can't work right in all cases, at
> least it should work right in simple cases.
In the case of iserach. I think it might be a good approach to output a
constant string search when the yanked string is not killed during the
recording, and to output a yank-in-the-search when the killing is also
recorded.
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.
2. "output a yank-in-the-search". That is actually to require reproducing
the whole isearch session, since the yanking can happen anytime during
isearch, and can be surrounded by other search string editing. That's
really really difficult - the required information is NOT ALL available
from recorded isearch commands and the isearch state stack.
My current implementation does neither. To illustrate, let's see what we get
for this isearch session (3 searches are all successful):
C-s abc M-y(yank "def" from kill-ring) C-s RET
Juri's approach get: (search-forward "abcdef")
My implementation get: (search-forward "abc") (search-forward "abcdef"
(search-forward "abcdef")
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.
What do we really want here?
> 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).
If you're talking about kill-and-yank during the recording, that's
reasonable. Then my analysis above and bellow apply.
> The same goes for minibuffers. When someone uses completion in a
> minibuffer, there are many cases where using the end result as a
> constant is best, and perhaps that is always good; but there could be
> some cases where it is important to repeat the completion operation.
> (I am not sure.) And yanking into the minibuffer ought to be repeated.
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. This is a foundmental
difference between kbd macro and lisp code. And I don't known how to
do "call-interactively without promting the user" from code.
Another issue is with recognizing (previous-line ...) as "to be deleted" to
avoid doing it twice. We'll have to put some flag on this recorded command
at recording time, and this flag depends on a previous
(execute-extendied-command nil) plus 'leaving minibuffer' event.
> As regards isearch-case-fold-search, I think it is ok to ignore that.
> The generated code should simply call a search function, which will
> obey case-fold-search. I think this will produce the most useful Lisp
> code, in terms of practical use.
If one toggles case-fold during isearch, I believe he does it for a reason
and we'd better record it. Currently the generated code looks like this:
(defun recorded-command ()
(interactive)
(let
((case-fold case-fold-search)) ; save case-fold
(setq case-fold-search t) ; set to recorded value
...
(search-forward "something")
(setq case-fold-search (not case-fold-search)) ; user toggles case-fold
(search-forward "SOMETHING") ; last isearch string
(setq case-fold-search (not case-fold-search)) ; toggle it back
...
(setq case-fold-search case-fold))) ; restore case-fold
It easy to do without the "case-fold" lines, though. Or another option can
be used to turn this on/off.
--
regards,
yzhh
next prev parent reply other threads:[~2007-11-04 8:51 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 [this message]
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
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='fgk17d$ha6$1@ger.gmane.org' \
--to=yezonghui@gmail.com \
--cc=emacs-devel@gnu.org \
/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.