unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Per Starbäck" <per@starback.se>
To: David Kastrup <dak@gnu.org>
Cc: Eli Zaretskii <eliz@gnu.org>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>,
	"Perry E. Metzger" <perry@piermont.com>
Subject: Re: Speed of keyboard macro execution?
Date: Sun, 13 Dec 2015 00:20:24 +0100	[thread overview]
Message-ID: <CADkQgvssNMiKQybn6gEWdbZiv3KcwvE9rrhDd8Qx_0Ki=_S85Q@mail.gmail.com> (raw)
In-Reply-To: <878u51swr0.fsf@fencepost.gnu.org>

> Repeating a keyboard macro without intervening other actions means that
> the macro, after achieving its changes, has to progress to the next
> position where executing it makes sense as its last part.  This progress
> will often involve moving to the next line.  The next _visual_ line is
> meaningless for that purpose in almost all situations.  Under manual
> control, you'll just move across some continuation line.  But a repeated
> keyboard macro is not under manual control.
>
> 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 am surprised that I should be the only user of keyboard macros having
> noticed that.

Of course you are not! Your proposed change would make it a easier to
write macros. Now I often resort to work-arounds like C-e C-f and then
more navigation to get to the right place in the new line to be sure
to actually get to the next line in the typical case where you run a
macro on one line at a time.

Since I teach a course for GNU beginners with some Emacs in it, I see
what kind of mistakes beginners make when using macros. There is no
surprise there, I think. They navigate with visual feedback in a way
that works fine for the line they are in, but that doesn't do the
"same" thing on (some) other lines.

First it can be totally obvious like just typing <right> <right>
<right> ... <right> to get to the end of line. Later perhaps using
word navigation in a CSV file where most fields are one word, but
where there are some fields with several words where their macros
won't work.

line-move-visual invites this sort of using visual feedback that only
works for a particular line and can lead to the same kind of
surprises. It has been written here that not changing any settings
when defining macros leads to less surprises. Yes, less surprises
*while defining*, but more surprises when using those macros. And then
it's certainly possible that you don't notice it, because you just ran
your macro on all lines in a buffer without checking every one.

I think one reason not many have written in support for your position
is that some experienced Emacs users turn off visual-line-mode and
think that it's mostly there for less experienced users, so they don't
have any problems. And the less experienced users don't use macros
that much (except when forced to in my course :-) .



  parent reply	other threads:[~2015-12-12 23:20 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
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 [this message]
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='CADkQgvssNMiKQybn6gEWdbZiv3KcwvE9rrhDd8Qx_0Ki=_S85Q@mail.gmail.com' \
    --to=per@starback.se \
    --cc=dak@gnu.org \
    --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).