Re: buffer-modified indicator in mode line - distinguish savable from unsavable changes

[Alan Mackenzie]

Hi, Drew!

On Sat, Jul 01, 2006 at 07:42:25PM -0700, Drew Adams wrote:
> The buffer-modified indicator in the mode line reflects two kinds of changes
> to the buffer: 1) changes that will make a difference if the buffer is saved
> and 2) changes that will not make any difference (the saved file will be the
> same, whether or not the buffer was changed in this way only).

> An example of a type 1 change is typing or deleting text. An example of a
> type 2 change is changing the face of a some text (e.g. using the facemenu).
 
> Type 1 changes let you rely upon interpreting ** in the mode line to mean
> that the buffer has not been saved since the last change. Well, that's true
> for type 2 changes too, but in that case saving makes no difference: type 2
> changes are not saved.
 
> I think it would be more useful to distinguish these two kinds of changes in
> some way, in the mode line. While it can sometimes be useful to know if a
> type 2 change actually took effect, most of the time I only want to see if
> the buffer needs saving, and for that type 2 changes are irrelevant.
 
> I would like to have the buffer-modified flag show 3 states: 1) unchanged,
> 2) type 2 changes only, 3) at least one type 1 change. The indicator might
> show this, for example: -- for unchanged (1), ++ for type 2 changes only
> (2), ** for at least one type 1 change (3). That way, ++ would show that
> something unsavable has changed, and ** would show that something savable
> has changed. For -- and ++, there is no need to save the buffer. When
> undoing, it is enough, for purposes of getting back to the saved buffer, to
> undo until ** changes to ++ (or --).
 
> WDOT? If others don't like that idea, how about at least having a user
> option that let's the buffer-modified indicator ignore type 2 changes, if a
> user prefers that (which I do)? With that option turned on, ** would always
> mean that a savable change has been made since the last save, and -- would
> always mean that the buffer does not need to be saved (any changes made so
> far are unsavable).

Before anybody else says it, we are talking about Emacs 23 here, aren't
we?

My own opinion is that we're suffering a conceptual problem here -
nobody seems to have firmly defined "changed".  Currently "changed"
seems to mean something like "there are entries in the undo list".  I
think it would be better redefined as "a state in which saving the buffer
would change the file".

Thus setting faces would set the changed flag in Enriched Mode, but not
in Emacs Lisp Mode.

Is there any benefit whatsoever in regarding a "type 2 change" as a
change at all?  I don't see one.

The consequences of the current (lack of) definition are seen in
font-lock.el in the existence of the ugly macro `save-buffer-state'.  We
shouldn't need macros like this.

All in Emacs 23, of course.

-- 
Alan Mackenzie (Munich, Germany)