From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 29c360e: Ensure redisplay after "C-x C-e" Date: Fri, 06 Nov 2015 17:47:49 +0200 Message-ID: <83oaf7qgd6.fsf@gnu.org> References: <20151106093011.17282.48378@vcs.savannah.gnu.org> <83vb9fqjvr.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1446824912 25107 80.91.229.3 (6 Nov 2015 15:48:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2015 15:48:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 06 16:48:20 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 1ZujFR-0004nZ-MJ for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 16:48:17 +0100 Original-Received: from localhost ([::1]:39563 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujFR-0001sA-6C for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 10:48:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujFO-0001s2-3R for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:48:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZujFI-0006Cf-U9 for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:48:13 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:51524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujFI-0006Bk-HA for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:48:08 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NXE00A00HB8CB00@mtaout26.012.net.il> for emacs-devel@gnu.org; Fri, 06 Nov 2015 17:51:20 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXE008R2HDKJS10@mtaout26.012.net.il>; Fri, 06 Nov 2015 17:51:20 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 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:193434 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 06 Nov 2015 10:30:51 -0500 > > >> That's always been the case for setting line-spacing. > > No, it worked correctly before Emacs 24.4, according to my testing. > > Yes, but that was an accident. I think what you did is add an arbitrary > hack to paper over this, and I think it'd be better to do it either of: > - live with the apparent regression, telling users that they should > simply be happy to have enjoyed this accident in the past. I don't like this alternative. Redisplay should be correct before it is fast. Users rightfully expect changes to such variables to have effect immediately, so not doing that looks like a bug. How do you explain that, after evaluating (setq line-spacing 1.0) nothing happens, but as soon as you type "M-x", the new setting takes effect? > - fix it "right". E.g. add ad-hoc code to redisplay_internal that tries > to detect changes to this variable, or add a "write barrier" on that > variable, or deprecated the `line-spacing' variable in favor of > a `set-line-spacing' function (thus providing the write-barrier), ... This is not the only such variable, there are others. Adding ad-hoc code for each one sounds _really_ hacky. I cannot take the other possibilities seriously, and I don't think you do, either. > If you fix this case in the way you did, then I see no reason not to > go further down that road and just always redisplay all mode-lines, on > the off-chance that the user set line-spacing, or toggled a minor mode > variable without calling something like force-mode-line-update, set > a variable `toto' which happens to be used by one of the (:eval...) > nodes of the mode-line-format of some of the displayed buffers, ... I see no reason to go down that road. I don't think there are any problems to fix there, and simply redisplaying all mode lines all the time will have no effect except slowing down Emacs. > > Why should we care about performance of "C-x C-e"? > > Why not? Because it's not performance-critical, and cannot be, ever. > I just think your addition of force-mode-line-update will be wasted > work in 99.9% of the cases, and it will only cover very few of the > cases where a force-mode-line-update is needed. Please show at least a couple of other cases. Then maybe I will change my mind. > PS: I even several times found that the "lucky accident" which causes > the mode-line to be recomputed after things like M-: is a mis-feature > because it doesn't let me know when a call to force-mode-line-update > is needed. I see no way around that, as long as going to minibuffer causes changes in display, like the menu bar, the tool bar, etc.