unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: perry@piermont.com, deng@randomsample.de, emacs-devel@gnu.org
Subject: Re: Speed of keyboard macro execution?
Date: Thu, 10 Dec 2015 20:38:58 +0100	[thread overview]
Message-ID: <87fuzat7ot.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <83d1ue9lns.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Dec 2015 20:57:27 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: "Perry E. Metzger" <perry@piermont.com>, deng@randomsample.de,
>> emacs-devel@gnu.org
>> 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	other threads:[~2015-12-10 19:38 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09 21:39 Speed of keyboard macro execution? Perry E. Metzger
2015-12-09 22:13 ` David Engster
2015-12-09 23:03   ` Perry E. Metzger
2015-12-10 16:43     ` Eli Zaretskii
2015-12-10 17:00       ` Perry E. Metzger
2015-12-10 17:14         ` John Wiegley
2015-12-10 17:27         ` David Engster
2015-12-10 17:33           ` Perry E. Metzger
2015-12-10 17:39             ` David Engster
2015-12-10 17:53             ` Eli Zaretskii
2015-12-10 18:10               ` Perry E. Metzger
2015-12-10 18:41                 ` Eli Zaretskii
2015-12-10 18:44               ` David Kastrup
2015-12-10 18:57                 ` Eli Zaretskii
2015-12-10 19:38                   ` David Kastrup [this message]
2015-12-10 20:00                     ` Eli Zaretskii
2015-12-10 20:09                       ` David Kastrup
2015-12-10 20:43                         ` Eli Zaretskii
2015-12-10 20:55                           ` David Kastrup
2015-12-10 20:16                       ` Perry E. Metzger
2015-12-10 20:18                         ` John Wiegley
2015-12-10 20:36                           ` David Kastrup
2015-12-10 20:43                             ` John Wiegley
2015-12-10 21:01                               ` David Kastrup
2015-12-10 21:26                                 ` John Wiegley
2015-12-10 23:35                                   ` David Kastrup
2015-12-11  1:14                                     ` John Wiegley
2015-12-11  6:27                                       ` David Kastrup
2015-12-12 22:56                                         ` John Wiegley
2015-12-12 23:46                                           ` David Kastrup
2015-12-13  0:16                                             ` John Wiegley
2015-12-13  0:32                                               ` David Kastrup
2015-12-12 23:20                                     ` Per Starbäck
2015-12-12 16:51                                   ` Perry E. Metzger
2015-12-12 17:42                                     ` David Kastrup
2015-12-12 23:01                                     ` Disabling visual lines for macros (was: Speed of keyboard macro execution?) John Wiegley
2015-12-12 23:33                                       ` Disabling visual lines for macros David Kastrup
2015-12-10 20:45                             ` Speed of keyboard macro execution? Perry E. Metzger
2015-12-10 20:50                               ` John Wiegley
2015-12-10 20:48                             ` Eli Zaretskii
2015-12-10 20:50                               ` John Wiegley
2015-12-10 21:13                               ` David Kastrup
2015-12-10 17:37         ` Eli Zaretskii
2015-12-10 17:43           ` John Wiegley
2015-12-10 17:54             ` Eli Zaretskii
2015-12-10 18:15       ` Achim Gratz
2015-12-10 18:47         ` Eli Zaretskii
2015-12-12  2:14       ` Joseph Mingrone
2015-12-12  7:39         ` Eli Zaretskii
2015-12-12 17:28           ` Joseph Mingrone
2015-12-12 17:57             ` Eli Zaretskii
2015-12-12 18:12               ` Joseph Mingrone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fuzat7ot.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=deng@randomsample.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=perry@piermont.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).