|
From: | Kevin Rodgers |
Subject: | 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 |
User-agent: | Thunderbird 2.0.0.23 (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 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
[Prev in Thread] | Current Thread | [Next in Thread] |