all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Joost Kremers <joostkremers@fastmail.fm>
Cc: raman@google.com, emacs-devel@gnu.org
Subject: Re: Text Properties And Buffer Modification
Date: Wed, 05 Dec 2018 10:30:17 +0200	[thread overview]
Message-ID: <83o9a08jfq.fsf@gnu.org> (raw)
In-Reply-To: <87wooofnqf.fsf@fastmail.fm> (message from Joost Kremers on Wed,  05 Dec 2018 08:15:36 +0100)

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Wed, 05 Dec 2018 08:15:36 +0100
> Cc: "T.V Raman" <raman@google.com>
> 
> > Because text properties are part of the buffer text: if you copy
> > some of the text into another place, the properties go there as
> > well.
> 
> But isn't that at least somewhat counter-intuitive, given that 
> they are usually not saved to the file the buffer is visiting?

Whether or not the properties are saved depends on the properties and
on the major mode.  E.g., modes that use markup are expected to save
at least some text properties.

> Up until now I've always understood the modified status of a buffer
> to mean that there is a discrepancy between what is on disk and what
> would be on disk if the buffer were saved in its current from. The
> Emacs Manual indeed seems to say so: "If a buffer contains changes
> that have not been saved, we say the buffer is 'modified'" (info
> "(emacs) Visiting").

There's nothing wrong with what the manual says, unless you interpret
"save" too literally, by actually examining what's on the disk file.

As a counter-example, consider "C-x RET f": it doesn't change the
buffer text, but still marks the buffer modified.

So yes, it might take some getting used to, but I see no conceptual
problem with how Emacs treats changes in text properties.  Granted,
I've got used to that many years ago.

> Granted, buffers that are not visiting a file can also be 
> modified, but they are essentially *always* modified, so their 
> modification status is largely irrelevant. (Isn't it?)

No, I don't agree with that.  Don't forget that the modified status is
important for more than just saving to a file: it is important for
redisplaying the buffer, for example.  And some buffers that don't
visit files are "written" in other ways, like email message being
sent.



  reply	other threads:[~2018-12-05  8:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04 23:39 Text Properties And Buffer Modification T.V Raman
2018-12-05  6:33 ` Eli Zaretskii
2018-12-05  7:15   ` Joost Kremers
2018-12-05  8:30     ` Eli Zaretskii [this message]
2018-12-05 15:32       ` Stefan Monnier
2018-12-05 17:35         ` T.V Raman
2018-12-05 18:42         ` Eli Zaretskii
2018-12-05 19:04           ` martin rudalics
2018-12-05 19:09             ` Eli Zaretskii
2018-12-06  9:07               ` martin rudalics
2018-12-06  9:19                 ` Eli Zaretskii
2018-12-06 10:10                   ` martin rudalics
2018-12-06 10:28                     ` Eli Zaretskii
2018-12-06 18:46                       ` martin rudalics
2018-12-06 19:16                         ` Eli Zaretskii
2018-12-08  9:42                           ` martin rudalics
2018-12-08 11:22                             ` Eli Zaretskii
2018-12-05 20:54           ` Stefan Monnier
2018-12-06  6:04             ` Eli Zaretskii
2018-12-05  9:16   ` martin rudalics
2018-12-05 10:54     ` Eli Zaretskii
2018-12-05 19:04       ` martin rudalics
2018-12-05 19:08         ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83o9a08jfq.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joostkremers@fastmail.fm \
    --cc=raman@google.com \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.