dabbrev-expand should escape kbd macros, shouldn't it?

dabbrev-expand should escape kbd macros, shouldn't it?

[Daniel Colascione]

Right now, if you record a kbd macro and hit M-/, the act of hitting M-/
is recorded like any other command in the kbd macro. On replay, we'll run
dabbrev-expand. The problem is that dabbrev-expand produces radically
different results depending on buffer context, making macro replay
unpredictable. Should the *result* of dabbrev-expand just get put into the
kbd macro instead?

Re: dabbrev-expand should escape kbd macros, shouldn't it?

[Andreas Schwab]

On Jul 17 2019, "Daniel Colascione" <dancol@dancol.org> wrote:

> Right now, if you record a kbd macro and hit M-/, the act of hitting M-/
> is recorded like any other command in the kbd macro. On replay, we'll run
> dabbrev-expand. The problem is that dabbrev-expand produces radically
> different results depending on buffer context, making macro replay
> unpredictable. Should the *result* of dabbrev-expand just get put into the
> kbd macro instead?

How is that different from any other key that is part of the macro?  The
point of a kbd macro is to record keys, not their effect (or even their
binding).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

RE: dabbrev-expand should escape kbd macros, shouldn't it?

[Drew Adams]

> > Right now, if you record a kbd macro and hit M-/, the act of hitting M-/
> > is recorded like any other command in the kbd macro. On replay, we'll run
> > dabbrev-expand. The problem is that dabbrev-expand produces radically
> > different results depending on buffer context, making macro replay
> > unpredictable. Should the *result* of dabbrev-expand just get put into the
> > kbd macro instead?
> 
> How is that different from any other key that is part of the macro?
> The point of a kbd macro is to record keys, not their effect (or even their
> binding).

+1

A keyboard macro is essentially a command.

You generally want to be able to replay a keyboard macro
(keystrokes) in various contexts.  You generally do not
want to capture the original context as part of the macro.

Re: dabbrev-expand should escape kbd macros, shouldn't it?

[Daniel Colascione]

> On Jul 17 2019, "Daniel Colascione" <dancol@dancol.org> wrote:
>
>> Right now, if you record a kbd macro and hit M-/, the act of hitting M-/
>> is recorded like any other command in the kbd macro. On replay, we'll
>> run
>> dabbrev-expand. The problem is that dabbrev-expand produces radically
>> different results depending on buffer context, making macro replay
>> unpredictable. Should the *result* of dabbrev-expand just get put into
>> the
>> kbd macro instead?
>
> How is that different from any other key that is part of the macro?  The
> point of a kbd macro is to record keys, not their effect (or even their
> binding).

Sort of. We make keyboard macros in the first place so we can do a thing
over and over. It turns out that dumbly recording and replaying keystrokes
is a pretty good strategy for lightweight automation. But dumb key
recording doesn't work well in some cases, and dabbrev is one of those. I
use dabbrev because I want to insert a specific string, cycling through
alternatives until I find the one I want. That's going to produce
different results on different occasions. Most of the time, recorded
keystrokes in macros aren't that sensitive to _temporal_ and _interbuffer_
context, and dabbrev is, so I think we should make an exception for
dabbrev.

Re: dabbrev-expand should escape kbd macros, shouldn't it?

[Andreas Schwab]

You can edit the kbd macro if you want to do something different from
what you typed.  But the macro recorder doesn't even *know* what is
being executed.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: dabbrev-expand should escape kbd macros, shouldn't it?

[Juri Linkov]

> Most of the time, recorded keystrokes in macros aren't that sensitive
> to _temporal_ and _interbuffer_ context, and dabbrev is, so I think we
> should make an exception for dabbrev.

Recently I had the same thoughts when a kbd macro recorded the paste
keystroke and not the text it pasted (as a sequence of self-inserting
keys).  I know that it records just plain keystrokes, but in that context
the result was unexpected.  However, I don't think that pasting should be
an exception.  Maybe keyboard macros should provide a special macro-escape
feature (like there is a macro-query feature available via ‘C-x q’) to ask
whether to record the keystroke literally or to record the effect of
the command.

This ambiguity demonstrates why it's impossible to implement a package
that would convert keyboard macros to programs - because there are too
many logical levels of how the result of every keystroke can be interpreted
depending on expectancy even of the same user in different contexts.