From: Stefan Monnier <monnier@iro.umontreal.ca>
To: wsnyder@wsnyder.org (Wilson Snyder)
Cc: emacs-devel@gnu.org
Subject: Re: Get rid of verilog-no-change-functions
Date: Sat, 12 Sep 2015 16:21:23 -0400 [thread overview]
Message-ID: <jwvbnd7h03m.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <7q8u8bj2ib.fsf@emma.svaha.wsnyder.org> (Wilson Snyder's message of "Sat, 12 Sep 2015 07:33:32 -0400")
> 3. This code was originally developed on Emacs 21 so it's
> odd that inhibit-modification-hooks wasn't sufficient.
inhibit-modification-hooks was new in Emacs-21 and not widely known, so
I'm really not surprised. Even nowadays it's still common to see people
let-binding after-change-functions instead of inhibit-modification-hooks.
> But the the verilog-mode.el code also works on ancient XEmacs.
> This is annoying for our code, but we still get bug reports
> occasionally so are reluctant to abandon it. At a minimum
> inhibit-modification-hooks needs to be defined to prevent XEmacs
> compile warnings.
AFAIK my patch should work just as well at least for the
verilog-save-buffer-state part since XEmacs doesn't run
after-change-functions for text-property modifications.
For verilog-save-no-change-functions, I don't understand what is the
intention behind preventing after-change-functions (it intuitively seems
wrong, so I'm obviously missing something).
> + (unless (boundp 'inhibit-modification-hooks)
> + (defvar inhibit-modification-hooks nil))
No, no, no, no!
Just use
(defvar inhibit-modification-hooks)
if you want to silence the byte-compiler.
But AFAIK as long you don't switch to "lexical-binding:t", no
byte-compiler will complain if you let-bind an unknown variable without
using it, so even that (defvar inhibit-modification-hooks) is
not indispensable.
> @@ -3231,6 +3233,7 @@ user-visible changes to the buffer must not be within a
> (inhibit-read-only t)
> (inhibit-point-motion-hooks t)
> + (inhibit-modification-hooks t) ; Emacs 21+
> (verilog-no-change-functions t)
> before-change-functions
> after-change-functions
> deactivate-mark
Here it's important to remove before-change-functions and
after-change-functions.
> @@ -3247,6 +3250,7 @@ user-visible changes to the buffer must not be within a
> For insignificant changes, see instead `verilog-save-buffer-state'."
> `(let* ((inhibit-point-motion-hooks t)
> + (inhibit-modification-hooks t)
> (verilog-no-change-functions t)
> before-change-functions
> after-change-functions)
> (progn ,@body)))
As mentioned, here I'd have to understand why we need to prevent
*-change-functions from running. After all, this is used in places
where we make very significant changes to the buffer and where font-lock
(for instance) would want to know about it.
Stefan
next prev parent reply other threads:[~2015-09-12 20:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-12 11:33 Get rid of verilog-no-change-functions Wilson Snyder
2015-09-12 20:21 ` Stefan Monnier [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-10-29 13:48 Wilson Snyder
2015-10-29 15:31 ` Stefan Monnier
2015-09-15 23:51 Wilson Snyder
2015-09-16 1:05 ` Stefan Monnier
2015-09-16 7:40 ` Andreas Schwab
2015-09-16 13:12 ` Stefan Monnier
2015-10-29 13:22 ` Stefan Monnier
2015-09-14 21:09 Wilson Snyder
2015-09-15 13:45 ` Stefan Monnier
2015-09-12 4:22 Stefan Monnier
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=jwvbnd7h03m.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=wsnyder@wsnyder.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).