Re: How to get rid of *GNU Emacs* buffer on start-up?

[Alan Mackenzie]

Hi, Xah!

Surely this thread of discussion is approaching its end, now.

On Fri, Sep 26, 2008 at 06:28:03AM -0700, Xah wrote:
> Kevin Rodgers wrote:

> > > «
> > >     * There is no easy, intuitive way to create multiple scratch
> > > buffers. (it is done by using the switch-to-buffer command (C-x b) and
> > > give name that is not one of existing buffers.)

> > We'll have to disagree: I think that is both easy and intuitive.

> What seems to you intuitive is not intuitive to the general text
> editing audience. The text editing audience is broad, including all IT
> professionals, those in academics. Many of these people, wouldn't have
> clude if you ask them to define variable or algorithm or byte. Perhaps
> you are thinking these people are stupid. Perhaps when compared to you
> as a tech geeker, they are quite ignorant about computers. But the
> world is big, there are all walks of life. Many of them are in fact
> scientists, engineers, mathematicians, lawers.

We know all this.

> You wouldn't know shit if i ask you some elementary math concepts
> (trust me). Similarly, you don't know the most elementary thing about
> laws, engineering, ... all all sort of fields.

Again, the Emacs developers, certainly the users, collectively have
substantial knowledge in all these fields.

> One element of User Interface design is that the user don't have to
> learn anything in order to use it, as much as possible.

Possibly.  But that element of UI is subordinate to efficiency in things
like Emacs or a modern airliner.

> Emacs has too many unusual ways... (btw, i'm damn repeating myself
> again and again and again here... in this thread i've already wrote
> paragraph(s) that details this).

Yes, Emacs has lots of "unusual" ways, and yes, you are repeating
yourself.  But consider how these "unusual" things have come about;
they've sort of evolved: new things have been tried, and if they've been
good they've become part of Emacs, otherwise they've been discarded and
forgotten about.  Emacs's features aren't random.

> Please, have a open mind. Open mind is not easy, you really have to
> put effort into it.

Please, you too.

> For example, let me ask this: have you ever, actually try to look into
> the knowledge of User Interface? What it entails? What academic field
> in involves? Have you actually read a text book on it? Whats the
> latest research on it? Who are the dignitaries in the research? What
> are the common, standard, or well known reference for UI?

No, I haven't.  Have you?  Emacs, by the very way it has developed, has a
good UI.  If you could cite me any papers written by UI academics about
Emacs, I'd certainly be interested to read them.  I'm sure I could learn
quite a bit.

> again i'm repeating, and you may think i sound like ergomaniac, or you
> might think i'm bullshitting ... but the opinions expressed here by
> tech geekers are really completely ignorant. Ask any UI expert,
> researcher, they'll laugh.

Would they really?  Again, have you seen any relevant publications where
some UI expert has criticised Emacs's interface.  Perhaps we could
improve it.

> The things i say, just about every aspect of this thread's argument,
> can be reasonably verified, acertined.

That's unlikely; unless I've missed something, you haven't yet cited any
authoritative sources.  Mostly, you've just cited your own work.

> But you guys didn't even go up to the level of question about
> verification, such as how can we carried out, etc. You you guys are
> saying, basically at the level of ???emacs is not Microsoft and emacs
> should not dumb down???!!

Yes, indeed.  Many of these other programs are intended to be easy to
learn.  Emacs is intended, instead, to be easy to use.  The aims are
different, so the results are different.

> > >     * When the scratch buffer is closed, emacs does not prompt user
> > > to save it. This easily causes data loss.

> > What part of the initial contents of the *scratch* buffer is not clear:

> > ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> > ;; If you want to create a file, visit that file with C-x C-f,
> > ;; then enter the text in that file's own buffer.

> See above. One element of software UI design is that it should keep it
> to minimal for users having to spend time learning things that is not
> directly relevant to her tasks.

No.  As said above, Emacs is designed to be _efficient_.  One of the
costs of this is that there a lot of little details that users need to
learn.  It's a tradeoff.  People who don't want to put in the learning
time should be using a different editor.

[ .... ]

> > So set initial-major-mode to your favorite text or programming language
> > mode.  Mine is emacs-lisp-mode.

> Again, the discussion, criticism, is not about ???Hi guys, do you know
> a way so that i can do xyz in emacs????. It is not about how one
> individual can customize emacs to some way.

