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

[Kevin Rodgers <kevin.d.rodgers@gmail.com>]

Xah Lee wrote:
> On Sep 24, 12:54 am, Kevin Rodgers <kevin.d.rodg...@gmail.com>
>> Here's my attempt at critical thinking:
>>
>> 1. You said that find-file and switch-to-buffer each have problems, so I
>> wrote a new command that has neither problem.  That is called a
>> solution.
> 
> Yes.
> 
>> 2. You said that neither function is designed for creating a new
>> temporary buffer.  That is true of find-file, which can create a new
>> buffer, but a buffer whose contents are to be persisted i.e. not
>> temporary.  I think switch-to-buffer _is_ designed for creating a new
>> temporary buffer, just a buffer that has a user-specified name.
> 
> this i don't  agree. Quote from my article:
> 
> «
>     * 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.

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

>     * A scratch pad can be very useful not just for temporary elisp
> code but for any scratch notes or programing in other languages. (For
> example, well known programer Stevey Yegg in his popular Effective
> Emacs↗ blog list it as a top 10 tip in emacs productivity.) Emacs's
> “*scratch*” buffer is narrowly geared for elisp editing only,
> defaulting to emacs-lisp-mode.

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

>     * Emacs does not provide a user level function to create a new
> buffer. It has menu “File‣Open file...” (a wrapper to the find-file
> command), which immediately prompt user for a full file path. This is
> annoying. Modern apps's New File command actually just create a new
> untitled file without prompting, and only when user save it it prompt
> a file name. If user closes it, it prompts for saving.
> »

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.

> More specifically, in different wording now: the problem with switch-
> to-buffer for creating new buffer is that it is simply not designed
> for it. It is only a side effect. (similar to, say, the unix “touch”
> command is used to create new file, and unix “mv” command is used for
> renaming, and in unix the boulean operators for “and” (&&) and
> “or” (||) are used for program flow... and quite a lot such quirks in
> various langs.) Sure, it you can use a hammer as a weapon and various
> things but not the right design for something is a problem. More
> specifically:
> 
> • switch-to-buffer the name does not convey it's use as a create-new-
> buffer.
> 
> • By using it for the purpose of creating new buffer and as well as
> switching buffer, it has multiple purposes. Thes 2 purpsose are
> semantically distinct and in practice doesn't mix.
> 
> • when user uses switch-to-buffer for creating new buffer, it again,
> just like find-file, promp user to type a name. Also, user needs to
> give a name not one of existing buffers. The problem with trivial
> prompting is well know is UI, especiall its problems can be seen in
> Microsoft Windows OS, where every minute it prompts users for this or
> that which is quite annoying. A better way, to let user decided to
> name something when user needs to.

So: Don't use switch-to-buffer.  Use something else.  Lobby the
Emacs maintainers to include that something else.  Argue the case
for that something else based on your actual usage, not speculation
about what makes Emacs easy/hard/intuitive/nonintuitive for others.

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

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

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

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

> For example, if i think modernization of emacs means making it behave
> like Microsoft apps, then i would have suggest using popup dialogs and
> get rid of scratch buffer, using XML instead of elisp for user prefs,
> using standard menu instead of the emacs's ones, get rid of dired, use
> standard Microsoft help app and format instead of C-h and info,
> possibly incorporate pop langs such as VisualBasic and replace elisp.

Yes, we're waiting for those suggestions from you next.  :-)

> The modernization i proposed, is intended to make emacs more
> efficient, powerful, and get rid of its primary criticism of usability
> problem. I believe, my propose solve the problem well, is quite
> conservative, is simple to implement, having no major change to emacs
> ways and consistency. ( Please give it a thought: http://xahlee.org/emacs/modernization.html
> )

I do not see how this single user command affects Emacs' efficiency,
power, or usability.  Your proposal is a sledgehammer that impacts all
users, when all that is needed to address *your* criticism is a new
command that behaves the way *you* want it to.

-- 
Kevin Rodgers
Denver, Colorado, USA