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

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

[Alan Mackenzie]

Eli Zaretskii <eliz@is.elta.co.il> wrote on Sun, 24 Nov 2002 08:01:30
+0200 (IST):

> On Sat, 23 Nov 2002, Alan Mackenzie wrote:

>> I don't see why setting text properties should mark a file as changed.

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

I think the principal use of text properties is for font-locking.
font-lock itself uses a macro "save-buffer-state" to preserve the
buffer-modified state whilst applying text properties, and it isn't the
only package to do this.  Are there any uses of text properties where
applying them to an otherwise unmodified buffer would necessitate the
buffer being saved to its file?

> If you want to put a face or some other display-related feature on a 
> text, but not have it copied with the text, use overlays.

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.  I suppose
I'll need to grep through the emacs /lisp directory to see how they're
used.

Thanks for the answer.

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

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

[Eli Zaretskii]

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.

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.  As another example, "C-x RET f" 
also marks the buffer modified, although it does nothing to the buffer 
contents.  Etc., etc.

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

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

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

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

[Alan Mackenzie]

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

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

[Eli Zaretskii]

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.

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

[Miles Bader]

Alan Mackenzie<none@example.invalid> writes:
> 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.

Not necessarily.  It's quite common for a buffer's contents to be
different from it's associated file in less subtle ways than character
encoding -- e.g., tar-mode, or hexl-mode, or the various hooks that you
can run before saving or after loading.

> I mean, Emacs is an editor, and editors are for changing files.

That's one thing they're useful for -- but emacs, at least, is used for
many, many, other things.  It's a pretty fundamental part of the emacs
model, I think, that buffers and files are not equivalent.

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

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

[Alan Mackenzie]

Alan Mackenzie <none@example.invalid> wrote on Mon, 22 Jul 2002 20:16:51
+0000:
> Emacs 21.1.

> I am using desktop (i.e. I have
>    (load "desktop")
>    (desktop-load-default)
>    (desktop-read)
> in my .emacs)

> Some of my files which get loaded continually (and which I rarely/never
> save) are marked as changed in the mode-line ("**") each time I start
> emacs.

> Whenever I perform a revert-buffer for any of these files, the buffer
> gets reverted, yet the mode-line continues to display "**".

> For what it's worth, there is a file called #filename# for each of these
> files.

> Is this a bug, or have I misunderstood something?

> Thanks in advance.

Hi, everybody.  My problem was nothing whatsoever to do with desktop.

What was happening was that I was setting text properties on these files'
buffers immediately after loading them (I think that loading a file
counts as a "change" for after-change-functions).  Setting text
properties marks a file as changed.

I don't see why setting text properties should mark a file as changed.
It seems to me that text properties are more an internal lisp structure,
and the buffer-changed flag should reflect only changes to the contents
of the buffer - i.e. that were the buffer to be saved, it would have
different contents from the file that had been loaded.  What is the
thinking behind this use of the buffer-changed flag?

Anyhow, apologies to anybody I sent off on a wild goose chase tracking
down this non-existent bug.

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

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

[Eli Zaretskii]

On Sat, 23 Nov 2002, Alan Mackenzie wrote:

> I don't see why setting text properties should mark a file as changed.

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.

If you want to put a face or some other display-related feature on a 
text, but not have it copied with the text, use overlays.

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

[Kevin Rodgers]

Alan Mackenzie wrote:


> Hi, everybody.  My problem was nothing whatsoever to do with desktop.
> 
> What was happening was that I was setting text properties on these files'
> buffers immediately after loading them (I think that loading a file
> counts as a "change" for after-change-functions).  Setting text
> properties marks a file as changed.
> 
> I don't see why setting text properties should mark a file as changed.
> It seems to me that text properties are more an internal lisp structure,
> and the buffer-changed flag should reflect only changes to the contents
> of the buffer - i.e. that were the buffer to be saved, it would have
> different contents from the file that had been loaded.  What is the
> thinking behind this use of the buffer-changed flag?


File: elisp,  Node: Changing Properties,  Next: Property Search,  Prev: Examining Properties,  Up: Text Properties

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,
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::.).


> Anyhow, apologies to anybody I sent off on a wild goose chase tracking
> down this non-existent bug.


-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

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

[Alan Mackenzie]

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

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

[Eli Zaretskii]

On Mon, 25 Nov 2002, Alan Mackenzie wrote:

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

Think about Emacs as a word processor which can save the formatting and 
typeface of characters in the buffer's file.  In that case, when a 
typeface changes, the file's contents change.  The fact that Emacs 
currently doesn't save faces in the file is mostly irrelevant; it could 
start doing that in the future, if, for example, compilers will begin to 
accept XML files as sources.

Or look at it this way: when the program's source is visited by Emacs in 
another session, it's again fontified as it was before.  For all 
practical purposes, the face was ``saved and restored''; the fact that it 
didn't come from the file is something that you know about Emacs's 
internal operation, that's all.