[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Thinking about changed buffers

From: Stephan Mueller
Subject: RE: Thinking about changed buffers
Date: Mon, 28 Mar 2016 18:49:12 +0000

On Monday, March 28, 2016 10:31 AM Lars writes:

" If you load a file, and then hit "a", and then delete the "a", then
" Emacs will say that the buffer has changed.  If you hit "a" and then
" `undo', Emacs will say that it hasn't.

Personally, I have relied on the a-then-delete behavior when I
_want_ the file to be considered modified*.  That is, my mental
model of 'modified' matches the simplistic approach currently
implemented.  (And I use undo when I don't want to have the
buffer marked modified).

I'm not convinced that this aspect (text change-and-happens-to
-get-restored) is worth correcting.  Or even, a flaw at all; I suppose
It may depend on whether one reads 'modified' as meaning "has
been touched" or as "is no longer identical".

I've not come across any other editor with the proposed behaviour;
perhaps it's worth considering "compatibility with typical expectations"
here as well as "can Emacs be better in this regard than other editors".


* that said, I don't necessarily have a compelling reason for wanting
a modified buffer.  I've used it to ensure that revert-buffer will
reload the file to trigger a re-colourization of the buffer, fixing
cases where cperl-mode got confused.  There's lots wrong with this
scenario: I should pursue the cperl issue, and I've since found that
the recolourization happens on revert-buffer without it being
modified, but the point remains that char-then-backspace is a
concise, intuitive, idiom that works with the current simple model.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]