[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33005: 27.0.50; Data loss with Gnus registry
From: |
Phil Sainty |
Subject: |
bug#33005: 27.0.50; Data loss with Gnus registry |
Date: |
Sat, 19 Oct 2019 15:05:26 +1300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
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
- bug#33005: 27.0.50; Data loss with Gnus registry, (continued)
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/14
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/10/14
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/15
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/10/15
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/16
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/10/16
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/17
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/10/17
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/18
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/18
- bug#33005: 27.0.50; Data loss with Gnus registry,
Phil Sainty <=
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/19
- bug#33005: 27.0.50; Data loss with Gnus registry, Phil Sainty, 2019/10/19
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/10/26
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/18
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/10/18
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/10/18
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/18
- bug#33005: 27.0.50; Data loss with Gnus registry, Eric Abrahamsen, 2019/10/18
- bug#33005: 27.0.50; Data loss with Gnus registry, Michael Heerdegen, 2019/10/19