[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16433: 24.3.50; find_newline screws up in Rmail buffers
From: |
Richard Stallman |
Subject: |
bug#16433: 24.3.50; find_newline screws up in Rmail buffers |
Date: |
Wed, 15 Jan 2014 07:29:05 -0500 |
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Sorry, no, I don't have a recipe. It was reproducible for the same
> message, at that time, but I don't know a way to make it fail again.
To reproduce it at that time, do you happen to remember what sequence
of commands was needed?
(mail-fetch-field "X-RMAIL-ATTRIBUTES") reproduced the bug, when it
was happening.
If and when it happens again, please try to look for editing
operations that change buffer text (insert or delete characters), but
do not invalidate the cache for the region where characters were
inserted or deleted.
I had not done any manual editing on the RMAIL buffer.
It was operated on by Rmail commands. If you see what editing
functions they call, you will see what I did to the RMAIL buffer.
It's possible I decrypted it with rmail-epa-decrypt.
> Perhaps buffer-swap-text should simply invalidate the cache.
Could be, but just by looking at the code, it seems like
buffer-swap-text does TRT, i.e. it swaps also the pointers to the
cache. So maybe my guess was wrong, and some other factor is at work
here.
If it isn't obvious what is wrong, we need to fix this bug somehow. I
am thinking of turning off the newline cache in Rmail mode.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.