Sorry, Xah, but that is PRECISELY what Emacs is about.  Emacs was
designed explicitly to be as configurable as possible.  That way, each
user can set up her own Emacs to suit her way of working.  I couldn't
work well with Emacs set up the way you're advocating, and I doubt you'd
much like the way I've set up my Emacs.  There are some defaults in Emacs
which, to me, are utterly stupid and crazy, and I've spent many, many
hours trying to explain to the rest of the Emacs developers why some of
their ideas are so stupid.  ;-)  They, in their turn, have defended their
stupidity, and argued that they're the best thing ever invented.  ;-)

There are no absolutes here.  Users vary enormously.

> I have written this again and again...

Yes, you have.  But that doesn't make what you've written any truer or
more valid than if you'd only written it once.

[ .... ]

> It is one of the items that details a problem of *scratch*, in support
> of my proposal. It is not about ???how can i, Xah Lee, set emacs so
> that the *scratch* buffer start in xyz mode???.

It isn't an intrinsic problem with *scratch*.  The problem is in the
relationship between the user and the *scratch* buffer.  The solution is
to configure Emacs until that relationship functions smoothly.

> No disrespect, but please perhaps take a course in college about
> critical thinking or philosophy:
> http://en.wikipedia.org/wiki/Critical_thinking

That is very disrespectful.  There has been no lack of quality critical
thinking from most of the people in this debate.

Would you please now reassure all of us that you have taken, or will take
heed of what we've been telling you, and will incorporate our points into
your thinking, whether you agree with them or not.

> -----------------------

[ .... ]

> > Agreed.  I think you should lobby the Emacs maintainers to include
> > something like the switch-to-new-buffer command I proposed.  But it
> > does need to be enhanced to prompt for saving when it is killed.

> You can help me with it, by filing a bug report on the *scratch*
> buffer, borrowing whatever part in my article you think you agree, or
> perhaps completely on your own reasons.

But you could do this yourself, couldn't you?

> As you perhaps know, i've had quite few heated arguments here. This
> thread is now 120 messages going to the level of ???fuck you's???.
> About 3 or 4 similar threads on other emacs issues has happend in the
> past 2 or 3 monhs.

Indeed.  Remember me telling you a few days ago that using swear words
(even without 6 surrounding question marks ;-) doesn't help you get your
message across?  If we looked at the thread to see who has been using
these bad words most, I wonder who would it be?

> I'm not getting paid to debate. The several items in emacs
> modernization proposals doesn't benefit me directly in any way, and it
> is not likly to be incorporated into emacs anytime soon.

No.  They're never going to be incorporated until somebody implements
them.

> Instead of suggesting me to do something, why don't you do something
> about it? I'm not trying to be rude, and i very much appreciate your
> argument here, one of the 3 or 4 in this thread that actually are
> sincere and has content, in my opinion.

Is there any reason you can't implement these things yourself?  Or is
there some reason you don't want to?

[ .... ]

> > >> 3. You contradict yourself to some degree by complaining that
> > >> temporary buffers can be killed without prompting the user about
> > >> whether and under what name to save them.  I think it would be
> > >> clearer if you said "empty" buffer instead of "temporary".

> > > I'm not sure i understood exactly what u mean.

> > Temporary objects are those which are not intended to be saved.

> Ok. i see what you are saying.

> > > What i meant in my article or post was that, emacs won't offer save
> > > for buffers not associated with a file. This is so for buffers
> > > created using the switch-to-buffer command.

> > Yes, it is a convenient feature.  :-)

> Emacs not prompting to save for any buffer not associated with a file,
> is a major problem. Please check with any respected UI expect...

Emacs also doesn't offer to save the contents of the minibuffer, or any
of a whole host of other buffers.

> i don't think it's fruitful for me to keep arguing. I've outlined all
> the reasons i can think of in my article. The large discussions in 120
> messages thread, almost added no value. ...

Surely you have learnt quite a bit from it?  I've learnt that in many
programs, Ctrl-n creates a new thingy.

> maybe to be constructive, how about you giving me a reason why not
> prompting for save is good?

This is one of those "relationship" things.  For some people, this
prompting would be useful, for many (including Kevin and me) it would be
a nuisance.

