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: Sun, 01 Apr 2018 15:22:33 -0400	[thread overview]
Message-ID: <jwv1sfyhho4.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20180401142410.GA9027@ACM> (Alan Mackenzie's message of "Sun, 1 Apr 2018 14:24:10 +0000")

>> That's weird: shouldn't the inhibit-modification-hooks already play this role?
> I don't think so.  i-m-h is purely to do with whether the hooks should
> be run now.  That has nothing to do with how items should be added to
> the undo list.

Ah, I see what you mean.
[ tho I think in practice, there'll be no difference:
  the code which binds inhibit-modification-hooks in the context will
  already want to deal with the fact that the undo entries would normally
  not be run within such a inhibit-modification-hooks, so it'll usually
  bind buffer-undo-list to t or do something related.  ]

> I'm not sure.  I think it's in re-undoing.

Yes, that would be expected, indeed.

> As you've already guessed, I would be in favour of removing that code
> from `undo' that we don't see what it's for.

As I said, it's orthogonal to the current discussion (it affects many
more cases).  And I personally have no opinion on whether this behavior
should be considered as a bug or a feature.

> I think it's almost time to commit this to master.

Agreed.

> I propose that combine-change-calls{-1,} go into subr.el, beside
> combine-after-change-calls, and undo--wrap-and-run-primitive-undo go
> into simple.el, beside the rest of the undo stuff.

I don't have an opinion on which file it should go to, but
undo--wrap-and-run-primitive-undo belongs with the rest, so it'd make
a lot more sense to keep them all three together.

> I will introduce the variable comment-combine-change-calls in
> newcomment.el, and modify {,un}comment-region to test it, and if set, to
> use c-c-c.

I'm not sure we even need such a variable (tho I'd put the
combine-change-calls around comment-region-default, so it doesn't
affect other settings of comment-region-function).

> I will document c-c-c in the Elisp manual on page "Change Hooks".

Thanks.


        Stefan



  reply	other threads:[~2018-04-01 19:22 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
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 [this message]
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=jwv1sfyhho4.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).