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

[Alan Mackenzie <acm@muc.de>]

Hallo again, Xah!

On Mon, Sep 22, 2008 at 06:07:34AM -0700, Xah Lee wrote:
> On Sep 20, 1:17 am, Alan Mackenzie <a...@muc.de> wrote:

[ .... ]

> > > > I don't know where you get your figure of 99% [of people for whom
> > > > *scratch* is supposedly not useful] from.
> > > It is a ballpark estimate.

> > You mean a wild guess, based on nothing at all?

> Lol. Alan, do u really live in a cave or what?

> I've always found emacs developers or lisp coders to be weird cave
> dwellers who bury their head in their perspective tech and have little
> understanding of software industry and professional programers.

You're really not in touch, are you?  Many of the Emacs developers,
probably most, possibly even all are professional programmers.  I
certainly am.  Developing Emacs would be well beyond the capabilities of
all but a tiny number of hobbiests.

> I started using emacs daily since 1998. I only started learning elisp
> in 2006. I have actually actively resisted in learning elisp, because
> of fear of falling into a blackhole of code diddling of little
> significance. Too bad, i have now since fallen into this hole. After
> all, i haven't had a day job since about 2004.

I'm sorry about that (the day job).  Do you want one?  A danger of
learning Lisp is becoming aware of the shortcomings of lesser languages
(nearly all others).

> it's quite bizzar when you hear some of the lispers. When's the last
> time you saw the sun, Alan?

Er, this morning.

[ .... ]

> > Emacs is intended for programmers, though it's great that other sorts
> > of writers find it useful too.

> That sentiment is rather silly to meaningless.

You mean you haven't understood it?  I'll try and explain it more
clearly.

> Sometimes in other context, you see emacs fanatics insist that emacs is
> the best tool for non-programing text editing, period. In fact, you see
> a few heads popping up here now and then saying how great they love
> emacs and they are not programers but writers.

> In other times, like now, you see emacs hotheads insists that emacs is
> more for programers and programers primarily, to the degree that if
> they don't know much about program, perhaps they should goto Microsoft
> Word, and about how emacs ???should not dumb down for these people???.

That's not the sense in which the comment is made.

> Execuse my French, but when i discusses these issues, it gets me angry
> over the degree of their FANTASTICAL STUPIDITY.

> So Alan, what does it really mean, to say that ???Emacs is intended for
> programmers, though it's great that other sorts of writers find it
> useful too.???? What does it signify? Does it imply anything? Does it
> actually mean anything other than a sentimental catch phrase to
> express certain love of emacs??

Yes.  When Emacs was written, back in the mists of time, it was written
purely as a programmers' editor.  Like many other great programs, it was
later found to be useful for other tasks than its intended one, one of
these being editing normal text.  This contrasts with, for example, word
processing programs.

[ .... ]

> > In the places I've worked, lots of people have asked me for help on
> > their Emacsen, but the question of getting rid of *scratch* hasn't
> > come up even once.  How many people have you met in real life who've
> > asked you to do that?  Xah, it really isn't a big deal.

> most people simply stopped using emacs. See:

> Text Editors Popularity
> http://xahlee.org/emacs/text_editor_trends.html

Really?  Funnily enough, you list Emacs in joint second place (along with
vim).  The most popular (Microsoft Visual Studio) is an IDE, with a
severely restricted range of application, so it's not really comparable.

[ .... ]

> > > > Have you considered coding an option so that this buffer would
> > > > only be created when, at startup time, there was no other buffer?
> > > > And coding another option so that when you killed it, it would
> > > > stay killed?  Write a patch, and submit it to
> > > > emacs-de...@gnu.org.  It might well be accepted for Emacs 23.
> > > Please understand, the issue is not:
> > > (1) whether i should write a patch,
> > > (2) nor is it about writing a patch that do something you think is
> > > better.

> > No, it's about writing a patch for something _you_ want.

> in commercial software, it's not about something you want. It's about
> what makes money, and that is determined by how people actually want
> to pull money out of their pocket. In order to achieve that, is about
> what's really best, that people want.

