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

[Kevin Rodgers]

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