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: Thu, 29 Oct 2015 09:48:05 -0400 Message-ID: <7qvb9pdbvu.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 1446126517 10753 80.91.229.3 (29 Oct 2015 13:48:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Oct 2015 13:48:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 29 14:48:32 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 1ZrnZ8-0005sy-P9 for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 14:48:30 +0100 Original-Received: from localhost ([::1]:44195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrnZ7-0002ZE-Vn for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 09:48:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrnYq-0002TT-Uf for emacs-devel@gnu.org; Thu, 29 Oct 2015 09:48:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrnYm-0006nz-39 for emacs-devel@gnu.org; Thu, 29 Oct 2015 09:48:12 -0400 Original-Received: from vpo3.wsnyder.org ([173.230.154.183]:59242 helo=wsnyder.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrnYl-0006nR-Ug for emacs-devel@gnu.org; Thu, 29 Oct 2015 09:48:08 -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:192898 Archived-At: I have this on a branch awaiting testing on older Emacsen (21 etc). I'll get that done and applied into Emacs trunk. -Wilson Stefan Monnier writes: >Hi Wilson, > >Did (or will) you install a patch along the lines fleshed out in >this thread? >If you prefer I can do it on the Emacs side instead, but I'd rather you >do it, since you're in a better position to make sure it actually works. > > > Stefan > > >>>>>> "Stefan" == Stefan Monnier writes: > >>>> 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. > >> `verilog-delete-auto' is an interactive function, so we do want to >> handle that case as well. > >>> 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. > >> Indeed, that would be to right thing to do, I think. > >>> 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. > >> You mean we could remove verilog-save-no-change-functions from it? >> If you say so, that's fine by me. > >>> Also why do you suggest a defvar working would be an "accident"? >>> These defvars only needs to exist when compiling. > >> *eval*uating (defvar foo) has no effect, other than to declare that var >> to be dynamically scoped *in that scope*. E.g. > >> (defun bar () >> (defvar foo) >> ...) > >> make `foo' be dynamically scoped in that scope. So > >> (eval-when-compile >> (defvar foo) >> ...) > >> Would most logically make `foo' be dynamically scoped within the >> eval-when-compile but not outside of it. > >> The only reason why it works is an implementation accident: >> eval-when-compile (when run from the byte-compiler) first compiles its >> body, and that has the side-effect that it ends up declaring `foo' also >> outside of the eval-when-compile. It also has a few other side-effect, >> and like this one, some of them are halfway between bugs and features. > >>>> (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? > >> Because it avoids forcing a recomputation of the mode-line. > >>> The documentation suggests this may be suspicious. > >> But in the present case, restore-buffer-modified-p would indeed >> restore the buffer-modified-p state, thus there's no need to recompute >> the mode-line. > >> This was introduced specifically for this kind of use. See for example >> the definition of with-silent-modifications. > > >> Stefan