From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#69511: Restore any state after revert-buffer Date: Sun, 03 Mar 2024 11:04:28 +0200 Message-ID: <86jzmjofdv.fsf@gnu.org> References: <86y1b0r00p.fsf@mail.linkov.net> <867cikpkpm.fsf@gnu.org> <864jdnpw83.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38104"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69511@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 03 10:05:44 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rghmw-0009ZT-Bd for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Mar 2024 10:05:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rghmp-0003XR-IQ; Sun, 03 Mar 2024 04:05:35 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rghmo-0003X8-NU for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2024 04:05:34 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rghmn-0007tc-Gu for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2024 04:05:34 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rghnG-0001oW-4x for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2024 04:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Mar 2024 09:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69511 X-GNU-PR-Package: emacs Original-Received: via spool by 69511-submit@debbugs.gnu.org id=B69511.17094567126895 (code B ref 69511); Sun, 03 Mar 2024 09:06:02 +0000 Original-Received: (at 69511) by debbugs.gnu.org; 3 Mar 2024 09:05:12 +0000 Original-Received: from localhost ([127.0.0.1]:39762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rghmR-0001n8-HY for submit@debbugs.gnu.org; Sun, 03 Mar 2024 04:05:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rghmM-0001mZ-Ex for 69511@debbugs.gnu.org; Sun, 03 Mar 2024 04:05:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rghln-0007aV-IV; Sun, 03 Mar 2024 04:04:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=x3AAm1xlRJ5pXaEcBd1MAP2wxymJJ4zmzNKBRDvIDjY=; b=QGyHLs22JEcP Qn1HbRYO+Zgyxv9bpVxRVy2iL6iZnJC6hLq1jDvh6esVtAdSx8uskceQFryOaVSY7LtifJD+HMoWA kRCDUUT5NZwJD+BOd+Owg1bAXbr+wEdFZ6iag16qPFR1R3nBUtnberGMSzTkE6qF21x8RMYOS3mPi zcSNnxtmMoU15wieRmFRHuNhu7vTeE2hkNSrgE76ANDpXF4Asn+u7rBwxPy9dXCd2JJkfCGFbRrEL o6UFsjPL6qKgvbmQXwkDbCLsLdnoSTbLMYnHfEHWmW1esCrY/e8vfNcq8lxsUpkPYlt/DX411iKp8 dCuLvxSbEWRhPHkZbOQ9KQ==; In-Reply-To: <864jdnpw83.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 03 Mar 2024 09:59:24 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280929 Archived-At: > From: Juri Linkov > Cc: 69511@debbugs.gnu.org > Date: Sun, 03 Mar 2024 09:59:24 +0200 > > >> This patch adds a new variable 'revert-buffer-state-functions' > >> that will allow any state to be saved and restored, > >> not only the currently hard-coded 'read-only' state: > > > > It isn't clear what you mean by "state" here. It seems like you are > > talking about functions to be called after reverting a buffer in order > > to do whatever is appropriate after reverting. And if so, why > > "state"? For example, one of your examples, with > > outline-minor-mode-highlight-buffer, is not about "state", but about > > re-highlighting the buffer after reverting it. > > "state" here is in the same sense as is already used in 'revert-buffer': "Two wrongs don't make a right", as the saying goes. And the name of a local variable is much less significant than the name of a public variable. > > So I would suggest calling this "revert-buffer-post-revert-functions", > > and updating the doc string to make it clear that the purpose is more > > general. > > "post" can't be used because these functions are called > before 'revert-buffer-function'. According to your doc string, the lambdas these functions produce are called _after_ reverting the buffer. So I see no reason not to use "post" here. > "pre" would be better but still has no hint that the returned lambdas > will be called after 'revert-buffer-function' to restore a state. The doc string can make that evident, so that's not a problem IMO. And again, "restore a state" doesn't describe what, for example, outline-minor-mode-highlight-buffer does. So this is not a good source for a descriptive name of the variable. > >> +(defvar-local revert-buffer-state-functions nil > >> + "Functions to save and restore any state during `revert-buffer'. > >> +This variable is a list of functions that are called before > >> +reverting the buffer. These functions should return a lambda > >> +that will be called after reverting the buffer > >> +to restore a previous state saved in that lambda.") > > > > The last sentence needs to be reworded, because it is not clear how > > functions (in plural) can return a lambda (in singular). Also, the > > doc string should describe how the function is called (with no > > arguments, I guess?), and that all those functions will be called one > > by one in the order of the list. > > Here is an improved docstring: > > (defvar-local revert-buffer-state-functions nil > "Functions to save and restore any state during `revert-buffer'. > This variable is a list of functions that are called before reverting ^^^^^^^^^^^^^ "The value of this variable..." > the buffer. Each of these functions are called without arguments and > should return a lambda that can restore a previous state of the buffer. > Then after reverting the buffer each of these lambdas will be called > one by one in the order of the list to restore previous states of the > buffer. An example of the buffer state is keeping the buffer read-only, > or keeping minor modes, etc.") Apart of the "state" thing, which I think is sub-optimal for the reasons explained above, this is fine, thanks.