From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#33005: 27.0.50; Data loss with Gnus registry Date: Sat, 19 Oct 2019 15:05:26 +1300 Message-ID: References: <871s8yvsrq.fsf@web.de> <87in29x33z.fsf@ericabrahamsen.net> <87r2gxygox.fsf@web.de> <87efcxwzr2.fsf@ericabrahamsen.net> <874ldtlcks.fsf@web.de> <87ftxdl7w1.fsf@ericabrahamsen.net> <878t33cjf2.fsf@web.de> <87o8za4gbl.fsf@web.de> <87mueuicys.fsf@ericabrahamsen.net> <87d0fgnik0.fsf@ericabrahamsen.net> <87v9srzm9g.fsf@web.de> <87ftjvz045.fsf@ericabrahamsen.net> <87tv8ajd6d.fsf@web.de> <87lftlsr90.fsf@ericabrahamsen.net> <87h849xds3.fsf@web.de> <87eezcpuac.fsf@ericabrahamsen.net> <87lftjkcj7.fsf@web.de> <87sgnr74ig.fsf@ericabrahamsen.net> <87sgnq5s3l.fsf@web.de> <87r23a5d0d.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="30254"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: Eric Abrahamsen , 33005@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 19 04:06:18 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iLe8D-0007bO-Ev for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Oct 2019 04:06:13 +0200 Original-Received: from localhost ([::1]:47826 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLe8C-0002sb-Bp for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Oct 2019 22:06:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45134) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLe83-0002sE-Bq for bug-gnu-emacs@gnu.org; Fri, 18 Oct 2019 22:06:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLe82-0005u6-5b for bug-gnu-emacs@gnu.org; Fri, 18 Oct 2019 22:06:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42941) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iLe82-0005tT-29 for bug-gnu-emacs@gnu.org; Fri, 18 Oct 2019 22:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iLe81-0003Qj-SI for bug-gnu-emacs@gnu.org; Fri, 18 Oct 2019 22:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2019 02:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33005 X-GNU-PR-Package: emacs Original-Received: via spool by 33005-submit@debbugs.gnu.org id=B33005.157145073413150 (code B ref 33005); Sat, 19 Oct 2019 02:06:01 +0000 Original-Received: (at 33005) by debbugs.gnu.org; 19 Oct 2019 02:05:34 +0000 Original-Received: from localhost ([127.0.0.1]:51762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iLe7a-0003Q1-2w for submit@debbugs.gnu.org; Fri, 18 Oct 2019 22:05:34 -0400 Original-Received: from smtp-1.orcon.net.nz ([60.234.4.34]:50633) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iLe7W-0003Po-4V for 33005@debbugs.gnu.org; Fri, 18 Oct 2019 22:05:32 -0400 Original-Received: from [116.251.203.173] (port=63282 helo=[192.168.20.103]) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1iLe7S-0005sh-VI; Sat, 19 Oct 2019 15:05:27 +1300 In-Reply-To: <87r23a5d0d.fsf@web.de> Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:169693 Archived-At: Hi Michael, On 19/10/19 3:44 AM, Michael Heerdegen wrote: > Phil, what's your opinion about this? gnus-mock.el wants to > edit a file it has opened with find-file-noselect, which is a > common thing to do. But it fails for me because I have enabled > global-so-long-mode in my init file and it makes the buffer > read-only. This is quite surprising because the buffer is only > used internally by gnus-mock. Could so-long be a bit smarter > here? This sounds very much like: https://savannah.nongnu.org/bugs/?56835 I have committed[1] a fix for that in my WIP branch here: https://git.savannah.nongnu.org/cgit/so-long.git/tree/?h=wip Could you test that and let me know if it fixes the issue for you? If so, I'll go ahead and merge the changes into Emacs. (I hadn't merged it to Emacs yet simply because its a notable change to how so-long has operated in the past; but I'm mostly sure it's going to be fine.) The documentation regarding this is as follows: ;; * Buffers which are not displayed in a window ;; --------------------------------------------- ;; When a file with long lines is visited and the buffer is not ;; displayed right away, it may be that it is not intended to be ;; displayed at all, and that it has instead been visited for ;; behind-the-scenes processing by some library. Invisible ;; buffers do not typically not cause performance issues, and it ;; might be surprising to the other library if such a buffer were ;; manipulated by `so-long'; so in these situations the ;; `so-long-invisible-buffer-function' value is called instead. ;; By default this arranges for `so-long' to be invoked on the ;; buffer if and when it is displayed, but not otherwise. This ;; is actually the normal way for `so-long' to be called -- even ;; when a visited file is displayed "right away", it is normal ;; for the buffer to be invisible when `global-so-long-mode' ;; processes it, and the gap between "arranging to call" and ;; "calling" `so-long' is simply extremely brief. -Phil [1]: https://git.savannah.nongnu.org/cgit/so-long.git/commit/so-long.el?h=wip&id=e9d6a4ef4ccde46e65f2bea9e4756ddc8cfab8e5