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

[Xah Lee]

On Sep 19, 1:36 pm, Alan Mackenzie <a...@colin2.muc.de> 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.

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

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

It is a ballpark estimate. Sad to say, but my experiences tells me
that tech geekers (you being one good example), lack any basic
knowledge of social things that are generally classified under social
science. Maybe u too old to do so, but you might want to take a few
courses under social science heading in college, like history,
psychology, philosophy, letters. Or, u can read some text books n u
can buy them online at amazon.com or browse used books store. Esp the
older editions, are just few dollars.

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.

Perhaps the concept of thinking for one hour on academic subject is
something you've never done. That's ok. I can suggest that instead of
just philosophizing on it, you could instead do a activity approach.
Try to go to library or online and find statistics about these issues.
Alternatively, if u have a lot money, you can pay research firms that
answer these questions for you. Typically, big corps like Microsoft
and Apple spend, i dunno, hundreds of thousands dollars on it yearly.

> Even when it 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.

> >    * The ?*scratch*? ?buffer? is primarily designed for elisp
> > programers. (it defaults to lisp mode) Majority of people who use
> > emacs are not lisp coders. For lisp coders, they can easily customize
> > their emacs to have a ?*scratch*? ?buffer?.
>
> It's designed for any rough notes, including bits of Lisp.  The only
> thing here I found bothersome was having C-j bound to
> `eval-print-last-sexp', but I just rebound it to `newline-and-indent'.
>
> >    * The ?*scratch*? ?buffer? is a intrusive idiosyncrasy. It is
> > persistent, cannot be closed (it regenerates). It is foreign to all
> > programers. This idiosyncrasy is the first thing presented to users,
> > and it persists.
>
> 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.

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.

> [ .... ]
>
> > 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:
>
> As you know very well, there's already an important binding for C-n.

Yes, thanks. Yesterday, i have done more polishing on the article
( http://xahlee.org/emacs/modernization_scratch_buffer.html ) Among
the editing is a addition about the shortcut. Quote:

«Note: the proposed keybinding “Ctrl+n” and “Ctrl+w” need not be part
of this proposal because emacs already use “Ctrl+n” and “Ctrl+w” for
basic cursor movement and cut. However, it could be adapted in
conjunction with newly designed Ergonomic Keybinding. (see below)»

> >    * The New command is a standard across Mac, Windows, Unix (Linux).
> > It is familiar to all software users.
>
> However, in Emacs, which uses many more key bindings than just about any
> other program, such a prime binding can't be spared for a command used
> only sporadically.  Of course, anybody who wants to rebind it is welcome.

For keybinding issues on this, see the above paragraph.

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

> >    * A New Buffer command (where the corresponding elisp command name
> > might will be named new-empty-buffer), can supplant completely the
> > functionality of *scratch* buffer.
>
> This exists already: C-x b <new-name>. I suggest you hack
> `switch-to-buffer', possibly using advice at first, so that a C-u prefix
> would cause it to create this new buffer.

I suggest you enhance your critical thinking skills. You can start by
reading Wikipedia here:
 http://en.wikipedia.org/wiki/Critical_thinking

> >    * When users want to have a scratch buffer, he can create it by
> > simply pressing the shortcut, and when he doesn't want it, he can
> > simply close it with a standard keystroke Ctrl+w.
>
> <sigh>.  Yet again, a prime binding like C-w can't be spared for such a
> minor command.  As you know, C-w is bound to `kill-region'.

See above.

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

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

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

> >    * Adopting the suggestion would fix several problems for those who
> > actually use emacs's scratch buffer. (1) emacs no longer mysteriously
> > respawn the ?*scratch*? buffer when user didn't want it. (2) user can
> > create multiple scratch buffers by just pressing a shortcut. (3) User
> > can close a scratch buffer and emacs will ask the user if she wants to
> > save it.
> > Draft Implementation
> > The above suggestion is experimentally implemented in my Ergonomic
> > Keyboard Shortcut Layout For Emacs.
>
> Just as a suggestion, this seems silly.  Creating buffers has nothing to
> do with keyboard layouts.  Why not separate out the functionality?

Thanks for your feedback.

I do not mean they should be the final form. That's why i said it's
experimental draft implementation. I started with elisp code for
ergonomic keybindings, then my studies lead me to find minor
improvements on text manipulating functions and other things such as
keybindings for common operations such as Open, Close, Save, and among
things is the discovery of emacs problems in creatig new empty buffer,
closing unsaved buffer with potential data lose, etc. Long story
short, it leads to a solution to the *scratch* and i have implemented
that doesn't have much to do with ergonomic keybindings.

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.

  Xah
∑ http://xahlee.org/

☄