That's far from clear.  Often the winner in the market is not the
(technically) best product.

> In Open Source software, it's largly driven by the need of a few
> coders. Emacs came to be largely because that's what Richard Stallman
> needs in the 1980s.

Indeed.  And that code was so amazingly good that it was grabbed by
masses of good programmers.  It was and is so good that it's still
thriving after 25 years.

> ... am not going to write another thousands word article and surely
> followed by wild discussion on this ... maybe you see some of my
> points.

I see a lot of your points.  I just disagree with most of them.

[ .... ]

> > I've had a wee look at it.  You have at least one thing there which
> > is false, namely "Emacs does not provide a user level function to
> > create a new buffer".  There is C-x b.  You then go on to complain
> > about having to give a definite file name when you do C-x C-f to
> > create a new file.  It seems to me that between these two commands
> > you can get what you want here.

> I have given reasons why C-x b is unfit for creating a temp buffer.

That's a entirely different thing from there being no user level
function.  What you've written on this page is not true.  I'm suggesting
you replace it with a sentence saying "C-x b is not very good for ....".

> To begin, the name is switch-to-buffer.

This richness of functionality is pretty much essential to Emacs.  The
alternative would be to have many more different commands.  If you put
the question "what happens when you do C-x b, giving it a name which
isn't an existing buffer?" there are two sensible answers: signal an
error, or create that buffer.  Which do you think is more useful?  (That
isn't a rhetorical question.)

> Also, emacs doesnt offer to save a buffer not associated with file, so
> you have potential data lose...

Yes, you do.  This is closely related to personal working style, and it
would be good for there to be an option to prompt when killing such
buffers.  I've already suggested you write this.

> I also give reason why C-x C-f is unfit, because it prompt for a file
> name...

You've said this, but I can't see what you're getting at.  Why is
prompting for a file name when you open the buffer worse than prompting
for it when you save it?

[ .... ]

> > > > > * The Ctrl+n shortcut for New is standard and familiar to all
> > > > > software users.
> > > > That's not true.  It's not familiar to me.
> > > You are not a typical software user. You are a tech geek.

> > I am a software user.  "All" means all without exception.  What you
> > wrote has been refuted by counterexample.  (Guess what I subject I
> > graduated in!)  Take it as a free lesson in English.  ;-)

> it would be ridiculous to say that you are not familiar with Ctrl+n.
> Try to put that on your resume. Like this: ???I, Alan, although am a
> tech geek, but i don't know what Ctrl+n??? is in today's software.
> Please do hire me though.???

