From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Paul Stoeber Newsgroups: gmane.emacs.devel Subject: Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye] Date: Mon, 24 Jun 2002 22:47:22 +0000 Sender: emacs-devel-admin@gnu.org Message-ID: <20020624224722.GB218@xyz> References: <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> <87u1nse5qr.fsf@emacswiki.org> <87bsa09x5r.fsf@tc-1-100.kawasaki.gol.ne.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1024958929 5982 127.0.0.1 (24 Jun 2002 22:48:49 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 24 Jun 2002 22:48:49 +0000 (UTC) Cc: jidanni@deadspam.com Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Mcdd-0001YN-00 for ; Tue, 25 Jun 2002 00:48:49 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17Mcez-0007YQ-00 for ; Tue, 25 Jun 2002 00:50:13 +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 17McdU-00032U-00; Mon, 24 Jun 2002 18:48:40 -0400 Original-Received: from manelan061.rz.tu-ilmenau.de ([141.24.132.61] helo=xyz) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17Mccl-00030s-00 for ; Mon, 24 Jun 2002 18:47:55 -0400 Original-Received: from q by xyz with local (Exim 3.12 #1 (Debian)) id 17MccE-00004y-00; Mon, 24 Jun 2002 22:47:22 +0000 Original-To: emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <87bsa09x5r.fsf@tc-1-100.kawasaki.gol.ne.jp> 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:5175 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5175 On Tue, Jun 25, 2002 at 06:36:32AM +0900, Miles Bader wrote: > Alex Schroeder writes: > > 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." > > This is a big change in emacs' behavior. > > I often create _lots_ of small random buffers with wierd names, to hold > random data (by doing `C-x C-b' and typing junk). I expect these to go > away if I exit, and if I want something more permanent, I visit a file. > > I don't mind if emacs informs me on the mode-line that my scratch > buffers won't be saved, but I _do not_ want emacs to suddenly ask me > whether I want to save each one when I exit. > > > 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. > > Who's `they'? As you can see, I expect just the opposite. I'm satisfied with Emacs's current behaviour. Dan Jacobson's initial message: Dan> Buffer A has maximal autosaving, you name it, cutting edge in safety, Dan> all because it is associated with a file. Dan> Buffer B will go bye bye when you quit emacs, no matter what you put Dan> in it. The user gets to choose between the two: C-x C-f, or C-x b. Perhaps the interactive `switch-to-buffer' should print a warning in the minibuffer to make newbies aware of the difference. Dan> Their modelines will never tell you that, gotta hit C-x C-b and look around. False. Gotta hit C-x C-s and see. If the user is unable remember how he created the buffer, that's not too much to ask. Dan> Yes I know that most are *blabla*, but I'm talking about ones I create Dan> with C-x b blabla. OK, I don't do that too much, but that's not the point. See Miles Bader's remark above. It seems he _does_ do that more often than Dan. Dan> The point is that the modeline tells you all the little stuff. The Dan> most important thing, the fact that this buffer will go bye bye Dan> without a trace is not mentioned there! Okay, every user is entitled to worry about that point and to rate that fact as the "most important thing". Kevin Rodgers' reply to Dan's initial message might be a nice conclusion of this thread: Kevin> No, the point is that many of us have actually been using Emacs for 20 Kevin> years and not found it wanting in this regard, and those who want such a Kevin> reminder displayed can simply customize the mode-line-format variable. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^