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: Sat, 07 Nov 2015 11:07:41 +0200 Message-ID: <83ziyqp482.fsf@gnu.org> References: <20151106093011.17282.48378@vcs.savannah.gnu.org> <83vb9fqjvr.fsf@gnu.org> <83oaf7qgd6.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1446887295 17167 80.91.229.3 (7 Nov 2015 09:08:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Nov 2015 09:08:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 07 10:08:02 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 1ZuzTd-0001sc-Dj for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 10:08:01 +0100 Original-Received: from localhost ([::1]:42860 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuzTc-0007ry-M7 for ged-emacs-devel@m.gmane.org; Sat, 07 Nov 2015 04:08:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuzTY-0007rr-MM for emacs-devel@gnu.org; Sat, 07 Nov 2015 04:07:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuzTV-0000Cr-Ai for emacs-devel@gnu.org; Sat, 07 Nov 2015 04:07:56 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:43102) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuzTU-0000Cm-UK for emacs-devel@gnu.org; Sat, 07 Nov 2015 04:07:53 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NXF00J00T460G00@mtaout28.012.net.il> for emacs-devel@gnu.org; Sat, 07 Nov 2015 11:06:45 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXF00FA5TB7FW30@mtaout28.012.net.il>; Sat, 07 Nov 2015 11:06:45 +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.184 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:193505 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 06 Nov 2015 16:47:58 -0500 > > >> - 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. > > We agree in general, of course. But it's always been the case that some > changes require a call to force-mode-line-update. Notice that > > > 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? > > I explain it saying that this variable value is only taken into account > if something is redisplayed. And the user moves on very happy. Not this user. And so I don't want to explain this away like that. > E.g. note how in bug#21835, the lack of redisplay is not a cause for > reporting a bug. It's just a minor surprise worthy of a "Note" in > passing to the actual problem of how the cursor is displayed. True for the person who reported that bug. Not true for me. Any change in display when you press M-x is a subtle redisplay bug that needs to be fixed. It means some redisplay optimization was used when it shouldn't have been. > If you don't like this answer, how 'bout I return the question: > > How do you explain to the user that when he used C-x C-e the display > was immediately updated, but when I put that same code into his > hand-made interactive function, it stopped working and started to > only take effect after something like M-x? Well, I was bothered by that as well, so the follow-up commit fixed that, I hope. Do you like it better? > I really can't see why we should hide this weakness of our > redisplay system in the case of C-x C-e. Either this weakness exists > and the Elisp coder will have to know about it sooner or later, or we > fix it for real. I hope I've now fixed it for real. > > This is not the only such variable, there are others. Adding ad-hoc > > code for each one sounds _really_ hacky. > > Agreed. The changes I made in 19e09cf are hopefully less hacky. > > I cannot take the other possibilities seriously, and I don't think you > > do, either. > > A `set-line-spacing' function, no, but a write-barrier, yes. > We've already had discussions on emacs-devel to add such a generic > feature cheaply, even with patches submitted. Please point to those patches, I don't think I have a clear idea what you allude to here. > >> > Why should we care about performance of "C-x C-e"? > >> Why not? > > Because it's not performance-critical, and cannot be, ever. > > Of course it can be performance critical in keyboard-macros. Redisplay happens only once after the macro finishes, no? Or did you have some very specific macro in mind? > >> 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. > > "grep force-mode-line-update" shows it's still needed at tons of > other places. Adding it in C-x C-e won't help them. It wasn't supposed to help them. Or maybe I completely misunderstand what you wanted to say here.