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

[Alan Mackenzie<none@example.invalid>]

Eli Zaretskii <eliz@is.elta.co.il> wrote on Mon, 25 Nov 2002 08:22:09
+0200 (IST):

> On Sun, 24 Nov 2002, Alan Mackenzie wrote:

>> > Text properties are considered an integral part of the buffer's text
>> > because you want them to be copied together with that text.  Thus,
>> > any change in text properties causes the buffer to be marked as
>> > modified.

>> Hmm...  That still doesn't make much sense to me.  What does it mean
>> for a buffer to be marked as modified?  It surely means "The buffer
>> isn't the same as the file it was loaded from any more.".

> No, it means the text in the buffer has changed in some way.  For 
> example, copying the text into a string will yield a different string.
> If the buffer is in Enriched mode, saving it after changing text 
> properties will actually change the file on disk.

OK.  This is an example where TPs _do_ affect the saved buffer.

> 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.  Nomatter how a Latin-1 file, say, is decoded into emacs, it
still hold _exactly_ the same information as was in the file to begin
with.  Just as the file will look different on a CD-ROM from what it
looks like on a floppy disk, it's still the same file.  However, the
moment I type a space into the buffer, it's no longer the same as the
file.  

> 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.  It is a
change from the user's point of view.

>> I think the principal use of text properties is for font-locking.

> That's a wrong assumption, actually.  Perhaps that's why you have a
> difficulty to accept the fact that Emacs marks the buffer modified when
> text properties change.  Please read the chapter in the ELisp manual
> that describes text properties and see how many non-face-related
> properties are there.

OK.  I've not actually seen most of the non-face properties being used,
but then that's just the narrowness of my emacs experience.  But, hey, I
use syntax-table properties myself (without which parse-partial-sexp
would screw up in my buffers).  But looking at this list of properties
(elisp manual "Special Properties" page), ALL of them are to do with
emacs internal processing, and NONE of them to do with the final contents
of the saved file, with the exception of face-properties which are saved
in an enriched mode file.  (Any more exceptions?)

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?  Help,
help, I'm going round in circles.  :-(

>> Are there any uses of text properties where applying them to an
>> otherwise unmodified buffer would necessitate the buffer being saved
>> to its file?

> See the example of Enriched mode above.

Wow, enriched mode looks like a useful thing to have around!  Thanks,
Eli!

>> Ah, overlays.  What are they?  The elisp manual just says "they're a
>> bit like text properties in some ways, but otherwise totally
>> different.".  Other than the fact that they don't set the
>> buffer-changed flag, I can't see any uses for them distinct from those
>> of text properties.

> The main differences is exactly what bothered you: overlays aren't 
> considered part of the text, only a display feature.

OK.

-- 
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").