GNU bug report logs - #13949
24.3.50; `fill-paragraph' should not always put the buffer as modified

Previous Next

Package: emacs;

Reported by: Dani Moncayo <dmoncayo <at> gmail.com>

Date: Wed, 13 Mar 2013 22:11:01 UTC

Severity: wishlist

Tags: fixed

Merged with 21155

Found in versions 24.3.50, 24.4.1, 25.0.50

Fixed in version 26.1

Done: Lars Magne Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13949 <at> debbugs.gnu.org
Subject: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified
Date: Mon, 28 Mar 2016 12:39:54 +0200
Lars Magne Ingebrigtsen <larsi <at> gnus.org> writes:

> for iterate_over_all_intervals
>   sha1_process_bytes(interval, len)

I completely forgot about the distinction between text property changes
that "count" and the ones that don't here.  Font locking, for instance,
runs with `with-silent-modifications' so those changes "don't count",
but there's nothing in the intervals themselves that you can examine
after the fact, as far as I can tell.  Is that correct?

So the question is, I guess: Does `M-q' does something to text
properties that we have to keep track of, or is it sufficient to just
hash the buffer contents to determine whether `M-q' did something?

(Please take any further discussions about how likely it is that an
editing change will end up with the same sha1 to the emacs-tangents
mailing list.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




This bug report was last modified 8 years and 166 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.