> ok, let me start... the emacs way of not prompting, you argue that's
> because some buffers are just temp, so user don't need to be prompted
> because they used it as throwaway ones in the first place. I argue no,
> because having user to remember which buffer is temp, or having user
> to be aware that the buffer is the *scratch* one, is a burden on the
> mind. Of course, it's not a major one, but such little things are
> problems. On the other hand, if you follow my proposal, user no longer
> need to keep in mind which buffer is meant for temp. As soon as they
> call close command, emacs will promp them to save if necessary.

And this prompting to save is an unnecessary and unpleasant nag.  When
you get something like this time after time after time, eventually you
just press the 'n' key automatically, without thinking.  Sooner or later,
you'll do the same when it's prompting you about a valuable buffer.  So
this feature of prompting to save *scratch* would cause you to lose
valuable buffers.  (This has happened to me in other programs.)

> > >> I prefer progress to modernization.

> > > The ???modernization??? is just a descriptive tag. Am not sure
> > > exactly what you mean. Modernization is simply a collective term
> > > for emacs improvements that happens to make emacs more compatible
> > > with modern terminologies, UI sandards. Many tech geekers will
> > > perhaps think ???modernization??? means ???let's make emacs like
> > > Microsoft???. No. It is not the intention nor the goal. (Of
> > > interest to note, that it is EXACTLY Linux's KDE's prominently
> > > published manifesto, for example, when it starts in about 1998.)

My impression of your proposals is that they would make Emacs more like
these other programs, and in so doing make Emacs worse.  For example, it
stands to reason that you reserve short key bindings for frequently used
commands.  Yet you are advocating using a shortest binding (Ctrl-n) for
opening a new buffer, something which is done only rarely.  (I use it, on
average, less than once per Emacs session.)

> > Whether a technology or UI convention (not standard) is good has
> > little to do with how modern it is, regardless of its sponsor.

> to be perfectly logical, that's right, but it kinda disregard common
> sense. As a analogy, whether a technology is better does not depend on
> whether it is modern. So, irregation, transportations methods in say
> 1500s, may actually be better than today's. But that's silly.

A better way of looking at it is how long a technology has been developed
for.  Since irrigation has developed over several millennia, you'd expect
it to have attained an optimum by now.  Similarly, the Emacs UI has
developed over ~30 years.  The sort of things you want to put in are
much newer by comparison, and exist mainly in environments where they're
not subject to selection and improvement.

> In software UI, sure, the issue is not that clear cut. However, you
> cannot brush away, or in the case of tech geekers, to sneer the UI
> designed by successful companies such as Microsoft, Apple, Google.

Oh, we could, but there's no need to.  Those UIs have different design
objectives from Emacs's.

> In other point of view, why not take the perspective and think, to
> what degree you are simply being a emacs fanatic and refuse to see
> things? Surely, you can imagine how vi users will argue to the death
> if you tell them some vi ways is inferior to emacs. Sure, there's a
> lot fanaticism. Are you saying fanatism is good? Are you saying that
> Microsoft, Apple, Google, etc are mere marketing and exploination of
> the dumb?

I'm really not sure what you mean by "Emacs fanatic".  Of course the
people on this mailing list will tend to be Emacs fanatics.  You are,
yourself, are you not?

> I get quite worked up when discussiing with you tech geekers...
> sometimse i don't care... you guys are just extremely idiotic.

That's what's known as an "ad hominem attack".  Rather than debating the
issues with people, you attack them personally.

> You can quote me on this. Argue with me, argue with all your silly
> argument with me and snowball this thread... so perhaps we can get it
> to some wider public attention. When the discussion of tech geekers
> such as this thread goes to the wide public, perhaps the public at
> large, all expert of various fields, will come to know that i'm a
> nutcase, but there's one thing they'll agree on: how ignorant and
> downright stupid the tech geekers are about UI, critical thinking.

Just what is it that makes you think that you're right, and we're all
wrong?  That's not a rhetorical question.  After so many people have
disagreed with you on this thread, have you not examined your own
thinking to see whether or not you might have gone wrong somewhere?
Perhaps made a few unwarranted assumptions, and then followed them with
impeccable logic?

> Have a good day Kevin. (^_^)

I'm not Kevin, but you have a good day too, Xah!

>   Xah
> ??? http://xahlee.org/

-- 
Alan Mackenzie (Nuremberg, Germany).