From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Get rid of verilog-no-change-functions Date: Thu, 29 Oct 2015 09:22:07 -0400 Message-ID: References: <7qa8snz1g8.fsf@emma.svaha.wsnyder.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446124961 16827 80.91.229.3 (29 Oct 2015 13:22:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Oct 2015 13:22:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: wsnyder@wsnyder.org (Wilson Snyder) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 29 14:22:35 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 1ZrnA0-0002Qs-SA for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 14:22:33 +0100 Original-Received: from localhost ([::1]:44079 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrn9z-0003m5-Pz for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 09:22:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrn9h-0003gx-La for emacs-devel@gnu.org; Thu, 29 Oct 2015 09:22:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zrn9d-0007w6-PJ for emacs-devel@gnu.org; Thu, 29 Oct 2015 09:22:13 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:53783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrn9d-0007vd-Iv for emacs-devel@gnu.org; Thu, 29 Oct 2015 09:22:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2FgA731xV/+Z93mhcgxCBMoJQhVW7QIdLBAICgTw6EwEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDTeIJAjPIwEBAQcCAR+LOoQ+RweELQWZbZsXI4FmJByBbiIxgkcBAQE X-IPAS-Result: A0A2FgA731xV/+Z93mhcgxCBMoJQhVW7QIdLBAICgTw6EwEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDTeIJAjPIwEBAQcCAR+LOoQ+RweELQWZbZsXI4FmJByBbiIxgkcBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="171946760" Original-Received: from 104-222-125-230.cpe.teksavvy.com (HELO fmsmemgm.homelinux.net) ([104.222.125.230]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2015 09:22:08 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id DD76AAE25E; Thu, 29 Oct 2015 09:22:07 -0400 (EDT) In-Reply-To: (Stefan Monnier's message of "Tue, 15 Sep 2015 21:05:16 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:192893 Archived-At: 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