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: [Emacs-diffs] master 29c360e: Ensure redisplay after "C-x C-e" Date: Fri, 06 Nov 2015 10:30:51 -0500 Message-ID: References: <20151106093011.17282.48378@vcs.savannah.gnu.org> <83vb9fqjvr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1446823896 7858 80.91.229.3 (6 Nov 2015 15:31:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Nov 2015 15:31:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 06 16:31:28 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 1Zuiz5-0006XA-QA for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 16:31:23 +0100 Original-Received: from localhost ([::1]:39423 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zuiz5-0008P5-1h for ged-emacs-devel@m.gmane.org; Fri, 06 Nov 2015 10:31:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zuiyf-0008LD-Rw for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:30:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zuiye-0000Ou-Jn for emacs-devel@gnu.org; Fri, 06 Nov 2015 10:30:57 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:1298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zuiya-0000MR-Aj; Fri, 06 Nov 2015 10:30:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CpHQA731xV/+Z93mhcghl3hAKFVbs3CYQOgz0EAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0FjDCSZ44Wg36DWSOBZiQcgXAggngBAQE X-IPAS-Result: A0CpHQA731xV/+Z93mhcghl3hAKFVbs3CYQOgz0EAgKBPDkUAQEBAQEBAYEKQQWDXQEBAwFWIwULCzQSFBgNJIg3CM8jAQEBAQYBAQEBHos6hQUHhC0FjDCSZ44Wg36DWSOBZiQcgXAggngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="176482275" Original-Received: from 104-222-125-230.cpe.teksavvy.com (HELO pastel.home) ([104.222.125.230]) by ironport2-out.teksavvy.com with ESMTP; 06 Nov 2015 10:30:51 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 568C95F97B; Fri, 6 Nov 2015 10:30:51 -0500 (EST) In-Reply-To: <83vb9fqjvr.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 06 Nov 2015 16:31:52 +0200") 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:193427 Archived-At: >> 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. - 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), ... > Probably because we used to trigger thorough redisplay "for other > reasons". Exactly. People you did this and got the redisplay properly refreshed were just lucky. 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, ... > Why should we care about performance of "C-x C-e"? Why not? 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. Stefan 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.