From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Lee Newsgroups: gmane.emacs.help Subject: Re: How to get rid of *GNU Emacs* buffer on start-up? Date: Thu, 18 Sep 2008 21:49:43 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <873ajzwoqu.fsf@kobe.laptop> <9bceaf08-4a29-4593-be31-13e3b459763d@i20g2000prf.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1221802864 32162 80.91.229.12 (19 Sep 2008 05:41:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2008 05:41:04 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Sep 19 07:42:00 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KgYkh-0006XE-Lz for geh-help-gnu-emacs@m.gmane.org; Fri, 19 Sep 2008 07:42:00 +0200 Original-Received: from localhost ([127.0.0.1]:50545 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KgYjf-0003wr-46 for geh-help-gnu-emacs@m.gmane.org; Fri, 19 Sep 2008 01:40:55 -0400 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!n33g2000pri.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 83 Original-NNTP-Posting-Host: 24.6.185.159 Original-X-Trace: posting.google.com 1221799783 31628 127.0.0.1 (19 Sep 2008 04:49:43 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Fri, 19 Sep 2008 04:49:43 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: n33g2000pri.googlegroups.com; posting-host=24.6.185.159; posting-account=qPxGtQkAAADb6PWdLGiWVucht1ZDR6fn User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.22, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:162440 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:57783 Archived-At: 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 wrote: > XahLee writes: > > =C2=ABI think the existance of the lisp scratch buffer is one of the ma= jor > > usability problem of emacs that prevents emacs from being widely > > adopted by most text editing audience.=C2=BB > > 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 =E2=80=9CNew Buffer=E2=80=9D, 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 =E2=88=91 http://xahlee.org/ =E2=98=84