[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#4587: Antwort: Re: bug#4587: 23.1; sort-lines and sort-fields always
bug#4587: Antwort: Re: bug#4587: 23.1; sort-lines and sort-fields always set buffer modified
Thu, 01 Oct 2009 06:25:59 -0600
Thunderbird 220.127.116.11 (Macintosh/20090812)
Stefan Monnier wrote:
Yes, that's generally desirable. But in the above cases, given the way
the code currently works, it's fairly inconvenient to do (the code does
modify the buffer, it just so happens that the end text is the same as
the original text), so it doesn't seem worth the trouble.
Wouldn't it be possible in case of an unmodified buffer to copy the
content of the region at the beginning to a temporary buffer, compare it
to the result afterwards, and if they match to restore the unmodified
I'd indeed expect that to implement the feature you request, the code
would have to do something like that. Most likely not copying the text
itself, but instead storing an md5 or somesuch hash of the text.
Not suitable for Emacs, but maybe useful for Roland:
(defadvice sort-lines (around restore-buffer-modified-p activate)
(let* ((buffer-was-modified-p (buffer-modified-p))
(buffer-was-not-modified-md5 (if (not buffer-was-modified-p)
(when (and (not buffer-was-modified-p)
(not (equal buffer-was-not-modified-md5 (md5 (current-buffer)))))
I sometimes need to check a list (which isn't small enough to be checked
at a glance) after editing it if it is still sorted.
Now I write he region before and after sorting it to separate files and
compare them, but I wonder if a powerful tool like Emacs must keep such an
obvious annoyance like this...
No, it definitely doesn't have to keep such obvious annoyances.
But it's not very high on the priority list.
Denver, Colorado, USA
- bug#4587: Antwort: Re: bug#4587: 23.1; sort-lines and sort-fields always set buffer modified,
Kevin Rodgers <=