From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.help Subject: Re: Loading files at startup (desktop) and revert-buffer leave buffers **. Date: Mon, 25 Nov 2002 23:26:31 +0000 Organization: muc.de e.V. -- private internet access Sender: help-gnu-emacs-admin@gnu.org Message-ID: <7jbura.v5.ln@acm.acm> References: NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1038341170 17749 80.91.224.249 (26 Nov 2002 20:06:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 26 Nov 2002 20:06:10 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18Gly7-0004bH-00 for ; Tue, 26 Nov 2002 21:06:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18GlyO-0006oo-00; Tue, 26 Nov 2002 15:06:20 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-han1.dfn.de!news-nue1.dfn.de!uni-erlangen.de!lmu.de!news.muc.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 88 Original-NNTP-Posting-Host: acm.muc.de Original-X-Trace: marvin.muc.de 1038340216 72650 193.149.49.134 (26 Nov 2002 19:50:16 GMT) Original-X-Complaints-To: news-admin@muc.de Original-NNTP-Posting-Date: 26 Nov 2002 19:50:16 GMT User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (Linux/2.0.35 (i686)) Original-Xref: shelby.stanford.edu gnu.emacs.help:107508 Original-To: help-gnu-emacs@gnu.org Errors-To: help-gnu-emacs-admin@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.help:4062 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:4062 Eli Zaretskii 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").