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: Xah Lee
Subject: Re: How to get rid of *GNU Emacs* buffer on start-up?
Date: Thu, 18 Sep 2008 21:49:43 -0700 (PDT)
User-agent: G2/1.0

When you keep a open mind and read into what i wrote, i think you'll
find that the suggestion is technical superior in everyway. You just
need to keep a open mind.

On Sep 18, 5:39 pm, tyler <tyler.sm...@mail.mcgill.ca> wrote:
> XahLee<x...@xahlee.org> writes:
> > «I think the existance of the lisp scratch buffer is one of the major
> > usability problem of emacs that prevents emacs from being widely
> > adopted by most text editing audience.»
>
> Ironically, I just used the scratch buffer as the repository for the
> text of your previous message. rot13-region doesn't work in the
> read-only gnus buffers, so I needed to transfer it to a different
> buffer.

You don't particularly need emacs *scratch* for that.

Imagine in NewEmacs, you just press Ctrl+n, then bang, you do exactly
the same thing. It is operatively easier then switching to *scratch*,
it is also easier on the mind because user don't have to remember
about some special *scratch*. It is simply a new buffer.

> I didn't need the scratch buffer to do this, as I could have used a
> temporary file (see below). But I think the scratch buffer does serve a
> valid purpose that warrants it's inclusion by default. In my opinion the
> one design feature that underlies Emacs success is the complete
> rejection of the distinction between user and developer. The scratch
> buffer is an extension of this mindset. Emacs assumes that everyone who
> uses it has a vested interest in understanding, exploring, and tweaking
> the code, so it is natural to provide the scratch buffer to enable and
> encourage this.

Imagine in NewEmacs, it also extending user's mindset exactly like
emacs, except it's even more easier to use, faster to execute, simpler
to operate, while having no comparative disadvantage.

> > Emacs does not provide a user level function to create a new buffer.
> > It has just New, which actually creates a empty file. Most apps's New
> > command does not work like that. They actually just create a new
> > buffer, and only when user save it it becomes a file.
>
> You are mistaken. I don't know what 'New' is in Emacs,

It is a menu command. I should've written “New Buffer”, but now the
whole polished article is here:

See here:
http://xahlee.org/emacs/modernization_scratch_buffer.html


> but find-file,
> when asked to find a file which does not already exist, creates a new
> buffer that is not associated with a file _unless_ it is saved.

As i detailed in the above article, find-file command has a few
problems. It immediately prompt user for a file name in some existing
dir. This is annoying and basically makes the command unfit for the
purpose of creating a new buffer.

The other common way, is by switching to a new buffer and type a name
not used by existing buffers. This method is also unfit as i detailed,
because it is somewhat obsure, and emacs doesn't prompt user to save
the buffer when user closes it.

> I
> regularly use this feature to create temporary files, which I may decide
> to save or not as I require. One of the advantages of this approach is
> that you can choose the mode for the temporary file by giving it an
> appropriate extension. If I need a buffer to work out some throw-away R
> code, I can open asdf.R, run the code, and delete the buffer.

the advantage you discussed above is a side effect. If it is a good
idea, in NewEmacs it can also be made so that user can call a command
something like switch-to-mode-by-file-extension and simply type file
name extensions to switch to the right mode.

  Xah
∑ http://xahlee.org/

reply via email to

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