From: Eli Zaretskii <eliz@is.elta.co.il>
Subject: Re: Loading files at startup (desktop) and revert-buffer leave buffers **.
Date: Mon, 25 Nov 2002 08:22:09 +0200 (IST) [thread overview]
Message-ID: <Pine.SUN.3.91.1021125081402.9888E-100000@is> (raw)
In-Reply-To: <cplrra.r5.ln@acm.acm>
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.
next prev parent reply other threads:[~2002-11-25 6:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1038117744.12302.help-gnu-emacs@gnu.org>
2002-11-24 23:02 ` Loading files at startup (desktop) and revert-buffer leave buffers ** Alan Mackenzie
2002-11-25 6:22 ` Eli Zaretskii [this message]
[not found] <mailman.1038205410.31195.help-gnu-emacs@gnu.org>
2002-11-25 23:26 ` Alan Mackenzie
2002-11-27 6:14 ` Eli Zaretskii
2002-11-27 6:52 ` Miles Bader
[not found] <j7phha.ab.ln@acm.acm>
2002-11-23 15:27 ` Alan Mackenzie
2002-11-24 6:01 ` Eli Zaretskii
2002-11-25 17:02 ` Kevin Rodgers
2002-11-25 22:45 ` Alan Mackenzie
2002-11-27 6:20 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.SUN.3.91.1021125081402.9888E-100000@is \
--to=eliz@is.elta.co.il \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).