From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alex Schroeder Newsgroups: gmane.emacs.devel Subject: Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye] Date: Mon, 24 Jun 2002 23:17:32 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <87u1nse5qr.fsf@emacswiki.org> References: <200206201435.g5KEZLF18772@aztec.santafe.edu> <5xu1nxh6o7.fsf@kfs2.cua.dk> <200206221720.g5MHKLj16237@rum.cs.yale.edu> <877kkrw1pz.fsf@emacswiki.org> <200206231812.g5NICiS24452@aztec.santafe.edu> <87r8ixazu9.fsf@emacswiki.org> <200206241940.g5OJe8v26290@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1024953497 27329 127.0.0.1 (24 Jun 2002 21:18:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 24 Jun 2002 21:18:17 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17MbE1-00076g-00 for ; Mon, 24 Jun 2002 23:18:17 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17MbFK-0005OC-00 for ; Mon, 24 Jun 2002 23:19:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17MbDx-0002iR-00; Mon, 24 Jun 2002 17:18:13 -0400 Original-Received: from relay01.cablecom.net ([62.2.33.101]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17MbD8-0002gV-00 for ; Mon, 24 Jun 2002 17:17:22 -0400 Original-Received: from smtp.swissonline.ch (mail-4.swissonline.ch [62.2.32.85]) by relay01.cablecom.net (8.11.6/8.11.4/SOL/AWF/MXRELAY/06072001) with ESMTP id g5OLHLV29083 for ; Mon, 24 Jun 2002 23:17:21 +0200 (CEST) Original-Received: from confusibombus (dclient217-162-235-193.hispeed.ch [217.162.235.193]) by smtp.swissonline.ch (8.11.6/8.11.6/SMTPSOL/AWF/2002040101) with ESMTP id g5OLHLu16354 for ; Mon, 24 Jun 2002 23:17:21 +0200 (MEST) Original-Received: from alex by confusibombus with local (Exim 3.12 #1 (Debian)) id 17MbDI-0000C3-00 for ; Mon, 24 Jun 2002 23:17:32 +0200 Original-To: emacs-devel@gnu.org X-Face: ^BC$`[IcggstLPyen&dqF+b2'zyK#r.mU*'Nms}@&4zw%SJ#5!/7SMVjBS7'lb;QK)|IPU5U'o1'522W4TyzB3Ab*IBo^iw]l4|kUbdZuUDO6=Um-.4IzhNiV'B"@K#jy_(wW|Zbk[34flKY^|PrQ?$u2\fKg^]AY>wOX#H32i In-Reply-To: <200206241940.g5OJe8v26290@aztec.santafe.edu> (Richard Stallman's message of "Mon, 24 Jun 2002 13:40:08 -0600 (MDT)") Original-Lines: 43 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2.90 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5171 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5171 Richard Stallman writes: > Yes, I understand the goal. But that is a user-level behavior you > want to change. There are many ways to do it; making > buffer-file-name non-nil is not a good way. I do not understand the argument, here. Perhaps what you are saying is that my solution does not fit the mental model developpers or users have, ie. the semantics are somehow wrong. Perhaps you want to say that the result users are seeing is not caused by what they think they did; Emacs is therefore surprising them. If so, I do not agree. We both agree on the goal. I think the best semantics for this is "When a user creates a non-temporary buffer (according to our naming conventions), treat this buffer as an unsaved file. It is precious, do auto-saving." You could then say that this is not something we want for just any buffer a user might create. There are lots of other buffers we want to kill silently. I reply to this that the code that creates temporary buffers not following our naming conflicts are in error. They should be fixed. Temporary buffers should follow our naming conventions. They are either invisible (names start with a space) or marked as temporary (names start and end with an asterix). Users know this. Users expect this. If they see a visible, seemingly non-temporary buffer in the buffer list, they may expect that everything they type into it will be auto-saved, and it will never be discarded without asking. These assumptions are currently violated in these rare cases. Now we can either fix the part about killing these buffers, or add something when creating these buffers. I think when we fix it on the creating side, we are fixing it on the safe side when it comes to users. Better safe than sorry. I think when we fix it on the killing of buffers side, we may find that there is yet another method of getting rid of buffers which we did not fix (I know nothing of the internals...). Alex. -- http://www.electronicintifada.net/diaries/index.html http://www.us-israel.org/jsource/US-Israel/hr2506c.html