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: Thu, 10 Dec 2015 20:38:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Cc: "Perry E. Metzger" <address@hidden>, address@hidden,
>> address@hidden
>> Date: Thu, 10 Dec 2015 19:44:54 +0100
>> 
>> I don't think there is much sense in having line-move-visual mode active
>> when recording/replaying keyboard macros.
>> 
>> Tying the operation of keyboard macros to the current display/font
>> selection is just meaningless.  Its purpose is for _aiming_ positioning
>> by keyboard, and that's just not useful at keyboard replay.
>
> I think it depends on the keyboard macro.  The ones I saw in that demo
> did move point, moreover they moved it to the end of a very long line,
> so both the actual redisplay and its simulation were at work,
> including auto-hscroll.

So how did line-move-visual accomplish anything useful here?  It is not
the question whether line-move-visual was involved here or not:
obviously it was or it could hardly have affected the benchmark.

> I don't see how you can prevent that: macros are just a mechanical way
> of recording and replaying commands, and commands sure do need to run
> this code.
>
> In any case, keyboard macros are not relevant to the discussion
> (contrary to the subject line).  The issue is slow redisplay with long
> lines.

Which occured during keyboard macro execution due to line-move-visual
being active.  Yes, improving the display engine speed would have sped
up this benchmark.  But if the benchmark did not actually accomplish
anything that would be useful in the course of editing, speeding the
display engine up will not lead to a corresponding speedup to anything
that would be useful in the course of editing.

So I think it would make excellent sense to disable visual positioning
modes while recording and replaying keyboard macros.  Not in order to
cheat at benchmarks, but to have actually useful behavior for a keyboard
macro that is intended to run without human intervention afterwards and
produce meaningful results.

I'll grant that paragraph adjustment according to visual width might
make sense in a keyboard macro and that _would_ exercise the display
engine by necessity.  But visual movement?  In a keyboard macro?  Not
really.

-- 
David Kastrup



reply via email to

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