Re: Loading files at startup (desktop) and revert-buffer leave buffers **.

[Eli Zaretskii <eliz@is.elta.co.il>]

On Mon, 25 Nov 2002, Alan Mackenzie wrote:

> > In other words, the connection with the file the buffer is visiting is
> > not the only one.  There are other examples of this in Emacs.  For
> > starters, a buffer does not need to be visiting a file.  More to the
> > point, text is decoded when it's read from file, so in general the
> > buffer _never_ holds the same stuff as the file.
> 
> I disagree.

It's okay to disagree.  I didn't design most of that stuff anyway, so I 
might not have all the definitive answers.  I just tried to explain to 
you the logic of the current design.  Text properties are _conceptually_ 
part of the buffer text, while overlays aren't.

> > As another example, "C-x RET f" also marks the buffer modified,
> > although it does nothing to the buffer contents.  Etc., etc.
> 
> set-buffer-file-coding-system - This is the converse case.  It should
> indeed mark the buffer modified, since if the buffer is now saved, the
> new file will (in general) be different from the old file.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Exactly!  In general, the file will be different, but in any particular 
case, it might be identical.  E.g., you could try setting the encoding to 
the same value, or to something that will leave the file's contents, when 
written, with no change.  Nonetheless, Emacs marks the buffer modified 
because the file _could_ be changed.

> I mean, Emacs is an editor, and editors are for changing files.  If a
> file's not going to get changed, why mark it's buffer as changed?

Again, that indication tells you that the _text_ of the buffer has 
changed in some way.  It doesn't necessarily tells you that the file will 
be different when written.