bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as


From: Dani Moncayo
Subject: bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified
Date: Thu, 14 Mar 2013 19:34:31 +0100

>> In general, I think that a command should flag the buffer as modified
>> only when the buffer contents at the end of the command were different
>> from the contents at the beginning of that  same command.
>
> Then your wish is much broader than the original bug report says.
> E.g., you'd like the following to leave the buffer marked as
> unmodified, right?
>
>   emacs -Q
>   M-<
>   C-d
>   ;
>
> Or how about this:
>
>   emacs -Q
>   M-x overwrite-mode RET
>   M-<
>   ;

These two examples are recipes for modifying the buffer with several
different commands whose global effect is void.  In principle, one
could expect that the buffer be flagged as modified only when the
current text is different from the text in the file.  That makes
sense, and I thought about that, but I agree with you that that
behavior, while desirable, would imply a big impact in performance and
memory consumption, which is not justified at all for such a small
feature.

The expected behavior I described above is not exactly this, though,
because I put it in a command-by-command basis, but anyway, I think
that even then the price to pay would be too high in many cases (one
single command may modify a large portion of text, even the whole
buffer).

> fill-paragraph first removes all the newlines from the paragraph, and
> then inserts only as many as needed to get a filled paragraph.  So the
> buffer gets changed at least twice in the process.

Yes I understood that.  I think that a nicer algorithm would be not to
modify the buffer unless the resulting text is going to be different
to the current one.  But if that would entail too much work, I suggest
to spend your valuable energy in more important things :)


-- 
Dani Moncayo





reply via email to

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