emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: modeline doesn't divulge buffer will go bye bye]


From: Alex Schroeder
Subject: Re: address@hidden: modeline doesn't divulge buffer will go bye bye]
Date: Mon, 24 Jun 2002 23:17:32 +0200
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2.90 (i686-pc-linux-gnu)

Richard Stallman <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]