GNU bug report logs - #4587
23.1; sort-lines and sort-fields always set buffer modified

Previous Next

Full log

Message #34 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#4587: Antwort: Re: bug#4587: 23.1;   sort-lines and sort-fields
 always set buffer modified
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

Previous Next

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