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

1928 views
Skip to first unread message

Davin Pearson

unread,
Sep 16, 2008, 1:28:29 AM9/16/08
to
Every time I start Emacs I have to bury to *GNU Emacs" buffer. This
is a little bit annoying having to do this. If I can't kill this
buffer, then I would at least prefer the default-directory of that
buffer to be "~/" so that I can easily load a file that I want to
edit. The following code is what I have written to accomplish that
task but sadly it doesn't appear to work.

(defun d-emacs-startup-hook
()
(if (get-buffer "*GNU
Emacs*")
(save-
excursion
(set-buffer "*GNU
Emacs*")
(setq default-directory
"~/")))

(defun d-emacs-startup-hook
()
(if (get-buffer "*GNU
Emacs*")
(kill-buffer "*GNU
Emacs*")))
)

Giorgos Keramidas

unread,
Sep 16, 2008, 3:39:40 AM9/16/08
to
On Mon, 15 Sep 2008 22:28:29 -0700 (PDT), Davin Pearson <davin....@gmail.com> wrote:
> Every time I start Emacs I have to bury to *GNU Emacs" buffer. This
> is a little bit annoying having to do this.

Try setting:

inhibit-startup-screen => t
inhibit-splash-screen => t

For more details, look at the documentation of these variables with:

C-h v inhibit-startup-screen RET
C-h v inhibit-splash-screen RET

Adam Rooke

unread,
Sep 16, 2008, 4:14:52 AM9/16/08
to help-gn...@gnu.org
I think this line of code will stop the start screen from appearing:
(setq inhibit-start-screen 1)

Documentation:
Non-nil inhibits the startup screen.

This is for use in your personal init file (but NOT site-start.el), once
you are familiar with the contents of the startup screen.

Nikolaj Schumacher

unread,
Sep 16, 2008, 4:44:08 AM9/16/08
to Davin Pearson, help-gn...@gnu.org
Davin Pearson <davin....@gmail.com> wrote:

> I would at least prefer the default-directory of that buffer to be
> "~/" so that I can easily load a file that I want to edit.

Did you know that you can just type ~/ when opening a file and the
default input will disappear?

regards,
Nikolaj Schumacher


Charles Sebold

unread,
Sep 16, 2008, 4:44:52 AM9/16/08
to
On 16 Sep 2008, Davin Pearson wrote:

> Every time I start Emacs I have to bury to *GNU Emacs" buffer. This
> is a little bit annoying having to do this. If I can't kill this
> buffer, then I would at least prefer the default-directory of that
> buffer to be "~/" so that I can easily load a file that I want to
> edit. The following code is what I have written to accomplish that
> task but sadly it doesn't appear to work.

In addition to everything else that's been said, I've noticed that
hitting "q" deletes the buffer and sends me to the good old *scratch*
buffer, too. I just got used to doing that.
--
Charles Sebold 16th of September, 2008

Davin Pearson

unread,
Sep 16, 2008, 4:47:23 AM9/16/08
to
On Sep 16, 7:39 pm, Giorgos Keramidas <keram...@ceid.upatras.gr>
wrote:

> Try setting:
>
>     inhibit-startup-screen  => t
>     inhibit-splash-screen   => t
>

It Works! Thank you for your help!

Xah

unread,
Sep 16, 2008, 4:57:59 PM9/16/08
to

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.

I wrote some detail about it here:
http://xahlee.org/emacs/modernization.html

I think emacs should get rid of the lisp scratch buffer completely.
Instead, have Ctrl+n for New File, that creates a new buffer named
“untitled” and default to text mode. The default mode can be
customized to set to lisp mode for those who wishes of course.

following is a excerpt
--------------------------

Q: I find the “*scratch*” buffer useful...

A: Just about anything, once it is exposed to human animals, a
significant number will find it useful. This is a matter of habit and
conditioning and applies to all aspects of human habit or behavior, as
you'll find people in cultures into things you couldn't dream of.
(such as body modification as flattening their breasts, widening a
hole in lower lips... to lesser degree tattoo, muscle bulking... or
sexual preferences and fetishes such as shit-eating... , or food
intake habits (eating/drinking/diet habits) ...)

Suppose you have random features in a software, and give this software
to a large number of people to use for few decades. Chances are, every
feature will be useful to a good sized number of people. People, in a
sense, adapt their work habits to the features.

The issue about emacs's “*scratch*” “buffer” is that:

* It is not useful by 99% of letter writers. If they wanted a
scratch pad, they can open a new document and not save it. This way is
familiar to all software users.
* 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”.
* 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.

---------------------------------------------

I have made a implementation of my suggestion solution. It will be
incorporated into my ergonomic keybinding in the next version.

Here's the basics:

(global-set-key (kbd "C-n") 'new-empty-buffer) ; Open New File

(defun new-empty-buffer ()
"Opens a new empty buffer."
(interactive)
(let ((buf (generate-new-buffer "untitled")))
(switch-to-buffer buf)
(funcall (and initial-major-mode))
(setq buffer-offer-save t)))
;; note: emacs won't offer to save a buffer that's
;; not associated with a file,
;; even if buffer-modified-p is true.
;; One work around is to define your own my-kill-buffer function
;; that wraps around kill-buffer, and check on the buffer modification
;; status to offer save
;; This custome kill buffer is close-current-buffer.

For the command close-current-buffer, see:
http://xahlee.org/emacs/modern_operations.el

Xah
http://xahlee.org/


Giorgos Keramidas

unread,
Sep 16, 2008, 9:22:01 PM9/16/08
to
On Tue, 16 Sep 2008 13:57:59 -0700 (PDT), Xah <xah...@gmail.com> wrote:
> On Sep 16, 1:44 am, Charles Sebold <cseb...@gmail.com> wrote:
>> In addition to everything else that's been said, I've noticed that
>> hitting "q" deletes the buffer and sends me to the good old *scratch*
>> buffer, too. I just got used to doing that.
>
> 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.

Hi Xah,

For what it's worth, I think I would appreciate an option that makes the
current behavior of the *scratch* buffer tunable, i.e. by an option like:

(defvar scratch-buffer-uses-fundamental-mode nil
"Non-nil makes the *scratch* buffer use `fundamental-mode'.

Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
If you are not really interested to use `lisp-interaction-mode',
but you would prefer to start all scratch buffers in
`fundamental-mode', to start editing text instead of typing Lisp
expressions, set the `scratch-buffer-uses-fundamental-mode'
variable to a non-nil value.")

> I wrote some detail about it here:
> http://xahlee.org/emacs/modernization.html

But I don't like the `personal attack' style that this text uses, and I
don't really agree with *all* the proposed `modernization' features.

If you were to split that document into smaller `features' and one of
them was a proposal to add an option for the default mode of *scratch*
buffers, and a good description of how you would suggest that we add a
prompt for *scratch* buffers that are modified, I would be more than
willing to help you with the testing and integration of any patches to
the main Emacs source tree.

My own idea about *scratch* buffers that do not fire up only in the
current `lisp-interaction-mode' state is something like:

* Add an option that may be set to a non-nil value to make *scratch*
buffers use `fundamental-mode', or even better, an option that
defines _which_ mode a *startup* buffer should use.

Two possible variations of this option would be:

;;; Boolean option
;; A boolean option that makes *scratch* buffers fire up in
;; `fundamental-mode' by default. The option would be set to `nil'
;; by default, but it should be easy to tweak the option once and
;; keep it set forever.

(defcustom scratch-buffer-uses-fundamental-mode nil
"Non-nil makes the *scratch* buffer use `fundamental-mode'.

Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
If you are not really interested to use `lisp-interaction-mode',
but you would prefer to start all scratch buffers in
`fundamental-mode', to start editing text instead of typing Lisp
expressions, set the `scratch-buffer-uses-fundamental-mode'
variable to a non-nil value."
:type 'boolean
:group 'editing-basics
:group 'convenience)

;;; A list of choices.
;; Still set to the default `lisp-interaction-mode'
(defcustom scratch-buffer-startup-mode 'lisp-interaction-mode
"The default mode to use for *scratch* buffers.

If the value is `lisp' start in lisp-interaction-mode.
If the value is `text' start in text-mode.
If the value is `fundamental' start in whatever mode has been
configured as the default `fundamental-mode'.
If the value is a function, use that function to set-up the
startup mode of *scratch* buffers."
:type '(choice (const :tag "Lisp interaction mode" 'lisp)
(const :tag "Text mode" 'text)
(const :tag "Fundamental mode" 'fundamental)
(function :tag "Custom mode"))
:group 'editing-basics
:group 'convenience)

* Add the scratch buffer to the list of buffers that trigger a prompt
if they are modified and the user types `C-x C-c' to leave Emacs.

Right now one can open _one_ scratch buffer only. Emacs uses
`buffer-modified-p' as the only criterion, but this doesn't work for
scratch buffers now. It should probably be an option too, or even a
function that checks `scratch-buffer-startup-mode' and decides. I
haven't thought too much about this yet, so I am not sure if it
sounds like a sensible thing to do.

Kevin Rodgers

unread,
Sep 17, 2008, 3:36:56 AM9/17/08
to help-gn...@gnu.org
Xah wrote:
> 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.

I think you should customize Emacs to behave as you want and not presume
to speak for most text editing audience:

,----[ C-h v initial-major-mode RET ]
| initial-major-mode is a variable defined in `startup.el'.
| Its value is
| lisp-interaction-mode
|
|
| Documentation:
| Major mode command symbol to use for the initial `*scratch*' buffer.
|
| You can customize this variable.
|
| [back]
`----

--
Kevin Rodgers
Denver, Colorado, USA

Xah

unread,
Sep 17, 2008, 7:16:44 PM9/17/08
to
On Sep 17, 12:36 am, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> Xahwrote:

> > 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.
>
> I think you should customize Emacs to behave as you want and not presume
> to speak for most text editing audience:

i was making a suggestion. As such, its premise is that the suggested
idea is good for general audience.

perhaps you thought that my suggestion actually is not reasonable and
is more like a one person's preference. If so, please give reasons.

Xah
http://xahlee.org/


Xah Lee

unread,
Sep 18, 2008, 1:35:34 AM9/18/08
to
Knu jebgr:
«V guvax gur rkvfgnapr bs gur yvfc fpengpu ohssre vf bar bs gur znwbe
hfnovyvgl ceboyrz bs rznpf gung ceriragf rznpf sebz orvat jvqryl
nqbcgrq ol zbfg grkg rqvgvat nhqvrapr.»

Tvbetbf Xrenzvqnf jebgr:
> Uv Knu ,
>
> Sbe jung vg'f jbegu, V guvax V jbhyq nccerpvngr na bcgvba gung znxrf gur
> pheerag orunivbe bs gur *fpengpu* ohssre ghanoyr, v.r. ol na bcgvba yvxr:
>
> (qrsine fpengpu-ohssre-hfrf-shaqnzragny-zbqr avy
> "Aba-avy znxrf gur *fpengpu* ohssre hfr `shaqnzragny-zbqr'.
>
> Rznpf erperngrf gur *fpengpu* ohssre va `yvfc-vagrenpgvba-zbqr'.
> Vs lbh ner abg ernyyl vagrerfgrq gb hfr `yvfc-vagrenpgvba-zbqr',
> ohg lbh jbhyq cersre gb fgneg nyy fpengpu ohssref va
> `shaqnzragny-zbqr', gb fgneg rqvgvat grkg vafgrnq bs glcvat Yvfc
> rkcerffvbaf, frg gur `fpengpu-ohssre-hfrf-shaqnzragny-zbqr'
> inevnoyr gb n aba-avy inyhr.")

ol univat n Arj pbzznaq jvgu Pgey+a xrl, vg fbyirf guvf ceboyrz jvgu
fpengpu cyhf jung lbh jnag.

• Gur Arj pbzznaq vf n fgnaqneq npebff Znp, Jvaqbjf, Havk (Yvahk). Vg
vf snzvyvne gb nyy fbsgjner hfref.

• Gur Pgey+a fubegphg sbe Arj vf fgnaqneq naq snzvyvne gb nyy fbsgjner
hfref.

• Gur Arj pbzzznaq (jurer gur pbeerfcbaqvat ryvfc pbzznaq anzr zvtug
jvyy or anzrq arj-rzcgl-ohssre), pna fhccynag pbzcyrgryl gur
shapgvbanyvgl bs *fpengpu* ohssre.

• Jura hfref jnag gb unir n fpengpu ohssre, ur pna perngr vg ol fvzcyl
cerffvat gur fubegphg, naq jura ur qbrfa'g jnag vg, ur pna fvzcyl
pybfr vg jvgu n fgnaqneq xrlfgebxr Pgey+j.

• Hfref pna unir zhygvcyr *fpengpu* ohssref rnfvyl jvgubhg gur arrq gb
ybbx vagb rznpf qbp.

• Gur “*fpengpu*” anzr vf abg va fbzr grpuavpny wnetba frafr gur orfg
bar. “*hagvgyrq*” be “hagvgyrq” vf n orggre bar, naq jvqryl hfrq
npebff fbzr 99% bs BFrf naq nccyvpngvbaf. Gur anzr “*fpengpu*” vf
haarprffnevyl aneebj, nf gb vaqvpngr gung gur ohssre'f pbagrag vf bayl
sbe grzc checbfrf, juvyr “hagvgyrq” pna vapyhqr gur checbfr bs
fpengpu, naq pna or qvfpneqrq whfg nf “*fpengpu*”.

• Gur erfcnjavat bs “*fpengpu*” ohssre orunivbe vf hahfhny, nyzbfg
havdhr gb rznpf nzbat gur gubhfnaqf bs nccyvpngvba gbqnl. Yrggvat hfre
unir pbageby gb perngr naq naq qvfpneq fhpu ohssre vf orggre.

• Gur “*fpengpu*” ohssre vf cevznevyl hfrq ol ryvfc cebtenzref. Srj
cebsrffvbany cebtenzref va gur VG vaqhfgel xabjf nobhg yvfc, naq bayl
zvabe crepragntr bs rznpf hfref npghnyyl pbqr rznpf yvfc.

> > V jebgr fbzr qrgnvy nobhg vg urer:
> > uggc://knuyrr.bet/rznpf/zbqreavmngvba.ugzy
>
> Ohg V qba'g yvxr gur `crefbany nggnpx' fglyr gung guvf grkg hfrf, naq V
> qba'g ernyyl nterr jvgu *nyy* gur cebcbfrq `zbqreavmngvba' srngherf.

Gur Zbqreavmngvba bs Rznpf negvpyr ng
uggc://knuyrr.bet/rznpf/zbqreavmngvba.ugzy
qbrf abg unir nal “crefbany nggnpx” jevgvat fglyr. Creuncf lbh jrer
guvaxvat zl bgure arjftebhc cbfgf ryfrjurer jurer guvf vffhr vf
qvfphffrq.

> V qba'g ernyyl nterr jvgu *nyy* gur cebcbfrq `zbqreavmngvba'
> srngherf.

Vs lbh nterr gb fbzr, cyrnfr svyr n oht ercbeg, be uryc fcernq gur
vqrn. Gunaxf sbe qvfphffvat guvf vffhr jvgu zr.

> Vs lbh jrer gb fcyvg gung qbphzrag vagb fznyyre `srngherf' naq bar bs
> gurz jnf n cebcbfny gb nqq na bcgvba sbe gur qrsnhyg zbqr bs *fpengpu*
> ohssref, naq n tbbq qrfpevcgvba bs ubj lbh jbhyq fhttrfg gung jr nqq n
> cebzcg sbe *fpengpu* ohssref gung ner zbqvsvrq, V jbhyq or zber guna
> jvyyvat gb uryc lbh jvgu gur grfgvat naq vagrtengvba bs nal cngpurf gb
> gur znva Rznpf fbhepr gerr.
>
> Zl bja vqrn nobhg *fpengpu* ohssref gung qb abg sver hc bayl va gur
> pheerag `yvfc-vagrenpgvba-zbqr' fgngr vf fbzrguvat yvxr:
>
> * Nqq na bcgvba gung znl or frg gb n aba-avy inyhr gb znxr *fpengpu*
> ohssref hfr `shaqnzragny-zbqr', be rira orggre, na bcgvba gung
> qrsvarf _juvpu_ zbqr n *fgneghc* ohssre fubhyq hfr.
>
> Gjb cbffvoyr inevngvbaf bs guvf bcgvba jbhyq or:
>
> ;;; Obbyrna bcgvba
> ;; N obbyrna bcgvba gung znxrf *fpengpu* ohssref sver hc va
> ;; `shaqnzragny-zbqr' ol qrsnhyg. Gur bcgvba jbhyq or frg gb `avy'
> ;; ol qrsnhyg, ohg vg fubhyq or rnfl gb gjrnx gur bcgvba bapr naq
> ;; xrrc vg frg sberire.
>
> (qrsphfgbz fpengpu-ohssre-hfrf-shaqnzragny-zbqr avy
> "Aba-avy znxrf gur *fpengpu* ohssre hfr `shaqnzragny-zbqr'.
>
> Rznpf erperngrf gur *fpengpu* ohssre va `yvfc-vagrenpgvba-zbqr'.
> Vs lbh ner abg ernyyl vagrerfgrq gb hfr `yvfc-vagrenpgvba-zbqr',
> ohg lbh jbhyq cersre gb fgneg nyy fpengpu ohssref va
> `shaqnzragny-zbqr', gb fgneg rqvgvat grkg vafgrnq bs glcvat Yvfc
> rkcerffvbaf, frg gur `fpengpu-ohssre-hfrf-shaqnzragny-zbqr'
> inevnoyr gb n aba-avy inyhr."
> :glcr 'obbyrna
> :tebhc 'rqvgvat-onfvpf
> :tebhc 'pbairavrapr)
>
> ;;; N yvfg bs pubvprf.
> ;; Fgvyy frg gb gur qrsnhyg `yvfc-vagrenpgvba-zbqr'
> (qrsphfgbz fpengpu-ohssre-fgneghc-zbqr 'yvfc-vagrenpgvba-zbqr
> "Gur qrsnhyg zbqr gb hfr sbe *fpengpu* ohssref.
>
> Vs gur inyhr vf `yvfc' fgneg va yvfc-vagrenpgvba-zbqr.
> Vs gur inyhr vf `grkg' fgneg va grkg-zbqr.
> Vs gur inyhr vf `shaqnzragny' fgneg va jungrire zbqr unf orra
> pbasvtherq nf gur qrsnhyg `shaqnzragny-zbqr'.
> Vs gur inyhr vf n shapgvba, hfr gung shapgvba gb frg-hc gur
> fgneghc zbqr bs *fpengpu* ohssref."
> :glcr '(pubvpr (pbafg :gnt "Yvfc vagrenpgvba zbqr" 'yvfc)
> (pbafg :gnt "Grkg zbqr" 'grkg)
> (pbafg :gnt "Shaqnzragny zbqr" 'shaqnzragny)
> (shapgvba :gnt "Phfgbz zbqr"))
> :tebhc 'rqvgvat-onfvpf
> :tebhc 'pbairavrapr)
>
> * Nqq gur fpengpu ohssre gb gur yvfg bs ohssref gung gevttre n cebzcg
> vs gurl ner zbqvsvrq naq gur hfre glcrf `P-k P-p' gb yrnir Rznpf.
>
> Evtug abj bar pna bcra _bar_ fpengpu ohssre bayl. Rznpf hfrf
> `ohssre-zbqvsvrq-c' nf gur bayl pevgrevba, ohg guvf qbrfa'g jbex sbe
> fpengpu ohssref abj. Vg fubhyq cebonoyl or na bcgvba gbb, be rira n
> shapgvba gung purpxf `fpengpu-ohssre-fgneghc-zbqr' naq qrpvqrf. V
> unira'g gubhtug gbb zhpu nobhg guvf lrg, fb V nz abg fher vs vg
> fbhaqf yvxr n frafvoyr guvat gb qb.

V guvax lbhe zbqry pna pbzcyvpngr gur hfre vagresnpr.

N fvzcyr Arj zrah pbzznaq (perngr-rzcgl-ohssre) gung perngrf n arj
ohssre va fbzr phfgbzvmnoyr qrsnhyg zbqr, fbyirf jung lbh jnagrq naq
vg tvirf lbh rkgen cbjre.

Rznpf qbrf abg cebivqr n hfre yriry shapgvba gb perngr n arj ohssre.
Vg unf whfg Arj, juvpu npghnyyl perngrf n rzcgl svyr. Zbfg nccf'f Arj
pbzznaq qbrf abg jbex yvxr gung. Gurl npghnyyl whfg perngr n arj
ohssre, naq bayl jura hfre fnir vg vg orpbzrf n svyr.

Perngvat n arj ohssre vf npghnyyl dhvgr hfrshy. Sbe rknzcyr, jryy
xabja cebtenzre Fgrirl Lrtt va uvf “Rssrpgvir Rznpf” oybt yvfg vg nf n
gbc 10 gvc va rznpf cebqhpgvivgl. Gur rznpf zrah fubhyq unir n Arj
pbzznaq jvgu Pgey+a gung pnyyf perngr-rzcgl-ohssre.

-------------------------

CF nf v zragvbarq va cerivbhf zrffntr, v qvq vzcyrzrag gur nobir. Va
zl qensg pbqr,

• perngr-arj-ohssre jvyy perngr n arj rzcgl ohssre anzrq “hagvgyrq”.
(guvf fubhyq or nqqrq gur zrah pbzznaq haqre “Svyr‣Arj” ohg v unira'g
qbar gung lrg.)

• perngr-arj-ohssre unf fgnaqneq xrlobneq fubegphg Pgey+a.

• ryvfc pbzznaq pybfr-pheerag-ohssre jvyy pybfr gur pheerag ohssre,
naq vs vg vf n ohssre abg nffbpvngrq jvgu n svyr (fhpu nf “hagvgyrq”),
vg'yy nfx hfre gb fnir (hayrff vg unf ab pbagrag)

• pybfr-pheerag-ohssre unf gur fgnaqneq xrlobneq fubegphg Pgey+j.

• pybfr-pheerag-ohssre fubhyq unir zrah haqre “Svyr‣Pybfr”, ohg vg vf
abg pheeragyl qbar. Gur rkvfgvat “Svyr‣Pybfr” zrah pbzznaq pnyyf xvyy-
guvf-ohssre, juvpu unf 2 ceboyrzf. (1) vg qbrfa'g unir n fubegphg. (2)
vg qbrfa'g nfx hfref gb fnir n aba-svyr-nffbpvngrq ohssre ng nyy.
(guvf vf znwbe ceboyrz gung yrnqf gb ybfvat qngn; vapyhqvat
“*fpengpu*” ohssre. Gur snpg gung rznpf hfref qbag frrz gb abgvpr guvf
ceboyrz vf orpnhfr vg qbrfa'g unir n xrlobneq fubegphg, fb gung
npghnyyl abobql hfrf guvf pbzznaq. Zbfg hfr xvyy-ohssre, juvpu vf
naablvat orpnhfr vg cebzcf rira vs gur svyr vf nyernql fnirq.)

Lbh pna svaq gur pbqr sbe gur nobir vzcyrzragngvba urer:
uggc://knuyrr.bet/rznpf/zbqrea_bcrengvbaf.ry

Gur pbqr vf cenpgvpnyyl hfnoyr, fvapr v hfr vg qnvyl sbe nobhg unys n
lrne abj jvgu vaperzragny vzcebirzrag naq oht svkrf, ohg v'z fher vg
pna hfr n ybg zber cbyvfuvat sbe choyvp hfr.

Vg vf TCY'q, fb srry serr gb teno cvrprf sbe lbhe bja hfr be fhozvg
vagb TAH.

bar guvat yrnqf gb nabgure... v'z tbvat gb svyr n oht ercbeg (n
fhttrfgvba) ba gur “*fpengpu*” abj.

(sbe fbzr ernfba, tbbtyr tebhcf jba'g yrg zr cbfg guvf zrffntr... fb
v'z ercylvat ol rznvy sbe abj)

Knu
∑ uggc://knuyrr.bet/

Xah Lee

unread,
Sep 18, 2008, 1:41:47 AM9/18/08
to
On Sep 17, 10:35 pm, Xah Lee <x...@xahlee.org> wrote:
> Knu jebgr:
> «V guvax gur rkvfgnapr bs gur yvfc fpengpu ohssre vf bar bs gur znwbe
> hfnovyvgl ceboyrz bs rznpf gung ceriragf rznpf sebz orvat jvqryl
> nqbcgrq ol zbfg grkg rqvgvat nhqvrapr.»
>

...

i was quite pissed that google groups wont let me post my message.
Trying different google account, clearing cache & cookie, etc didn't
help. Even using the option Reply To Author (as private email) didn't
work. I suspect google is checking content and think it's a spam,
because there are hundreds of spams that uses my name Xah Lee or my
website XahLee.org's content.

after a day's frustration, the the above message is sent in rot13, and
indeed it went thru. Apparently google is checking message content.

Fuck google motherfucking incompetence.

Xah
http://xahlee.org/


Xah Lee

unread,
Sep 18, 2008, 7:50:50 PM9/18/08
to
My previous message (the rot13'd one), is now polished and published
on my website, at:

Suggestions on Emacs's Scratch Buffer
http://xahlee.org/emacs/modernization_scratch_buffer.html

The following is a text version.
----------------------------------

Suggestions on Emacs's Scratch Buffer

Xah Lee, 2008-09

In the article The Modernization of Emacs, i suggested that emacs's
“*scratch*” buffer be removed. In this article, we give some detail
about it.

In the article, i gave the following as primary reasons that scratch
buffer should be removed:

* It is not useful by 99% of letter writers. If they wanted a
scratch pad, they can open a new document and not save it. This way is
familiar to all software users.
* 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”.
* 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.

Here are few minor reasons:

* 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.)
* When the scratch buffer is closed, emacs does not prompt user to
save it. This easily causes data loss.
* 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.
* Emacs does not provide a user level function to create a new
buffer. It has “Open New file...”, which actually creates a empty file
and immediately prompt user for a file name. This is annoying. Most
apps's New File command actually just create a new buffer, and only
when user save it it becomes a file. When user closes it, it prompts
for saving.

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:

* The New command is a standard across Mac, Windows, Unix (Linux).
It is familiar to all software users.
* The Ctrl+n shortcut for New is standard and familiar to all
software users.
* 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.
* 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.
* By adopting the New Buffer and Ctrl+n, users can intuitively
create multiple scratch buffers for any purpose.
* The name “untitled” is conventional, far more widely understood,
and more general than “scratch”.
* For those who uses scratch buffer for elisp coding, she can set
the default mode for untitled buffer to emacs lisp mode.
* 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. The following are the elisp files,
primarily the modern_operations.el:

* ergonomic_keybinding_dvorak.el.
* ergonomic_keybinding_qwerty.el.
* modern_operations.el.

Some detail about the implementation:

* create-new-buffer will create a new empty buffer named
“untitled”. (this should be added to the menu under “File‣New Buffer”
but i haven't done that yet.)
* create-new-buffer has standard keyboard shortcut Ctrl+n.
* elisp command close-current-buffer will close the current
buffer, and if it is a buffer not associated with a file (such as
“untitled”), it'll ask user to save (unless it has no content)
* close-current-buffer has the standard keyboard shortcut Ctrl+w.
* close-current-buffer should have menu under “File‣Close”, but it
is not currently done. The existing “File‣Close” menu command in emacs
22.2 calls kill-this-buffer, which has 2 problems. (1) it doesn't have
a shortcut. (2) it doesn't ask users to save a buffer that are not
associated with file (in effect, any text in the buffer is
irreversibly lost immediately). The standard emacs command used to
close a file is kill-buffer (Ctrl+x k). It has a major problem of
prompting user even if the file is already saved.

I have been using the above code daily since late 2007, with
incremental improvement and bug fixes. i'm sure it can use a lot more
polishing for public use. The code is GPL'd, so feel free to grab
pieces for your own use or submit into GNU.

Xah
http://xahlee.org/


tyler

unread,
Sep 18, 2008, 8:39:42 PM9/18/08
to help-gn...@gnu.org
Xah Lee <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.

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.

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

Cheers,

Tyler

--
Making back-ups of your legally-purchased DVDs will be illegal under
Bill C-61.

http://www.michaelgeist.ca/content/view/3072/317/

David Kastrup

unread,
Sep 19, 2008, 12:16:51 AM9/19/08
to
tyler <tyler...@mail.mcgill.ca> writes:

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

C-c C-r works in gnus. Which does not mean that alternative ways are a
bad idea.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Xah Lee

unread,
Sep 19, 2008, 12:49:43 AM9/19/08
to
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/

Eli Zaretskii

unread,
Sep 19, 2008, 4:53:57 AM9/19/08
to help-gn...@gnu.org
> From: Xah Lee <x...@xahlee.org>
> Date: Thu, 18 Sep 2008 16:50:50 -0700 (PDT)

>
> * Emacs does not provide a user level function to create a new
> buffer. It has “Open New file...”, which actually creates a empty file
> and immediately prompt user for a file name. This is annoying.

This is incorrect. No file is created on disk until you actually save
the buffer. Until then, only a buffer is created.

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

If I ever want a Notepad, I'd just launch that. I don't need Emacs to
emulate it.

Xah Lee

unread,
Sep 19, 2008, 7:34:12 AM9/19/08
to
On Sep 19, 1:53 am, Eli Zaretskii <e...@gnu.org> wrote:
> > From: Xah Lee <x...@xahlee.org>
> > Date: Thu, 18 Sep 2008 16:50:50 -0700 (PDT)
>
> > * Emacs does not provide a user level function to create a new
> > buffer. It has “Open New file...”, which actually creates a empty file
> > and immediately prompt user for a file name. This is annoying.
>
> This is incorrect. No file is created on disk until you actually save
> the buffer. Until then, only a buffer is created.

Ok, my original phrasing is a bit off. Please focus on the main ideas.

Here's a better phrasing:

• Emacs does not provide a user level function to create a new buffer.
It has “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.

In newsgroup discussion, people tend to nick pick details and often
give no acknowledgement even if they agree in general. So, if a
criticism or idea X is posted in the thread's original post, often
there will be several responses that nick pick details that are non-
critical to the main idea. So, often, the thread becomes large and
derailed and little critical discussion.

> > 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”.
>
> If I ever want a Notepad, I'd just launch that. I don't need Emacs to
> emulate it.

The issue here is not about whether one Eli Zaretskii wants Microsoft
Notepad (assuming it is Microsoft Notepad you are talking about).
Perhaps you are using the term “Notepad” as a general concept. In that
case, emacs's *scratch* buffer is also a notepad. So, i don't know
what u mean except perhaps you are just fooling around.

Xah
http://xahlee.org/


tyler

unread,
Sep 19, 2008, 8:42:44 AM9/19/08
to help-gn...@gnu.org
David Kastrup <d...@gnu.org> writes:

That combination is not defined for me in gnus, but it did lead me to
discover toggle-rot13-mode, which I *will* now bind to C-c C-r. Thanks!

Tyler

--
Support standardized open formats and control your own data -
Reject Microsoft OOXML

http://noooxml.org

xraysm...@gmail.com

unread,
Sep 19, 2008, 9:08:47 AM9/19/08
to
Emacs provides a user level function to create a new buffer. C-x b,
and enter a name of a non-existing buffer. Not once is there a prompt
for a file-name. I find this useful as I create tens of buffers a day,
holding chunks of files I'm twiddling with, notes from phone calls,
lists of file names, etc. I don't want to save them to disk, but I
sure as heck need to give that buffer a name so I can find it back
amongst all the other things I have. And if I close it without saving,
Emacs prompts me gently -- it doesn't demand a filename, it asks if I
want to save it. And only then, if I say yes, does it prompt for a
filename. How polite.


I grew up with a "scratch-pad" next to the telephone (yeah, kids, it
had a dial), and sometimes we'd get home-made scratch-pads for
Christmas. What fun!

Cor Gest

unread,
Sep 19, 2008, 9:04:25 AM9/19/08
to
Some entity, AKA Xah Lee <x...@xahlee.org>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

> Here's a better phrasing:
>
> • Emacs does not provide a user level function to create a new buffer.
> It has “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.

Emacs _never_ 'opens' files, it merely visits them and copies its
content into a (named)-buffer.
After you are done messing with that buffer you order emacs to write the
content of the buffer to file-name to relace it and saving
the unaltered-visited-file. (you _do_ use versioning, don't you ?)
If you cannot understand this type of editing you really should
not use emacs at all and use something else.

Oh, BTW emacs really is ment for people who know what they want to do
and those people do not create untitled files nor do they not know
where they are messing around in any filesystem, otherwise they should
not be allowed access to the system in the first place.

Cor
--
Mijn Tools zijn zo modern dat ze allemaal eindigen op 'saurus'
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
SPAM DELENDA EST http://www.clsnet.nl/mail.php
1st Law of surviving a gunfight : Have a gun

Eli Zaretskii

unread,
Sep 19, 2008, 9:46:34 AM9/19/08
to help-gn...@gnu.org
> From: Xah Lee <x...@xahlee.org>
> Date: Fri, 19 Sep 2008 04:34:12 -0700 (PDT)

>
> On Sep 19, 1:53 am, Eli Zaretskii <e...@gnu.org> wrote:
> > > From: Xah Lee <x...@xahlee.org>
> > > Date: Thu, 18 Sep 2008 16:50:50 -0700 (PDT)
> >
> > > * Emacs does not provide a user level function to create a new
> > > buffer. It has “Open New file...”, which actually creates a empty file
> > > and immediately prompt user for a file name. This is annoying.
> >
> > This is incorrect. No file is created on disk until you actually save
> > the buffer. Until then, only a buffer is created.
>
> Ok, my original phrasing is a bit off. Please focus on the main ideas.

If you want people to listen to your ideas seriously, you will wish to
make a point of expressing them accurately.

> So, i don't know what u mean except perhaps you are just fooling
> around.

I meant what I said: Emacs does not need to be like other (primitive)
semi-editors, which don't distinguish between files and buffers.

And I'm not ``fooling around'' more than you do.

Xah Lee

unread,
Sep 19, 2008, 10:13:49 AM9/19/08
to
Xah wrote:

> Suggestions on Emacs's Scratch Buffer
> http://xahlee.org/emacs/modernization_scratch_buffer.html

On Sep 19, 6:08 am, xraysmalev...@gmail.com wrote:
> Emacs provides a user level function to create a new buffer. C-x b,
> and enter a name of a non-existing buffer.

>...


> And if I close it without saving,
> Emacs prompts me gently -- it doesn't demand a filename, it asks if I
> want to save it. And only then, if I say yes, does it prompt for a
> filename. How polite.

what you reported doesn't seems to be the emacs behavior for me.

For example:

Type C-x b xyz RET to create a new buffer named xyz.

Type something in it.

Now type M-x kill-buffer RET. The buffer will be killed with all
content lost.

Xah
http://xahlee.org/

Xah Lee

unread,
Sep 19, 2008, 10:21:34 AM9/19/08
to
On Sep 19, 6:04 am, Cor Gest <c...@clsnet.nl> wrote:
> Some entity, AKA Xah Lee <x...@xahlee.org>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
> > Here's a better phrasing:
>
> > • Emacs does not provide a user level function to create a new buffer.
> > It has “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.
>
> Emacs _never_ 'opens' files, it merely visits them and copies its
> content into a (named)-buffer.

> After you are done messing with that buffer you order emacs to write the
> content of the buffer to file-name to relace it and saving
> the unaltered-visited-file. (you _do_ use versioning, don't you ?)
> If you cannot understand this type of editing you really should
> not use emacs at all and use something else.

huh? What is your point??

> Oh, BTW emacs really is ment for people who know what they want to do
> and those people do not create untitled files nor do they not know
> where they are messing around in any filesystem, otherwise they should
> not be allowed access to the system in the first place.

huh? what does this has to do with anything?

r u now saying emacs should only be for elite programers?

r u trying to say emacs is not Microsoft? hum?? I no unstand.

Perhaps u r having a sentiment someting like the following Q:

Q: Why should emacs want to be popular and why should emacs change to
conform the majority?

Luckly i have answered your Q previously, here:

http://xahlee.org/emacs/modernization.html

Quote:

A: This attitude has plagued unix and computer geekers for decades. In
the early 1990s (DOS and unix), tech geekers would sneer at graphical
menus and mouse, with hordes of reasons how pure text interface, the
command line, and or keyboard operations are sufficient and superior
than graphical user interface or using a mouse. This seems ridiculous
today, but such voices are commonly seen all over newsgroups. (Since
about 1998, linuxes are in a frenzied race to copy whole-sale of
Microsoft Windows's user interface ( KDE↗, GNOME↗, Lindows↗ ) trying
to make itself easy-to-use.)

We like emacs, we want emacs to be used by more people, we like more
elisp programers. By improving emacs, as a side effect emacs will also
be more popular. It is not a popularity contest.

Thanks.

Xah
http://xahlee.org/

Xah Lee

unread,
Sep 19, 2008, 10:32:11 AM9/19/08
to
Hi Eli moron,

U wrote:
> If you want people to listen to your ideas seriously, you will wish to
> make a point of expressing them accurately.

Please understand, that the level of precision and time spend in
writing needed depends on the context. You would be a fool, to spend
one year to compose a newsgroup post. And, you would be moron if you
nickpick on spellings and phrasings that are not critical to the main
ideas.

I'm not sure ur a moron, but i wondered, because in my previous
message i specifically pointed out that please focus on main ideas.
You seem to me don't have much general education to sufficiently
understand the situation, but gave a retort about precision that is
typical of sophomorons.

> > So, i don't know what u mean except perhaps you are just fooling
> > around.
>
> I meant what I said: Emacs does not need to be like other (primitive)
> semi-editors, which don't distinguish between files and buffers.

Huh? where did u get the idea that emacs should be like other
primitive semi-editors? what's a primitive semi-editor? Do you mean
vi?

> And I'm not ``fooling around'' more than you do.

Fuck you.

Xah
http://xahlee.org/


xraysm...@gmail.com

unread,
Sep 19, 2008, 11:21:09 AM9/19/08
to

I stand corrected: it doesn't prompt to save, since it was never a
file to begin with. I guess I'm just in the habit of saving when I
want to. Nevertheless, the original point was that Emacs DOES provide
a user-level function to create a new buffer. And it also allows you
to save that buffer as a file -- if you wish.

--the Other michael

Eli Zaretskii

unread,
Sep 19, 2008, 11:31:44 AM9/19/08
to help-gn...@gnu.org
> From: Xah Lee <x...@xahlee.org>
> Date: Fri, 19 Sep 2008 07:32:11 -0700 (PDT)
>
> Hi Eli moron,
> [...]
> Fuck you.

Out of arguments again, eh?


Xah Lee

unread,
Sep 19, 2008, 11:36:58 AM9/19/08
to
xraysmalev...@gmail.com wrote:

> > > Emacs provides a user level function to create a new buffer. C-x b,
> > > and enter a name of a non-existing buffer.
> > >...
> > > And if I close it without saving,
> > > Emacs prompts me gently -- it doesn't demand a filename, it asks if I
> > > want to save it. And only then, if I say yes, does it prompt for a
> > > filename. How polite.

Xah wrote:
> > what you reported doesn't seems to be the emacs behavior for me.
>
> > For example:
>
> > Type C-x b xyz RET to create a new buffer named xyz.
>
> > Type something in it.
>
> > Now type M-x kill-buffer RET. The buffer will be killed with all
> > content lost.

xraysmalev...@gmail.com wrote:
> I stand corrected: it doesn't prompt to save, since it was never a
> file to begin with. I guess I'm just in the habit of saving when I
> want to.

Thanks for the correction.

> Nevertheless, the original point was that Emacs DOES provide
> a user-level function to create a new buffer. And it also allows you
> to save that buffer as a file -- if you wish.

I don't agree that emacs does provide a user-level function for
creating a new buffer. The 2 practical methods to create a new buffer,
by find-file or switch-to-buffer, are both not designed to create a
new buffer for temp use, and each has serious problems in my opinion.

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

• Emacs does not provide a user level function to create a new buffer.


It has “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.

In summary: the problem with find-file is that it promps user to enter
a file name upfront. The problem with switch-to-buffer is that it
doesn't promp to save when user closes it. In both, the functions are
simply not designed for creating a new temp buffer.

-------------------------

But now suppose for a moment that find-file and switch-to-buffer are
very good for creating temp buffers. Isn't that more reason to get rid
of “*scratch*”?

original article http://xahlee.org/emacs/modernization_scratch_buffer.html

Xah
http://xahlee.org/


Nikolaj Schumacher

unread,
Sep 19, 2008, 12:13:50 PM9/19/08
to Cor Gest, help-gn...@gnu.org
Cor Gest <c...@clsnet.nl> wrote:

> Emacs _never_ 'opens' files, it merely visits them and copies its
> content into a (named)-buffer.

"Visit" is really just another metaphor for "open". Of course,
technically, open implies "keep open till closed", and I think that's
why "visit" was invented. But the term "open" has evolved. For
example, you "open" a website in your browser, and are in fact
"visiting" it. There's really little merit in distinguishing between
those two names.

> Oh, BTW emacs really is ment for people who know what they want to do
> and those people do not create untitled files

Yes, we do. We just call them (scratch) buffers. They provide all the
same features Xah's "untitled files" do. Really, the only differences are
nomenclature, the way of creating them and the fact that one exists by
default.


regards,
Nikolaj Schumacher


Alan Mackenzie

unread,
Sep 19, 2008, 12:39:56 PM9/19/08
to
Xah Lee <x...@xahlee.org> wrote:
> Hi Eli moron,

> U wrote:
>> If you want people to listen to your ideas seriously, you will wish to
>> make a point of expressing them accurately.

> Please understand, that the level of precision and time spend in
> writing needed depends on the context. You would be a fool, to spend
> one year to compose a newsgroup post. And, you would be moron if you
> nickpick on spellings and phrasings that are not critical to the main
> ideas.

Sometimes, Xah, your spellings and phrasings, to say nothing of your
wierd variable length quotes with dangling bits, make your message all
but indecipherable.

Eli has one up on you there. English isn't his native language either,
yet he manages to convey his ideas with style and panache.

> I'm not sure ur a moron, but i wondered, because in my previous
> message i specifically pointed out that please focus on main ideas.
> You seem to me don't have much general education to sufficiently
> understand the situation, but gave a retort about precision that is
> typical of sophomorons.

OK, back to the main point. It seems that `switch-to-buffer' (C-x b)
does pretty much what you want. Except you seem upset that when you do
M-x kill-buffer, Emacs kills the buffer. I'd be unhappy if it didn't.

Actually, you'd be better typing C-x k. All you want, I think, is that
Emacs should give you a warning when you're about to kill such a buffer.

Why don't you implement this and post it up? It's not rocket science,
and you do have a basic grasp of Emacs Lisp. You seem to expect that
somebody else should do the work of implementing your ideas - that's
just not the way things work. Implement it now - it should take more
than an hour or two to modify C-x b - then we can try it out to see how
good it actually is.

> Fuck you.

Xah, don't try to fuck - you're not very good at it. Write some Elisp
instead.

> Xah

--
Alan Mackenzie (Nuremberg, Germany).

Eric S Fraga

unread,
Sep 19, 2008, 11:32:39 AM9/19/08
to
On 2008-09-19, Xah Lee <x...@xahlee.org> wrote:
> A: This attitude has plagued unix and computer geekers for decades. In
> the early 1990s (DOS and unix), tech geekers would sneer at graphical
> menus and mouse, with hordes of reasons how pure text interface, the
> command line, and or keyboard operations are sufficient and superior
> than graphical user interface or using a mouse. This seems ridiculous
> today, but such voices are commonly seen all over newsgroups. (Since

the reasons still stand and they are not ridiculous.
give me (screen|ratpoison)+emacs and I have the perfect working environment.
and often the underlying OS doesn't even matter.
'nuff said.

^xb gives what you wanted in any case.

--
MC . -.. --- - ..-. .-. .- --. .- .- - ..- -.-. .-.. .- -.-. ..- -.-
NL Professor Eric S Fraga, Chemical Engineering, University College London
GP Key: FFFCF67D F'prnt: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.

Lowell Gilbert

unread,
Sep 19, 2008, 2:11:06 PM9/19/08
to
Eli Zaretskii <el...@gnu.org> writes:

> Out of arguments again, eh?

Can't identify the arguments until you know which function you're calling.

Alan Mackenzie

unread,
Sep 19, 2008, 4:36:19 PM9/19/08
to
Xah Lee <x...@xahlee.org> wrote:

> In the article The Modernization of Emacs, i suggested that emacs's

> ?*scratch*? buffer be removed. In this article, we give some detail
> about it.

> In the article, i gave the following as primary reasons that scratch
> buffer should be removed:

> * It is not useful by 99% of letter writers. If they wanted a
> scratch pad, they can open a new document and not save it. This way is
> familiar to all software users.

It is necessary to have _some_ buffer when starting Emacs. I don't know
where you get your figure of 99% from. Even when it is not used, it's
not that big a nuisance.

> * 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...@gnu.org. It might well be
accepted for Emacs 23.

[ .... ]

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

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

> * The Ctrl+n shortcut for New is standard and familiar to all
> software users.

That's not true. It's not familiar to me.

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

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

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

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

A mere unimportant trifle.

> * 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. But this option exists
already: `initial-major-mode'.

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

[ .... ]

David Kastrup

unread,
Sep 19, 2008, 5:09:21 PM9/19/08
to
tyler <tyler...@mail.mcgill.ca> writes:

> David Kastrup <d...@gnu.org> writes:
>
>> tyler <tyler...@mail.mcgill.ca> writes:
>>
>>> Xah Lee <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.
>>
>> C-c C-r works in gnus. Which does not mean that alternative ways are a
>> bad idea.
>
> That combination is not defined for me in gnus, but it did lead me to
> discover toggle-rot13-mode, which I *will* now bind to C-c C-r. Thanks!

Huh? When in the summary buffer, I get

C-c C-r runs the command gnus-summary-caesar-message, which is an
interactive compiled Lisp function in `gnus-sum.el'.

It is bound to C-c C-r, W r, <menu-bar> <Article> <Washing> <Rot 13>.

(gnus-summary-caesar-message &optional ARG)

Caesar rotate the current article by 13.
With a non-numerical prefix, also rotate headers. A numerical
prefix specifies how many places to rotate each letter forward.

[back]

Xah Lee

unread,
Sep 19, 2008, 8:02:11 PM9/19/08
to
On Sep 19, 9:13 am, Nikolaj Schumacher <m...@nschum.de> wrote:

> We just call them (scratch) buffers. They provide all the

> same featuresXah's"untitled files" do. Really, the only differences are


> nomenclature, the way of creating them and the fact that one exists by
> default.

That's not the only differences. I have given detail on other
differences.

Quote from my article:
http://xahlee.org/emacs/modernization_scratch_buffer.html

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

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

»

and quote from my post here:

I don't agree that emacs does provide a user-level function for
creating a new buffer. The 2 practical methods to create a new buffer,
by find-file or switch-to-buffer, are both not designed to create a
new buffer for temp use, and each has serious problems in my opinion.

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

• Emacs does not provide a user level function to create a new


buffer. It has “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.

In summary: the problem with find-file is that it promps user to enter


a file name upfront. The problem with switch-to-buffer is that it
doesn't promp to save when user closes it. In both, the functions are
simply not designed for creating a new temp buffer.

Xah
http://xahlee.org/


Xah Lee

unread,
Sep 19, 2008, 8:12:48 PM9/19/08
to
On Sep 19, 9:39 am, Alan Mackenzie <a...@colin2.muc.de> wrote:

> XahLee<x...@xahlee.org> wrote:
> > Hi Eli moron,
> > U wrote:
> >> If you want people to listen to your ideas seriously, you will wish to
> >> make a point of expressing them accurately.
> > Please understand, that the level of precision and time spend in
> > writing needed depends on the context. You would be a fool, to spend
> > one year to compose a newsgroup post. And, you would be moron if you
> > nickpick on spellings and phrasings that are not critical to the main
> > ideas.
>
> Sometimes,Xah, your spellings and phrasings, to say nothing of your

> wierd variable length quotes with dangling bits, make your message all
> but indecipherable.

you think? could it be that your criticial thinking and readings
skills are not mature enough?

Seriously.

I recommend you read some of my literature annotations on my website:

• The Tale Of The Bull And The Ass
http://xahlee.org/p/arabian_nights/an2.html

• The Tragedy Of Titus Andronicus
http://xahlee.org/p/titus/titus.html

• Politics and the English Language
http://xahlee.org/p/george_orwell_english.html

> Eli has one up on you there. English isn't his native language either,
> yet he manages to convey his ideas with style and panache.

you think?

> > I'm not sure ur a moron, but i wondered, because in my previous
> > message i specifically pointed out that please focus on main ideas.
> > You seem to me don't have much general education to sufficiently
> > understand the situation, but gave a retort about precision that is
> > typical of sophomorons.
>
> OK, back to the main point. It seems that `switch-to-buffer' (C-x b)
> does pretty much what you want.

The question is not about whether it “pretty much” does. Nor is it
about whether what i want.

The issue, is about a problem with emacs's “*scratch*” buffer, and how
the 2 alternative practical existing ways to create empty buffer each
are unfit for the purpose. I detailed them in my article:

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

Please u peruse of it.

> Except you seem upset that when you do
> M-x kill-buffer, Emacs kills the buffer. I'd be unhappy if it didn't.

The issue is not about whether i'm upset. Nor is it about whether kill-
buffer not killing the buffer.

Please think.

> Actually, you'd be better typing C-x k. All you want, I think, is that
> Emacs should give you a warning when you're about to kill such a buffer.

Huh? what r u talking about?

> Why don't you implement this and post it up? It's not rocket science,
> and you do have a basic grasp of Emacs Lisp. You seem to expect that
> somebody else should do the work of implementing your ideas - that's
> just not the way things work. Implement it now - it should take more
> than an hour or two to modify C-x b - then we can try it out to see how
> good it actually is.
>
> > Fuck you.
>
> Xah, don't try to fuck - you're not very good at it. Write some Elisp
> instead.

The issue is not about fucking.

Please focuse on the issue if u are interested in discussing it.

Xah
http://xahlee.org/

Xah Lee

unread,
Sep 19, 2008, 8:50:38 PM9/19/08
to
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/


Xah Lee

unread,
Sep 19, 2008, 8:54:18 PM9/19/08
to
On Sep 19, 8:32 am, Eric S Fraga <ucec...@ucl.ac.uk> wrote:
> On 2008-09-19, Xah Lee <x...@xahlee.org> wrote:
>
> > A: This attitude has plagued unix and computer geekers for decades. In
> > the early 1990s (DOS and unix), tech geekers would sneer at graphical
> > menus and mouse, with hordes of reasons how pure text interface, the
> > command line, and or keyboard operations are sufficient and superior
> > than graphical user interface or using a mouse. This seems ridiculous
> > today, but such voices are commonly seen all over newsgroups. (Since
>
> the reasons still stand and they are not ridiculous.

In argument, you can't just say something is ridiculous. You have to
give reasons.

Perhaps you think something is obvious. But in arguments, others might
think the opposite is obvious. That's why good argument needs explicit
reasons.

Xah
http://xahlee.org/

Cor Gest

unread,
Sep 19, 2008, 8:48:25 PM9/19/08
to
Some entity, AKA Xah Lee <x...@xahlee.org>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

> The issue is not about fucking.
>
> Please focuse on the issue if u are interested in discussing it.

Right!

NOBODY is interested in discussion(for discussions sake),
unless it is accompanied by working code.

Chetan

unread,
Sep 19, 2008, 9:12:37 PM9/19/08
to
Xah Lee <x...@xahlee.org> writes:

I haven't followed this closely, but this seems to be back where this
started, although I am not sure if the original issue of "*Gnum Emacs*"
buffer got resolved. Actually, I didn't realize it existed until I ran
with -q. Presumably all this is meant for a newbie, so is it expected to
be bundled with CUA mode and enabled by default for a newbie?

Chetan

Allan Gottlieb

unread,
Sep 19, 2008, 9:53:35 PM9/19/08
to tyler, help-gn...@gnu.org
At Fri, 19 Sep 2008 09:42:44 -0300 tyler <tyler...@mail.mcgill.ca> wrote:

> David Kastrup <d...@gnu.org> writes:
>
>> tyler <tyler...@mail.mcgill.ca> writes:
>>
>>> Xah Lee <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.
>>
>> C-c C-r works in gnus. Which does not mean that alternative ways are a
>> bad idea.
>
> That combination is not defined for me in gnus, but it did lead me to
> discover toggle-rot13-mode, which I *will* now bind to C-c C-r. Thanks!

What version of emacs are you using?
What happens if you are in a gnus summary buffer and type

C-h k C-c C-r

allan


Kevin Rodgers

unread,
Sep 19, 2008, 10:35:08 PM9/19/08
to help-gn...@gnu.org
Xah Lee wrote:
> I don't agree that emacs does provide a user-level function for
> creating a new buffer. The 2 practical methods to create a new buffer,
> by find-file or switch-to-buffer, are both not designed to create a
> new buffer for temp use, and each has serious problems in my opinion.
>
> • 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.)
>
> • Emacs does not provide a user level function to create a new
> buffer. It has “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.
>
> In summary: the problem with find-file is that it promps user to enter
> a file name upfront. The problem with switch-to-buffer is that it
> doesn't promp to save when user closes it. In both, the functions are
> simply not designed for creating a new temp buffer.

Wow, if you had put 1% of the effort into coding that you put into this
thread, you could have come up with something like this:

(defun switch-to-new-buffer ()
"Switch to a new *scratch* buffer."
(interactive)
(switch-to-buffer (generate-new-buffer "*scratch*"))
(setq switch-to-new-buffer t))

If it's such a huge problem for 99% of users, you could propose to the
maintainers that it be added to files.el

--
Kevin Rodgers
Denver, Colorado, USA

Xah Lee

unread,
Sep 19, 2008, 10:58:55 PM9/19/08
to
On Sep 19, 7:35 pm, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> XahLeewrote:

Thanks. But the issue is not about how to code a better switch-to-new-
buffer. The issue is about criticism of *scratch* buffer, and a
suggestion that emacs should remove it.

Please see:
http://en.wikipedia.org/wiki/Critical_thinking

If you didn't read the original article, please see:

Xah Lee

unread,
Sep 19, 2008, 11:06:47 PM9/19/08
to
On Sep 19, 5:48 pm, Cor Gest <c...@clsnet.nl> wrote:
> Some entity, AKAXahLee<x...@xahlee.org>,

> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
> > The issue is not about fucking.
>
> > Please focuse on the issue if u are interested in discussing it.
>
> Right!
>
> NOBODY is interested in discussion(for discussions sake),
> unless it is accompanied by working code.

Actually, people are interested in discussion, and in fact that's what
newsgroup is for.

Also, you seems to suggest that people should not criticize software
such criticism is not valuable, unless it is companied by code patches
that fixes it.

That is not true. In fact, successful software companies, from Open
Source ones such as GNU to commercial corps such as Apple and
Microsoft, highly value user feedback and criticism, and very actively
change their software due to criticisms.

Possibly you do not understand the meaning of criticism, or the
meaning of “constructive” criticism. I suggest the following articles:

http://en.wikipedia.org/wiki/Criticism

http://xahlee.org/UnixResource_dir/writ/criticism.html

plain text version follows
--------------------
Criticism versus Constructive Criticism

Xah Lee, 2003-01

A lot intelligent people are rather confused about criticism,
especially in our “free-speech” free-for-all internet age. When they
say “constructive criticisms are welcome” they mostly mean “bitching
and complaints not welcome”. Rarely do people actually mean that
“criticism without suggestion of possible solutions are not welcome”
or “impolite criticism not welcome”.

Such discernment is important. Wanton bitching as internet-using geeks
are used to is not criticism is any form.

People can be respected and make a living out of criticisms, called
critics, but not bitching. And when one really value opinions, you
often want criticism without qualifications. Just be happy that
valuable criticisms may come to you free from the experts in the
public. The instant you qualify what kind of feedback are welcome,
your feedback is compromised. (this is particularly so for political
or controversial subjects)

One easy way for many of the unix geekers to see this is the
cryptology industry.

If a person really desires valuable criticisms that are polite or with
solutions or “constructive” (whatever that means), one usually has to
pay.

Xah
http://xahlee.org/


Alan Mackenzie

unread,
Sep 20, 2008, 4:17:34 AM9/20/08
to Xah Lee, help-gn...@gnu.org
'Morning, Xah!

On Fri, Sep 19, 2008 at 05:50:38PM -0700, Xah Lee wrote:
> 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.

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

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.

Alan Mackenzie

unread,
Sep 20, 2008, 4:50:00 AM9/20/08
to Xah Lee, help-gn...@gnu.org
Hi, Xah.

One small but important point you made:

On Thu, Sep 18, 2008 at 04:50:50PM -0700, Xah Lee wrote:

> Here are few minor reasons:

> * When the scratch buffer is closed, emacs does not prompt user to
> save it. This easily causes data loss.

The other side of the argument is that *scratch* is intended for
temporary, unimportant doodling, and for anybody who uses it this way,
being continually prompted to save it would rapidly become annoying.

I don't think there's a built in option to change this. However, you
could write a hook function to add in this check. The hook is
`kill-buffer-query-functions' and is documented in the Elisp manual on
the page "Killing Buffers".

[ .... ]

> * modern_operations.el.

A small point about this file (at
<http://xahlee.org/emacs/modern_operations.el>): you don't really need
the function `kill-line-backwards', since M-0 C-k will do this for you.
However, that key binding is a bit clumsy. You could use it like this:

(defun kill-line-backwards ()
"Doc string ...."
(interactive)
(kill-line 0))

Nikolaj Schumacher

unread,
Sep 20, 2008, 6:51:34 AM9/20/08
to Xah Lee, help-gn...@gnu.org
Xah Lee <x...@xahlee.org> wrote:

> On Sep 19, 9:13 am, Nikolaj Schumacher <m...@nschum.de> wrote:
>
>> We just call them (scratch) buffers. They provide all the
>> same featuresXah's"untitled files" do. Really, the only differences are
>> nomenclature, the way of creating them and the fact that one exists by
>> default.
>
> That's not the only differences. I have given detail on other
> differences.

Yes. Please note that the post you quoted was sent after my message, so
the other difference hadn't been made clear at that time.

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

But on the other hand, creating multiple scratch buffers with names like
"untitled" through "untitledN" might not be in the users best interest.

I agree there should probably at least be a menu entry for "New buffer"
in the "Buffers" menu.

> • Emacs does not provide a user level function to create a new
> buffer. It has “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.

Well, not exclusively. For instance, Xcode prompts for the type of
file, then for the name.

You should note that apps that do this differently almost never call
this "New file". Because a file without a file name doesn't make sense.
Instead, they call this "New <document type>" or just "New". (At least
all the apps on my computer do.) So in the context of Emacs, the
correct name would probably be "New buffer".

> The problem with switch-to-buffer is that it doesn't promp to save
> when user closes it. In both, the functions are simply not designed
> for creating a new temp buffer.

Of course that depends on how you define "temp" buffer... I would avoid
that name for for what you're suggesting.

I /would/ like certain buffers to prompt before closing. You should add
autosaving to the mix, too. Sometimes I do too much actual work in the
scratch buffer, which is lost if Emacs crashes.


All this, however, is no reason to remove the scratch buffer. I can see
it defaulting to fundamental-mode, not having that message in it, and
prompting if modified and killed. But somehow I feel your proposed fix
doesn't fit your initial demand (removing the scratch buffer). The
scratch buffer itself isn't a usability problem. It's limitations are.
So, if anything, you're improving the scratch buffer not scrapping it.

regards,
Nikolaj Schumacher


Christian Herenz

unread,
Sep 21, 2008, 8:06:55 AM9/21/08
to
Xah schrieb:

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

Hah... Having not read the whole conversation of this topic, I want to add an
experience I made last week. I was in the lab, and saw that a guy on the other
site worked inside an xemacs session. I asked him, why he puts everything in the
*scratch* buffer - and he looked at me and asked "buffer - scratch - sure you
are allright". I think that lots of emacs users today just use emacs as it where
notepad.exe or something like that, especially in scientifc environments some
people could boost their productivity, if they would at least know some of the
basics of the editor in the beginning of their career. When I told the guy: "Do
you know, that you can open more than one file at a time in emacs?" He asked me:
"Why the hell should I want to do that - I just open another emacs...".

Just a little story...

Greets,
Christian

Joost Kremers

unread,
Sep 21, 2008, 3:01:40 PM9/21/08
to
Christian Herenz wrote:
> Xah schrieb:
>
>> 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.

personally, i find it unlikely that the *scratch* buffer has ever kept
anyone from adopting emacs. i also find it extremely unlikely that anyone
will be convinced to start using emacs when the *scratch* buffer is
ditched.

personally, i see emacs as a sophisticated tool for professionals. just as
i wouldn't buy a €10.000 SLR camera for the occasional holiday snapshot
i take, other people don't depend on an editor that much to (want to)
invest time in learning emacs.

> Hah... Having not read the whole conversation of this topic, I want to add an
> experience I made last week. I was in the lab, and saw that a guy on the other
> site worked inside an xemacs session. I asked him, why he puts everything in the
> *scratch* buffer - and he looked at me and asked "buffer - scratch - sure you
> are allright". I think that lots of emacs users today just use emacs as it where
> notepad.exe or something like that, especially in scientifc environments some
> people could boost their productivity, if they would at least know some of the
> basics of the editor in the beginning of their career. When I told the guy: "Do
> you know, that you can open more than one file at a time in emacs?" He asked me:
> "Why the hell should I want to do that - I just open another emacs...".

man... such people should simply be banned from using emacs ever again. ;-)


--
Joost Kremers joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Eric S Fraga

unread,
Sep 22, 2008, 4:25:11 AM9/22/08
to
On 2008-09-20, Xah Lee <x...@xahlee.org> wrote:
> On Sep 19, 8:32 am, Eric S Fraga <ucec...@ucl.ac.uk> wrote:
>> On 2008-09-19, Xah Lee <x...@xahlee.org> wrote:
>> > [...]

>> > than graphical user interface or using a mouse. This seems ridiculous
>> > today, but such voices are commonly seen all over newsgroups. (Since
>>
>> the reasons still stand and they are not ridiculous.
>
> In argument, you can't just say something is ridiculous. You have to
> give reasons.

Excuse me? *You* said the reasons were ridiculous, not me. The
reasons are there, as you implied. Let me give you a couple:

1. RSI: I cannot use a mouse without pain.
2. speed: I type 60+ wpm, which is not particularly fast but results
in faster output than using the mouse, especially if the GUI is badly
designed (which applies to most graphical apps in my experience).

Others will have their own reasons and calling them ridiculous is
potentially insulting. If you prefer a graphical interface, fine. I
do not.

> Perhaps you think something is obvious. But in arguments, others might
> think the opposite is obvious. That's why good argument needs explicit
> reasons.

I agree; you said reasons had been given for text based interfaces.
You then said these were ridiculous and then failed to give any
reasons why. Maybe you should start listening to your own advice?
Just a friendly suggestion.

--
Eric S Fraga, UCL

Xah Lee

unread,
Sep 22, 2008, 7:40:18 AM9/22/08
to
Hi Erik Fragga,

On the subject of RSI, perhaps you should use Dvorak, and you'd be
interested in my article here:

How To Avoid The Emacs Pinky Problem
http://xahlee.org/emacs/emacs_pinky.html

Text version follows:
-------------------------------------
How To Avoid The Emacs Pinky Problem

Xah Lee, 2006

Emacs makes frequent use of the control key. On a conventional
keyboard, the Control Key is at the lower left corner of the keyboard,
usually not very large and is pressed by the pinky finger. For those
who use emacs all day, this will result in repetitive strain injury↗.
This page lists some tips on avoiding this pinky problem.

I've been using computer since 1991, at least 8 hours a day on average
every singe day. I was a QWERTY touch-typist with 80 wpm and worked as
a secretary for about 2 years, then in ~1994 i switched to Dvorak. I
started to use emacs everyday since 1998. I am a keyboard and key
macro nerd, and have used tens of keyboard macro or keymap type of
utilities on the Mac, unixes, and Windows, always looking for the most
ergonomic and efficient way to operate the keyboard and computer. This
page summarize my experiences applied to emacs.

The best way to avoid the pinky problem is actually to use a good
keyboard. Let us start with some tips on choosing a good keyboard.
Tips For Selecting A Computer Keyboard

Here are some keyboard hardware advices:

• Buy a keyboard such that the Alt and Control keys are large.

• Buy a keyboard where Alt and Control are also available on the right
side.

• The Alt and Control key's positions on the left and right sides
should have the same distance to your left and right thumbs (while
your hands are rested in standard touch-type position). Specifically:
the distance from the left Alt to the F key should be the same as the
right Alt to the J key.

BAD
Apple keyboard

above: The Apple keyboard as of 2006. Note the ridiculous distance of
the right side's modifier keys. It is not possible, to use the right
thumb to press the alt key while the index finger remains on the J.

Many keyboards don't have full set of modifier keys on the right side,
and when they do, they are positioned far to the right, making them
not much usable for touch typing. For example, the keyboards made by
Apple Computer, their right-side Command/Alt/Ctrl keys are inferior
citizens. They are placed far more to the right, making the right set
of modifier keys difficult or impossible to reach with the thumb. It
makes these keys essentially decorative in nature. (Apple did this to
make the keys flush at the lower right corner; sacrificing function
for esthetics.).

GOOD
Microsoft Natural Multimedia keyboard

above: The Microsoft Natural Multimedia keyboard. Note, the keys are
split and oriented for each hand. And, the Ctrl, Alt are very large
and symmetrically positioned with respect to each hand's thumb. (See A
Review of Microsoft Natural Keyboards)

For more extensive commentary on various computer keyboards and
design, see: Computer keyboards Gallery.
How To Press The Control Key
Use Your Palm or Semi-Fist

Do not use your pinky to press the Control key.

For most PC keyboards, it is very easy to press the control key using
your palm. Just open your hand somewhat and push down with the meat at
the chopping edge of your hand. Alternatively, you can roll your wrist
a bit, curl in your fingers into a semi-fist, then sit your fist on
the control key.
Use Both Hands

Do not use a just one hand to type a Control+‹key› combo.

Use one hand to press Control, use the other hand to press the
combination key. This is the same principle for pressing the Shift key
in touch-typing.

When the key you want to press is on the left side of the keyboard,
use the right side of Control key. For example, to press “Ctrl+a”,
hold down the right Control with your right palm edge, and use your
left hand to press “a”. Make this into a habit. Using a single hand to
press “Ctrl+‹key›” combo usually means your hand needs to cram into a
particular shape, thus putting stress on it when done repeatedly.

This is also why choosing a keyboard with Control keys positioned on
both sides of the keyboard symmetrically, is important.
Software Ways To Avoid the Pinky Problem

A good keyboard and good typing habit is good. But suppose you are
stuck with a lousy keyboard or your notebook computer. A notebook
computer usually don't have control key on both sides of the keyboard.
Its control key is very small, and it cannot be pressed by palm. Here
are some suggestions for this situation.
Swap Control and Alt

Try swapping the Control and Alt keys.

Emacs's are developed for Lisp Machine's keyboards of the 1980s, which
have the Control key near the space bar, and the Meta key further away
from the space bar. So, Control key is the primary modifier key.
However, today's keyboards have Alt instead of Meta, and the Control
key is placed at the far corner instead. Emacs did not change its
shortcuts. It simply mapped the Meta to Alt. That is why today, most
frequently used keyboard shortcuts have the more difficult to press
Control key instead of the Alt. For more detail on this and other
aspects of emacs's shortcuts, see: Why Emacs's Keyboard Shortcuts Are
Painful.

By switching the Alt and Control key, will make Emacs's keyboard
shortcuts much easier to use as it was designed.

The other advantage of swapping Alt and Control, is that on Windows
and Linuxes, most direct shortcuts involve the Ctrl key. By swapping,
Windows shortcuts are made easier since now Control is right under
your thumb. On the Mac, shortcuts are made with the Cmd key. If you
swap Control with Cmd, the primary modifier Cmd will be at the corner,
thus make it more difficult to use all other applications. The best
thing to do on the Mac is to swap Control and Cmd only in Emacs. I do
not know if it is possible to swap Ctrl and Alt within emacs.

For system-wide swap of modifier keys on OS X, see: How to Swap
Modifier Keys on OS X.
Swap Cap Lock and Control

Another commonly suggested solution is to remap the the Cap Lock and
Control key by swapping them. This is not a optimal solution, because
the Control key is still pressed by the pinky, and somewhat displaces
your hand on home position. Also, there is now only one Control key,
making the left pinky doing double work. (modifier keys comes in pairs
for good reasons. Try pick out a Shift key and type for a week)
However, if you are stuck on a lousy keyboard such as laptops, and
unable to swap Ctrl and Alt, then making the Cap Lock key as Control
might be a practical solution.

For detail, see: Why You Should Not Swap Cap Lock With Control.

It is not possible to swap cap locks and control key within emacs,
because the cap-lock key signal is not received by applications.
However, you can do it with several system utilities. In unix-like
systems, this is done with xmodmap. See Emacs wiki: moving the Ctrl
key↗.
Use a Ergonomic Shortcut Layout

If you are adventurous, the best solution is to use a ergonomically
designed shortcut layout for emacs.

See: A Ergonomic Keyboard Shortcut Layout For Emacs.
Dvorak Keyboard Layout

Perhaps a more important ergonomic improvement one can make is by
using the Dvorak keyboard layout.
dvorak keyboard layout

I've been using Dvorak keyboard since 1994. It works beautifully with
emacs. It makes typing more comfortable. (i use emacs since 1997). If
you use unix/X11, you can switch to dvorak by running
dvorakKeymap.txt. On Mac OS X, use “System Preference: International”.
On Windows XP, go to “Control Panel:Regional and Language Options”.

For more info about Dvorak layout, see Wikipedia: Dvorak Simplified
Keyboard↗.

A web comics introducing Dvorak: http://www.dvzine.org/zine/index.html

A video game: The Typing of the Dead↗.

Xah
http://xahlee.org/

On Sep 22, 1:25 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
wrote:


> On 2008-09-20,XahLee<x...@xahlee.org> wrote:
>
> > On Sep 19, 8:32 am, Eric S Fraga <ucec...@ucl.ac.uk> wrote:

Lennart Borgman (gmail)

unread,
Sep 22, 2008, 8:16:27 AM9/22/08
to Xah Lee, help-gn...@gnu.org
Xah Lee wrote:
> Hi Erik Fragga,
>
> On the subject of RSI, perhaps you should use Dvorak, and you'd be
> interested in my article here:
>
> How To Avoid The Emacs Pinky Problem
> http://xahlee.org/emacs/emacs_pinky.html

Xah, it is good that you try to help people with this, but why don't you
mention sticky keys:

http://www.emacswiki.org/cgi-bin/wiki/StickyModifiers

On the bottom of that page is also a link to Alex Schröder's comment
about physical fitness and RSI. I very much agree with Alex conclusion.

Xah Lee

unread,
Sep 22, 2008, 9:07:34 AM9/22/08
to
On Sep 20, 1:17 am, Alan Mackenzie <a...@muc.de> wrote:
> 'Morning,Xah!

>
> On Fri, Sep 19, 2008 at 05:50:38PM -0700,XahLeewrote:
> > 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.
>
> 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.

many apps, including most browsers and text editor, can start without
a window present. (on the Mac)

In fact, i think that's most apps behave on the Mac these days. (as
opposed to must having a window present. (on Windows, this is somewhat
irrelavent since each app are often in its own window with menu bar))

In AquaMacs for example, you can close all buffers, windows, frames,
without quiting the app.

> > Even so, you don't need *scratch*. You can just have ???untitled???.
>
> I think all those question marks would confuse people.

Why do u keep using a broken newsreader that don't understand unicode
and insist about the issue? C'mon.

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

Lol. Alan, do u really live in a cave or what?

I've always found emacs developers or lisp coders to be weird cave
dwellers who bury their head in their perspective tech and have little
understanding of software industry and professional programers.

I started using emacs daily since 1998. I only started learning elisp
in 2006. I have actually actively resisted in learning elisp, because
of fear of falling into a blackhole of code diddling of little
significance. Too bad, i have now since fallen into this hole. After
all, i haven't had a day job since about 2004.

it's quite bizzar when you hear some of the lispers. When's the last
time you saw the sun, Alan?

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

That sentiment is rather silly to meaningless.

Sometimes in other context, you see emacs fanatics insist that emacs
is the best tool for non-programing text editing, period. In fact, you
see a few heads popping up here now and then saying how great they
love emacs and they are not programers but writers.

In other times, like now, you see emacs hotheads insists that emacs is
more for programers and programers primarily, to the degree that if
they don't know much about program, perhaps they should goto Microsoft
Word, and about how emacs “should not dumb down for these people”.

Execuse my French, but when i discusses these issues, it gets me angry
over the degree of their FANTASTICAL STUPIDITY.

So Alan, what does it really mean, to say that “Emacs is intended for


programmers, though it's great that other sorts of writers find it

useful too.”? What does it signify? Does it imply anything? Does it
actually mean anything other than a sentimental catch phrase to
express certain love of emacs??

actually.... i do know exactly what's on your mind. I can write say a
2 thousand words article on emacs that is 100% of how you feel, how
you see things, what you know about it. Cause i understand tech
geekers far too well.

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

most people simply stopped using emacs. See:

Text Editors Popularity
http://xahlee.org/emacs/text_editor_trends.html

plain text version follows:

∑ Back to Emacs Tutorial.
Text Editors Popularity

Xah Lee, 2007-08

This page shows the popularity of programer's text editors and IDEs.
The following lists them in order of popularity as of 2007-08.

1. (Microsoft Word↗)
2. Microsoft Visual Studio↗
3. emacs↗, Vim↗
4. Notepad++↗
5. Xcode↗
6. Textmate↗
7. Eclipse IDE↗
8. (Wordpad↗)
9. JEdit↗
10. BBEdit↗, Notepad2↗
11. NEdit↗
12. (TextEdit↗)

The ranking is based on Google Trends↗. This is not be a very accurate
measurement of user base, but gives a rough indication.

Those in parenthesis are text editors not used for programing, but
included here just to give a context, and a sense of the relative
ranking by Google Trend.

Ideally, i'd like to list all programer's text editors and IDEs, by
the number of users. (and limiting the entries to 10 or so)
Preferably, also show the data by a graph so that we can see the
relative gap between ajacent entries. (for example, when shown as a
pie chart, Microsoft Word and Visual Studio together might be 90%,
while all the rest is just 10%)

I haven't done much research on what IDEs are common on the Windows
platform. (Never developed for MS technologies) So if you work in the
Windows platform and knew some of the commonly used IDEs or editors,
please let me know.

Among the above list, some editor should be there but for one reason
or another i wasn't able to use Google Trends to get some sensible
statistics are: Microsoft Notepad↗, Programmer's Notepad↗, Borland
Delphi↗, Kate (text editor)↗, GEdit, roughly same popularity as Nedit
according to google trends, but it doesn't have Wikipedia entry!

Also note: Google trends has records back to about 2004. This
conveniently marks the beginning year to be considered on this list.
Personally, i've been using Mac in about 1991. Many IDEs on the mac
has come and gone. From roughly 1990 to 2002, the following are the
major editor/platform used on the Mac, each basically replaced the
previous one chronologically: Macintosh Programmer's Workshop↗, THINK
C↗, CodeWarrior↗, SimpleText↗. But since the arrival of OS X,
CodeWarrior and SimpleText went extinct primarily due to the platform
change and arrival of XCode and TextEdit. Also, BBEdit is widely
popular throughout the 1990s, but its user base gradually declined
with the arrival of OS X↗ in 2001.
Who Cares?

We all have heard “vi vs emacs” a million times, and have participated
in brawls and polls about which editors are the best. Although, these
are almost always carried out in a facetious fashion among tech
people, without any hint about the social importance of these kind of
questions.

Statistics such as market share, is broadly speaking part of the info
and activity of demographics and market research. Such information is
very important in decision making, and corporations will often spend
tens of thousand dollars to research or buy the info. (there are a
entire market of business dedicated to market research) For example, a
corporation will need to know its market share to make decisions on
marketing budget, development budget, pricing decision, corporate
buyout negotiation, down to the technical details of a feature design.
Good and bad directional decisions can mean success and extinction.
(For more on this, see Wikipedia Market research↗. )

Non-commercial software such as emacs, isn't dependent on paying
customers nor driven by financial investors, so many market questions
are moot. (since in a sense nobody really could care if a particular
free software went exinct for lack of users, and thousands of
OpenSource or FreeSoftware big and small come and went all the time
without a beep.) However, getting users and getting info about users
is still a important aspect in understanding and for improving our
software, because we like emacs and want our time investment into it
survive. (put it in another way, we don't want to have to be forced to
switch to vi due to emacs dilapidation and oblivion.)

In our OpenSource or Freedom software world, competition such as emacs
vs xemacs vs vi, or GNOME vs KDE, etc, isn't about cutting-throat or
bankruptcy or loosing our daily bread and butter, but it is still a
valid competition, similar to sports and games.

As a example of importance of the info about market share of editors,
consider emacs advocates and Free Software Foundation (emacs
developers), in their consideration of modernization of Emacs. If
emacs is used by majority of professional programers (defined as those
who makes a living primarily by coding), then perhaps it is not so
important to changes emacs to conform to modern UI. But if data
indicates that, say, the combined users emacs and vi is less than 10%
of the programing population, then the modernization of emacs issue
warrants much more weight.

--------------------------

little usability issues addds up. You say *scratch* is little problem,
but then emacs uses non-standard terminology (buffer, yank, kill-ring-
save, window/frame, ... etc), non-standard UI (minibuffer instead of
popup dialog...etc), non-standard keyboard shortcuts, and etc etc too
many to list. You basically end up with a system that is just too
foreign, and difficult to learn is one primary complaint of emacs.

there are many reasons why emacs is the way it is, and many reasons
that many emacs ways are superior and operatively more efficient. We
need to exam on the whole, all thing considered, and improve those
problematic or of little utility and or a simple solution that can
work.

I think my criticism and proposed fix on the *scratch* buffer problem
is quite simple and effective...

on hindsight of this thread of all things already been said ...
perhaps give it another scan?
http://xahlee.org/emacs/modernization_scratch_buffer.html


> [ .... ]
>
> > > 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.
>
> No, it's about writing a patch for something _you_ want.

in commercial software, it's not about something you want. It's about
what makes money, and that is determined by how people actually want
to pull money out of their pocket. In order to achieve that, is about
what's really best, that people want.

Successful software corps, such as Apple, Microsoft, IBM, google, etc
roughly did that. You don't become successful by breaking the law as
most tech geekers likes to think of Microsoft.

In Open Source software, it's largly driven by the need of a few
coders. Emacs came to be largely because that's what Richard Stallman
needs in the 1980s. He has ceased being a coder who actively work in
the industry since maybe 1990s. ...

... am not going to write another thousands word article and surely
followed by wild discussion on this ... maybe you see some of my
points.

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

I have given reasons why C-x b is unfit for creating a temp buffer. To
begin, the name is switch-to-buffer. Also, emacs doesnt offer to save
a buffer not associated with file, so you have potential data lose...
I also give reason why C-x C-f is unfit, because it prompt for a file
name... in fact i listed these two ways in my article originally.
Given my article, i do not see any new point or argument against what
i said already.

Please, do read my article with a open mind. I am effectively
repeating my article for each reply in this now 50 messages thread.

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

it would be ridiculous to say that you are not familiar with Ctrl+n.
Try to put that on your resume. Like this: “I, Alan, although am a
tech geek, but i don't know what Ctrl+n” is in today's software.
Please do hire me though.”

LOL. How silly can tech geekers get? Really? How utterly bizarre and
silly can they get? Alan, you “are not familiar with Ctrl+n” eh?

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

huh? are you saying that clone-buffer is a good way to create a new
buffer?

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

As i mentioned, little oddities here and there adds up. See above.

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

Sorry if i sound rude, but what you said, your attitude, your
sentiment, your feelings about software user interface, typical of
tech geekers, are the most motherfucking, baseless, stupid.
Fantastically stupid. Moronic. Flat earth.

Step outside of your cave. Go ask a librarian, or someone in Apple or
Microsoft who works or research on UI, or even try to consult academic
professors...

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

... here we venture into the problem of Open Source... see above i
already give some pointers on the issue. In commercial softs, you have
a goal, and how your app will be are based on facts and professional
experts works on it with their daily bread at stake. In Open Source,
joe moron has the final word, or else, start your own!

It is not a wonder, most Open Source software for the desktop users
don't have any foothold on the market, even though $free$ as cig given
to children.

This does not mean open source softs has to be stupid. Little
thinking, little suggestion, and a whole lot of copying of commercial
apps helps (such as linuxes copying almost entire Microsoft Window
UI). Emacs copied a whole lot from the commercial Xemacs (Lucid Emacs)
from about 1990 to 2004. Open source softs do improve slowly (e.g. CUA
mode).

you want emacs to improve? think more, and get away from tech geeker
mindset. Go to college and study more about humanities. Your thoughts
on software will improve far more than decades of tech geeking and
slashdot.

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

That depends. In fact, a lot people swore or worse, and they made a
change... e.g. recently i learned of:

http://en.wikipedia.org/wiki/Lenny_Bruce
http://en.wikipedia.org/wiki/George_Carlin

... and see also

http://xahlee.org/Periodic_dosage_dir/lacru/crumb.html
http://xahlee.org/Periodic_dosage_dir/lacru/goya.html
http://xahlee.org/Periodic_dosage_dir/lacru/odalisque.html

... we could go on and discuss the history of swearing and impact on
society, or exam the world's culture and attitude about swearing, or
the psychology of swearing, swearing in modern society, the history of
swearing tolerance ... i think we'd have a ball.

also note, swearing is sometimes the most effective way of expression.
For example, if someone bugs you and you just burst out “fuck off”,
that says a lot, and would avoid potential damage to all parties ...

and, of course, if your aspiration is to be a political leader, than
swearing in public is often bad ... in some sense, it is about a
image, a diplomacy, or in some tech geeker way of thinking, it's about
lying and smiling.

Smile!

Ok, quickly typed out n no time to edit.

Xah
http://xahlee.org/

Xah Lee

unread,
Sep 22, 2008, 9:08:29 AM9/22/08