help-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Alan Mackenzie
Subject: Re: How to get rid of *GNU Emacs* buffer on start-up?
Date: Sat, 20 Sep 2008 08:17:34 +0000
User-agent: Mutt/1.5.9i

'Morning, Xah!

On Fri, Sep 19, 2008 at 05:50:38PM -0700, Xah Lee wrote:
> On Sep 19, 1:36 pm, Alan Mackenzie <address@hidden> wrote:
> > It is necessary to have _some_ buffer when starting Emacs.

> Not really. If you look at most apps, they provide either untitle or
> empty page, and has user pref to set whether to do that or just have
> nothing.

There is no nothing.  Something must appear on the screen, even if it's
only blank space.  In Emacs, that something is a buffer, even if it's
empty.  From a pragmatic point of view, to change Emacs to be able to
have no buffer would be a massive amount of work for negligible gain -
people use Emacs to edit things, not to look at nothing.

> Even so, you don't need *scratch*. You can just have ???untitled???.

I think all those question marks would confuse people.  Anyhow, "scratch"
is easier and quicker to say.  And in a niche market, a *scratch* is
what's wanted.  ;-)

> > I don't know where you get your figure of 99% from.

> It is a ballpark estimate.

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

> Sad to say, but my experiences tells me that tech geekers (you being
> one good example), .....

Hey, thanks!

> lack any basic knowledge of social things that are generally classified
> under social science.

You might be surprised.

> To answer your question or help you think more specifically, you can
> actually try to spend 1 hour thinking about this specific issue. Start
> with, for example, how many people in the world actually code elisp.
> What's the percentage with respect to programers. What's the percentage
> with respect to all IT professionals. (look up definition or ask a
> professor in social science department on what is meant by ???IT
> professional???) Also, think about what emacs is supposed to be, and
> think about its relation to writers. Think about how many writers are
> there in the world, what's their percentage with respect to, say,
> programers.

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

> Perhaps the concept of thinking for one hour on academic subject is
> something you've never done.

Hahahaha!  That's so funny it's not even an insult.

> > Even when it [the *scratch* buffer] is not used, it's not that big a
> > nuisance.

> To you, a emacs tech geeker, doesn't seems a nuisance. To your grandma,
> or even most professional, or another tech geeker of the vi faction, it
> stops them using emacs.

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.

[ .... ]

> > 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 address@hidden  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.

> To illustrate (1), for example, suppose you say that fucking in the
> ass is not moral and government should ban it. Then someone says why
> don't you stop fucking in the ass yourself.

> To illustrate (2), suppose you say that fucking in the ass should be
> better done with lubes first. Then someone says why don't you try to
> fuck in the ass with butter.

Er, somebody elsewhere in the thread said the issue wasn't fucking, so in
deference to him, I won't answer this bit.

> > [ .... ]

> > > Proposed Fix
> > > I propose that emacs should also add a menu command ?New buffer?,
> > > with the keyboard shortcut ?Ctrl+n?. Once called, it should create
> > > a scratch buffer titled ?untitled?. If one already exists, append
> > > numbers such ?untitled 2?. Here are the reasons:

> Yes, thanks. Yesterday, i have done more polishing on the article
> ( http://xahlee.org/emacs/modernization_scratch_buffer.html )

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.

> > > * 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.  ;-)

> > > * 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.

> > >    * The name ?untitled? is conventional, far more widely understood,
> > > and more general than ?scratch?.

> > A mere unimportant trifle.

> it's not umimportant trifle. Familiarity is important aspect of
> software usability.

OK, let me put it this way.  Of all the things which an Emacs newbie will
find unfamiliar, this is amongst the least important.

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.

> > >    * For those who uses scratch buffer for elisp coding, she can set
> > > the default mode for untitled buffer to emacs lisp mode.

> > Or, more precisely, Lisp Interaction Mode.

> you are right. Thanks for correction.

> > But this option exists
> > already: `initial-major-mode'.

> Yes, but what's your point?

You seemed to be arguing for a feature which already exists, suggesting
you were unaware of it.  I was making sure you found out about it.

> Thanks for your feedback.

No problem!

> 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.

I'm afraid I won't be helping you with your code.  I don't agree that
your suggestions are good ones.  Even if I did, I still wouldn't be
offering the help you want, because I've got too many things of my own to
do.  However, even though I don't like your changes, I do support your
right to promote them.

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

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).




reply via email to

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