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

[Alan Mackenzie<none@example.invalid>]

Kevin Rodgers <kevinr@ihs.com> wrote on Mon, 25 Nov 2002 10:02:46 -0700:

> Changing Text Properties
> ------------------------

>     The primitives for changing properties apply to a specified range of
> text.  The function `set-text-properties' (see end of section) sets the
> entire property list of the text in that range; more often, it is
> useful to add, change, or delete just certain properties specified by
> name.

>     Since text properties are considered part of the buffer's
> contents,....

This rather begs the question I was asking.  _Why_ should text properties
be considered part of the buffer's contents?  This isn't a rhetorical
question.  The way it is at the moment has sent at least one elisp
programmer (me) into a 4-month long confusion.  In the end, I had to
enclose t-p changes inside a macro which restores the buffer-modified
flag at the end.  font-lock, and its various ancillary modes, does the
same.  This is a big hassle.

Eli has pointed out a mode (enriched-mode), where t-p changes _are_
reflected in the eventual file contents, but I suspect this is a rare
thing in elisp code.

> .... and can affect how the buffer looks on the screen, any change in
> the text properties is considered a buffer modification.  Buffer text
> property changes are undoable (*note Undo::.).

Handy thing, that undo!

It seems to me that one should only be prompted to save a buffer to a
file (e.g. on C-x C-s, or C-x k) when one has changed the substance of
that buffer, not merely the way it has been displayed.  What is the
rationale behind prompting a user to save a "changed" file, merely
because he has changed its display within emacs to yellow letters, for
example?  The same goes for the two stars displayed on the mode-line.

Maybe there should be two distinct change flags.  A "user" change flag
when essential changes are made to the buffer, and an "internal" change
flag, to be used for buffer changes which can have no effect outside of
emacs. 

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").