emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Speed of keyboard macro execution?


From: David Kastrup
Subject: Re: Speed of keyboard macro execution?
Date: Fri, 11 Dec 2015 07:27:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

John Wiegley <address@hidden> writes:

>>>>>> David Kastrup <address@hidden> writes:
>
>> My claim is not about "right" but "useful" behavior. We've had one other
>> person state that he switches off visual-line-mode always since keyboard
>> macros would otherwise be useless. Of course that's one possibility, but
>> visual-line-mode is actually useful for _visual_ navigation. Which is not
>> what happens during macro execution since the computer executes the recorded
>> keys without human intervention. Which makes sense in _similar_ but not
>> identical situations (for identical situations, one could just copy and
>> paste the result repeatedly). And non-identical situations will sometimes
>> have lines wrapped visually and sometimes not without that being related to
>> the structure of the modified text.
>
> I think we're presupposing what users want, and that is no reason to change a
> long-standing default.

I'm still waiting for a single example where the current behavior would
be actually useful for keyboard macro execution.

> You can always disable visual movement during recording and playback
> manually; I don't see why it needs to happen automatically now.

line-move-visual is not a minor mode.  Changing it requires setting of a
variable.  Setting a variable and resetting it afterwards every time one
wants to use keyboard macros requires a different level of expertise
than that required to use keyboard macros in the first place.  Apart
from being a nuisance.

> If you want a customization option to auto-disable visual movement
> during recording and playback, it should be easy to achieve with
> advice. Give it a try for a few months, and then tell me if you really
> find it to be a quality of life improvement. If so, I'd welcome the
> customization.

Can we get a single case where the current behavior would be useful?
Just one?  Or is this really just an academic exercise?

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]