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

[Richard Stallman <rms@gnu.org>]

    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.