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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.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 18:15:32 +0300

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Cc: 13949 <at> debbugs.gnu.org
> 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?

The intervals do store the property itself, but I actually don't
understand why should you bother discerning between faces and the
other properties.  If the buffer text is really unchanged, the face
properties will be identical as well, right?

> 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?

There are a couple of properties that have special meaning for fill.el
functions, see there.

However, I thought you are working on infrastructure that isn't
supposed to be limited to what M-q does.  Was I mistaken?

Previous Next

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