Subject: Re: bug#4587: Antwort: Re: bug#4587: 23.1; sort-lines and sort-fields always set buffer modified

From: Kevin Rodgers <[email-masked]>
Date: Thu, 01 Oct 2009 06:25:59 -0600

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
>> status?
> 
> 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)
					  (md5 (current-buffer)))))
     ad-do-it
     (when (and (not buffer-was-modified-p)
	       (buffer-modified-p)
	       (not (equal buffer-was-not-modified-md5 (md5 (current-buffer)))))
       (restore-buffer-modified-p buffer-was-modified-p))))

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

-- 
Kevin Rodgers
Denver, Colorado, USA