[Top][All Lists]

[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

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
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]