unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: An idea: combine-change-calls
Date: Wed, 28 Mar 2018 17:26:30 -0400	[thread overview]
Message-ID: <jwv605fc3go.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20180328204254.GC6592@ACM> (Alan Mackenzie's message of "Wed, 28 Mar 2018 20:42:54 +0000")

> It would need amendment, of course, but that wouldn't be difficult.

I'd rather try and avoid that.  And if we really do want to extent the
format because we consider that (apply ...) is not good enough here,
than I'd want this new extension to be generic rather than specific for
this particular use-case.

> But I suspect that the mechanism you suggested (an `apply' format
> element recursively calling primitive-undo), will break other packages
> too, even if the format of undo lists isn't changed.

Could be, indeed.

> What we've been discussing goes beyond hiding information, it is the
> destruction of information.  Users, maybe just a few, won't like that at
> all.

Not at all.  It's just optimizing the representation of the undo-log.
If there's an undo-boundary in there, then indeed, we'd be throwing away
a bit of information, but I assumed we wouldn't care about that case.

Whatever you decide to do with the undo-log, handling undo-boundary
pushed during the execution of `body` will be tricky I suspect (except
if we just don't touch the undo-list, of course).

> Incidentally, position elements in the undo list don't work: `undo'
> removes them from buffer-undo-list.

Are you sure they "don't work" (they seemed to work in my test)?

IIUC The code you cite only strips them from the undo elements added
while performing an undo (i.e. from "redo" elements), so they should
still work for a plain "edit .... undo".

> I think you amended that bit of code some years ago.  Can you say why
> this is done?  The comment in the code:
>
>     ;; Don't specify a position in the undo record for the undo command.
>     ;; Instead, undoing this should move point to where the change is.
>
> doesn't give any reason, and the various pertinent commit messages
> aren't any help either.

Hmm... good question.  I see this code basically dates back to

  commit 2512c9f0f0e6cc71c601ffdb0690b9cf5642734b
  Author: Richard M. Stallman <rms@gnu.org>
  Date:   Wed Mar 16 23:41:32 1994 +0000

    (undo): Don't let the undo entries for the undo
    contain a specific buffer position.  Delete it if there is one.

and no, I don't know why we do this.


        Stefan



  reply	other threads:[~2018-03-28 21:26 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-24 13:50 An idea: combine-change-calls Alan Mackenzie
2018-03-24 22:18 ` Stefan Monnier
2018-03-25 19:14   ` Alan Mackenzie
2018-03-25 20:05     ` Stefan Monnier
2018-03-26 20:17       ` Alan Mackenzie
2018-03-26 21:07         ` Stefan Monnier
2018-03-27 16:58           ` Alan Mackenzie
2018-03-27 18:30             ` Stefan Monnier
2018-03-27 19:45               ` Alan Mackenzie
2018-03-27 20:24                 ` Stefan Monnier
2018-03-28 20:42                   ` Alan Mackenzie
2018-03-28 21:26                     ` Stefan Monnier [this message]
2018-03-29 15:10                       ` Alan Mackenzie
2018-03-29 15:40                         ` Stefan Monnier
2018-03-29 17:11                           ` Alan Mackenzie
2018-03-29 19:10                             ` Stefan Monnier
2018-03-30 11:46                               ` Alan Mackenzie
2018-03-30 15:05                                 ` Stefan Monnier
2018-03-31 21:00                                   ` Alan Mackenzie
2018-03-31 23:38                                     ` Stefan Monnier
2018-04-01 14:24                                       ` Alan Mackenzie
2018-04-01 19:22                                         ` Stefan Monnier
2018-03-30  9:12           ` Johan Bockgård
2018-03-30 13:04             ` Stefan Monnier
2018-04-02 16:25               ` Alan Mackenzie
2018-04-02 17:52                 ` Johan Bockgård
2018-04-03  0:41                 ` Stefan Monnier
2018-04-03  1:43                 ` Clément Pit-Claudel
2018-04-03  3:15                 ` Richard Stallman
2018-03-26 21:09         ` Stefan Monnier
2018-03-27  0:36         ` Stefan Monnier
2018-03-27 17:00           ` Alan Mackenzie

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=jwv605fc3go.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    /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).