unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: An idea: combine-change-calls
Date: Thu, 29 Mar 2018 15:10:33 +0000	[thread overview]
Message-ID: <20180329151033.GA5213@ACM> (raw)
In-Reply-To: <jwv605fc3go.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Wed, Mar 28, 2018 at 17:26:30 -0400, Stefan Monnier wrote:
> > 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,
> ....

I don't think "consider" is the right word here.  I don't think it will
work at all.  In primitive-undo, some undo list is an argument, and it
has elements removed from it and it is then the return value.  If we try
to call primitive-undo recursively through an (apply ...) form, there is
no interface to return the depleted list to the calling p-u.  We could,
of course, use some global variables instead of arguments, but this
would involve changes just as incompatible as making additions to the
undo list elements.

> ... than I'd want this new extension to be generic rather than
> specific for this particular use-case.

It is generic, in the sense it handles any case where
before/after-change-functions are to be condensed into one call of each.

What do you mean by generic, here?

[ .... ]

> > 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.

It does a good deal more than "optimizing the representation" - it makes
an irreversible change which loses information.  Somebody, sometime, is
going to need that info.

> 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).

In my current code, the only undo-boundary pushed (in the handling of
combine-change-begin) is immediately acted upon to terminate the
recursive invocation of primitive-undo.  This is pushed onto the LIST
variable in the nested p-u, and doesn't affect buffer-undo-list or
pending-undo-list.

> > 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".

Ah, is that it?  I had some difficulty understanding it properly.

> > 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.

Yes.

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

Thinking about it, that comment above ("Don't specify a position ....")
reads as if it was originally in place on some code which added elements
to buffer-undo-list, and then got hurredly moved to `undo' when the
strategy was changed to delete such elements.  Again, it isn't clear why
position elements get deleted.  Any code which adds them (such as my new
code) will have a reason for doing so.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2018-03-29 15:10 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
2018-03-29 15:10                       ` Alan Mackenzie [this message]
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=20180329151033.GA5213@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /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).