Re: recording-elisp.el - try recording commands as elisp code

[yzhh <yezonghui@gmail.com>]

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