From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: wsnyder@wsnyder.org (Wilson Snyder) Newsgroups: gmane.emacs.devel Subject: Re: Get rid of verilog-no-change-functions Date: Tue, 15 Sep 2015 19:51:03 -0400 Message-ID: <7qa8snz1g8.fsf@emma.svaha.wsnyder.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1442361083 21164 80.91.229.3 (15 Sep 2015 23:51:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 23:51:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 16 01:51:23 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zc00P-0002I8-S4 for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 01:51:21 +0200 Original-Received: from localhost ([::1]:46447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zc00P-0004VT-9b for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 19:51:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zc00C-0004VK-UB for emacs-devel@gnu.org; Tue, 15 Sep 2015 19:51:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zc009-0001eO-O4 for emacs-devel@gnu.org; Tue, 15 Sep 2015 19:51:08 -0400 Original-Received: from vpo3.wsnyder.org ([173.230.154.183]:56206 helo=wsnyder.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zc009-0001db-Io for emacs-devel@gnu.org; Tue, 15 Sep 2015 19:51:05 -0400 X-ssh-sendmail: true User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 173.230.154.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189991 Archived-At: >>> 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. > >> The child functions perform hundreds of thousands of minor >> changes, then call the hooks on everything. Doing it this >> way makes an update maybe 10 seconds versus (as it once did) >> many minutes - which was almost unusable. At the end of >> everything fontification is correct. > >Combining all the *-change-functions calls makes a lot of sense (that's >why we have combine-after-change-calls, for example). But I don't see >where you "then call the hooks on everything". > >I see the verilog-save-font-mods which re-font-locks the buffer >afterwards, but since it disables font-lock at the beginning it means >that verilog-save-no-change-functions is not needed to prevent >font-lock hooks. > >And of course, disabling/enabling font-lock-mode doesn't take care of >other users of *-change-functions. Your patches make sense, and there's no appreciable performance loss. >Also, I see that verilog-save-no-change-functions is wrapped inside >verilog-save-font-mods in verilog-auto, but not in verilog-delete-auto. The common use of delete-auto is under verilog-auto itself, so if we added it to delete-auto we'd be calling the hooks at both auto's exiting of verilog-delete-auto and at the exit of verilog-auto itself. We'd then be better off pulling the guts out of verilog-delete-auto (without verilog-save-no-change-functions) and call those guts from verilog-auto and verilog-delete-auto. But anyhow I've never heard complaints of verilog-delete-auto being slow as it makes an order-of-magnitude fewer changes, so doesn't seem worth the work. >> - (unless (boundp 'inhibit-point-motion-hooks) >> - (defvar inhibit-point-motion-hooks nil)) >> - (unless (boundp 'deactivate-mark) >> - (defvar deactivate-mark nil)) >> + (defvar inhibit-modification-hooks) >> + (defvar inhibit-point-motion-hooks) >> + (defvar deactivate-mark) > >Those defvars should not be with an eval-when-compile (they happen to >also work if they are, currently, but that's a mere accident). These defvars only apply to XEmacs. I considered doing it this way a feature, as if e.g. GNU removed one of those variables in the future the warnings would return. Likewise if someone sends me a bug report showing the warnings on GNU I want to know that those variables aren't in their version. Also why do you suggest a defvar working would be an "accident"? These defvars only needs to exist when compiling. > (progn ,@body) > (and (not modified) > (buffer-modified-p) >- (set-buffer-modified-p nil))))) >+ (if (fboundp 'restore-buffer-modified-p) >+ (restore-buffer-modified-p nil) >+ (set-buffer-modified-p nil)))))) Can you explain why restore-buffer-modified-p is preferred? The documentation suggests this may be suspicious. Like `set-buffer-modified-p', with a difference concerning redisplay. It is not ensured that mode lines will be updated to show the modified state of the current buffer. Use with care.