I am indeed familiar with C-n, as the key binding for `next-line'.  I'm
not familiar with it as "open a new file", because I don't use that sort
of software very much.

> LOL. How silly can tech geekers get? Really? How utterly bizarre and
> silly can they get? Alan, you ???are not familiar with Ctrl+n??? eh?

So the criterion for being bizarre and silly is not knowing Ctrl+n??? ?
Come on, old man, you can do better than that!  ;-)

> > > > > * By adopting the New Buffer and Ctrl+n, users can intuitively
> > > > > create multiple scratch buffers for any purpose.
> > > > Being able to create several *scratch*'es might well be useful.
> > > Yes. Thank you.

> > Taking another look at my .emacs, I see I've got M-n bound for this:

> >     (define-key lisp-interaction-mode-map "\M-n" 'clone-buffer)

> > This is easy enough, apart from discovering that it's possible.

> huh? are you saying that clone-buffer is a good way to create a new
> buffer?

No, I'm ambivalent about it.  It works, but it's rather obscure.  It took
me longer to find than it should have done.  But then, taking a new
buffer's characteristics from an existing one is less hassle than having
to type them in explicitly.  It would be nice if there was a more obvious
command to do this, but I can't fomulate this new command myself.

[ .... ]

> > But "familiarity is [an] important aspect of ... usability".  This is
> > confused thinking.  Merely by using software, any software, you will
> > become familiar with it.  This has no bearing on how usable the
> > software is.  Emacs is supremely easy to use, and some programs
> > (several popular Microsoft programs, for example) remain ghastly to
> > use, no matter how familiar with them you become.

> Sorry if i sound rude, but what you said, your attitude, your
> sentiment, your feelings about software user interface, typical of
> tech geekers, are the most motherfucking, baseless, stupid.
> Fantastically stupid. Moronic. Flat earth.

Yep, you sound very rude indeed here.

But extracting the substance from that paragraph, what exactly do you
find so outrageous in what I wrote?  It's almost like we're talking at
cross purposes, using the same words to mean different things.

When I say "ease of use", I usually contrast it with "ease of learning".
Emacs is very easy to use, but very hard to learn.  By easy to use, I
mean that (i) typical actions need few key presses to activate them; (ii)
Emacs doesn't get in your way: it doesn't obscure your text with annoying
dialogue boxes, it doesn't pester you with silly "are you sure?" prompts,
and, in the main, doesn't have precarious state which you could destroy
by an accidental keypress.

I think you mean something different by "usability", and I'd be
interested in hearing you say what you mean.

> Step outside of your cave. Go ask a librarian, or someone in Apple or
> Microsoft who works or research on UI, or even try to consult academic
> professors...

Maybe you could suggest a few URLs for me.  But one thing's clear:
different people work best with different tools, sometimes radically
different.

[ .... ]

> > > You suggested few times about how i should code elisp in some way
> > > and submit the patch. Perhaps, let me suggest to you, that you
> > > should try to take what code i have, polish it, and start a
> > > discussion in emacs dev lisp, and send the patch into GNU emacs.

> > OK, just stop right there.  That's just not the way Emacs develpment
> > works.  If you want to promote a new feature, you have to do the work
> > yourself.  Even on the developers' mailing list, if you put an idea
> > forward, no matter who you are, nobody else is going to take it up
> > and do the work for you.  You might ask people to criticise the idea
> > in advance (like you are doing at the moment) and incorporate their
> > ideas.  You then implement the idea as a patch, and then ask people
> > to try it out.  Then the real criticism starts.  And that criticism
> > can be robust indeed.

> ... here we venture into the problem of Open Source... see above i
> already give some pointers on the issue. In commercial softs, you have
> a goal, and how your app will be are based on facts and professional
> experts works on it with their daily bread at stake. In Open Source,
> joe moron has the final word, or else, start your own!

No.  The project's maintainers (Stefan Monnier and Chong Yidong) have the
final say.  I've not suggested you fork Emacs.  Merely that you
contribute some code.

> It is not a wonder, most Open Source software for the desktop users
> don't have any foothold on the market, even though $free$ as cig given
> to children.

Neither does most commercial software, for that matter.  For several
types of software (software development, networking, servers, ....), free
software is prominent or dominates, whereas in others (games ...) it's
hardly there at all.

> This does not mean open source softs has to be stupid. Little
> thinking, little suggestion, and a whole lot of copying of commercial
> apps helps (such as linuxes copying almost entire Microsoft Window
> UI). Emacs copied a whole lot from the commercial Xemacs (Lucid Emacs)
> from about 1990 to 2004. Open source softs do improve slowly (e.g. CUA
> mode).

Just to clarify, Lucid Emacs was always free software.  It had a
commercial sponsor for some time, like (e.g.) Apache does today.

> you want emacs to improve? think more, and get away from tech geeker
> mindset.

How so?  Emacs is intended for the "tech geeker mindset".  How will
getting away from this help emacs improve?

> Go to college and study more about humanities. Your thoughts on
> software will improve far more than decades of tech geeking and
> slashdot.

No thanks!  I graduated from university some considerable time ago, and
I'm not going back for another stint.

[ .... ]

> > A small tip: using swear words doesn't help you get your message
> > across.  It really doesn't.

> That depends. In fact, a lot people swore or worse, .....

I wasn't trying to start a philosophical discussion here.  I was telling
you that if you swear and curse on this sort of newsgroup/mailing list,
you will offend people (who will thus ignore you) and others won't take
you seriously.  I am trying to help you communicate better.

[ .... ]

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).