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

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

[Davin Pearson]

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*")))
  )

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

[Giorgos Keramidas]

On Mon, 15 Sep 2008 22:28:29 -0700 (PDT), Davin Pearson <davin.pearson@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

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

[Davin Pearson]

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!

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

[Adam Rooke]

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.

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

[Nikolaj Schumacher]

Davin Pearson <davin.pearson@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

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

[Charles Sebold]

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

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

[Xah]

On Sep 16, 1:44 am, Charles Sebold <cseb...@gmail.com> wrote:
> 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.

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/

☄

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

[Giorgos Keramidas]

On Tue, 16 Sep 2008 13:57:59 -0700 (PDT), Xah <xahlee@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.

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

[Xah Lee]

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/

☄

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

[Xah Lee]

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/

☄

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

[tyler]

Xah Lee <xah@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/

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

[David Kastrup]

tyler <tyler.smith@mail.mcgill.ca> writes:

> Xah Lee <xah@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

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

[tyler]

David Kastrup <dak@gnu.org> writes:

> tyler <tyler.smith@mail.mcgill.ca> writes:
>
>> Xah Lee <xah@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!

Tyler

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

http://noooxml.org

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

[Allan Gottlieb]

At Fri, 19 Sep 2008 09:42:44 -0300 tyler <tyler.smith@mail.mcgill.ca> wrote:

> David Kastrup <dak@gnu.org> writes:
>
>> tyler <tyler.smith@mail.mcgill.ca> writes:
>>
>>> Xah Lee <xah@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

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

[tyler]

Allan Gottlieb writes:
 > At Fri, 19 Sep 2008 09:42:44 -0300 tyler <tyler.smith@mail.mcgill.ca> wrote:
 > 
 > > David Kastrup <dak@gnu.org> writes:
 > >>
 > >> 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
 > 

My bad. I tried C-c C-r in the article buffer, not the summary
buffer. It does behave as advertised when invoked from the summary
buffer.

Incidentally, when I first tried to decode the message, I started with
C-h a rot13, which brought up a number of appropriate functions, but
_not_ gnus-summary-caesar-message, which is what C-c C-r is bound to.
Is there a better way to perform a quick search for functions,
something more inclusive than C-h a, but faster than C-h i followed by
browsing to the emacs indices?

Cheers,

Tyler

-- 
Don't learn the tricks of the trade; learn the trade.

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

[Tassilo Horn]

tyler <tyler.smith@mail.mcgill.ca> writes:

Hi Tyler,

> Incidentally, when I first tried to decode the message, I started with
> C-h a rot13, which brought up a number of appropriate functions, but
> _not_ gnus-summary-caesar-message, which is what C-c C-r is bound to.
> Is there a better way to perform a quick search for functions,
> something more inclusive than C-h a, but faster than C-h i followed by
> browsing to the emacs indices?

If you knew the key before, you could have done `C-h k C-c C-r'.  Else
`C-h a' (for commands) and `M-x apropos' (for functions and variables)
is quite nice.

If you don't find what you're looking for then, it might be that the
thing you're looking for is badly named.  In the actual case, that's not
true, cause rot13 is a caesar variant and `message-caesar-buffer-body'
is capable to encode with an arbitrary rotation number.

So if `apropos' didn't help, try `C-h d' (`apropos-documentation').  Fed
with rot13 it finds `message-caesar-buffer-body' as entry in the message
mode map.

Bye,
Tassilo

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

[David Kastrup]

tyler <tyler.smith@mail.mcgill.ca> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> tyler <tyler.smith@mail.mcgill.ca> writes:
>>
>>> Xah Lee <xah@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]


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Xah Lee]

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/

☄

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

[Xah Lee]

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/

☄

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

[Eli Zaretskii]

> From: Xah Lee <xah@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.

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

[Xah Lee]

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/

☄

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

[Cor Gest]

Some entity, AKA Xah Lee <xah@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 

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

[Xah Lee]

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/

☄

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

[Eric S Fraga]

On 2008-09-19, Xah Lee <xah@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 >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.

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

[Xah Lee]

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/

☄

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

[Eric S Fraga]

On 2008-09-20, Xah Lee <xah@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
GP Key: FFFCF67D F'prnt: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D
BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.

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

[Xah Lee]

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:
> >> On 2008-09-19,XahLee<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
> GP Key: FFFCF67D F'prnt: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D
> BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.

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

[Lennart Borgman (gmail)]

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.



> 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:
>>>> On 2008-09-19,XahLee<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
>> GP Key: FFFCF67D F'prnt: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D
>> BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.
> 
> 

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

[Xah Lee]

On Sep 22, 5:16 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> wrote:
> 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

Gosh, in every thread that relates to keybinding, you post about
sticky keys, as if insisting that it is the ultimate solution. Kinda
getting annoying! =(^o^)=

(and i was shocked that in a discussion with you about a month or 2
ago here, despite all your enthus about emacs keybinding as done in
your EmacsW32, you have no familiarity on how keyboard shorcuts on the
Mac is like)

i'm not sure what to say about sticky keys as a UI with respect to
ergonomics and efficiency ... Here's some quick notes:

• i like them fine. I've used Windows NT daily, 8 hours a day, from
about 1998 to 2005.

• sticky key, or pressing several keystrokes in sequence as opposed to
pressing multiple keys together, is good alternative i think, possibly
even better, as a UI in terms of ergonomics and efficiency of typing
shortcuts ... though, i have not really studied key sequence
alternative in detail. When i used windows, i do press Alt then some
other key often and love it.

... alright, i'm adding the sticky suggestion here:
http://xahlee.org/emacs/emacs_pinky.html

Thanks for the suggestion.

(should show up later today... my web server having some problem i
think)

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

One major thing is that he adopted the Kinesis keyboard.

The Kinesis keyboard fixed several keyboard design problems. I came to
know about Kinesis in maybe 1993 and touched in it stores (Fry's
Electronics). I think it is excellent.

i have photo and commentary here:
http://xahlee.org/emacs/keyboards.html

see also:
Keyboard Hardware Design Flaws
http://xahlee.org/emacs/keyboard_problems.html

afaik, kinesis hold the patent on the keyboard design. I think that's
why u dont see for example microsoft introduce mod keys at thumb
position or non-jagged arrangement of the keys of their ego keyboards
and new designs.

i think i might patent my ergonomic shortcut layout for text editing
too. At least, others can't patent it cause i did it and published it.

one thing i think is a obvious design flaw in Kinesis is that the
functions keys are a row of rubbish buttons instead of keys, and that
they are uniformally laid out in a row as opposed to 4 groups of keys.
The button style hinder user them, and the uniform row hinders touch
typing them.

i've been toying with the idea of actually buying the $250 or $300
keyboard now and then ever since i saw it in early 1990s.. but just
never did. I'm now quite happy with Microsoft's ergonomic split
keyboards.

i'm already using dvorak (since ~1993), and already using a rather
radical keybinding set in emacs... i'm sure getting myself Kinesiss
will officially qualify me as isnane and put me in more odds with the
common people or even the tech geekers.

  Xah
∑ http://xahlee.org/

☄

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

[Lennart Borgman (gmail)]

Xah Lee wrote:
> On Sep 22, 5:16 am, "Lennart Borgman (gmail)"
>> 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
> 
> Gosh, in every thread that relates to keybinding, you post about
> sticky keys, as if insisting that it is the ultimate solution. Kinda
> getting annoying! =(^o^)=
> 
> (and i was shocked that in a discussion with you about a month or 2
> ago here, despite all your enthus about emacs keybinding as done in
> your EmacsW32, you have no familiarity on how keyboard shorcuts on the
> Mac is like)

Maybe I should wear a warning flag for all my ignorances then ... ;-)

> ... alright, i'm adding the sticky suggestion here:
> http://xahlee.org/emacs/emacs_pinky.html
> 
> Thanks for the suggestion.

Thanks, that was what I wanted.

> (should show up later today... my web server having some problem i
> think)
> 
>> 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.
> 
> One major thing is that he adopted the Kinesis keyboard.

This is what Alex has written there:

  RepeatedStrainInjury – saw a doctor, started physiotherapy on
  2002-02-05. I bought a Kinesis keyboard. I used little programs that
  forced me to take a lot of breaks. It didn’t help.

Note that the Kinesis keyboard and the other things did not help (or
perhaps was not enough) for Alex! He continues

  I stopped therapy
  2002-10-21 and decided to work less, get up more often, started
  practicing Aikido, and no longer work in long shifts. That helped.

More psyical exercise, less sitting computer work -- that was what Alex
believed helped.

And that is what I think is the right way to avoid problems.

We are simply not made for computers (and I wonder if computers are
really made for us ...).

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

[Xah Lee]

On Sep 22, 7:50 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> wrote:
> XahLeewrote:
> > On Sep 22, 5:16 am, "Lennart Borgman (gmail)"
> >>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
>
> > Gosh, in every thread that relates to keybinding, you post about
> > sticky keys, as if insisting that it is the ultimate solution. Kinda
> > getting annoying! =(^o^)=
>
> > (and i was shocked that in a discussion with you about a month or 2
> > ago here, despite all your enthus about emacs keybinding as done in
> > your EmacsW32, you have no familiarity on how keyboard shorcuts on the
> > Mac is like)
>
> Maybe I should wear a warning flag for all my ignorances then ... ;-)
>
> > ... alright, i'm adding the sticky suggestion here:
> >http://xahlee.org/emacs/emacs_pinky.html
>
> > Thanks for the suggestion.
>
> Thanks, that was what I wanted.
>
> > (should show up later today... my web server having some problem i
> > think)
>
> >> 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.
>
> > One major thing is that he adopted the Kinesis keyboard.
>
> This is what Alex has written there:
>
>   RepeatedStrainInjury – saw a doctor, started physiotherapy on
>   2002-02-05. I bought a Kinesis keyboard. I used little programs that
>   forced me to take a lot of breaks. It didn’t help.
>
> Note that the Kinesis keyboard and the other things did not help (or
> perhaps was not enough) for Alex! He continues
>
>   I stopped therapy
>   2002-10-21 and decided to work less, get up more often, started
>   practicing Aikido, and no longer work in long shifts. That helped.
>
> More psyical exercise, less sitting computer work -- that was what Alex
> believed helped.
>
> And that is what I think is the right way to avoid problems.

of course, the best way to stop Repeated Strain Injury is to stop or
lessen the activity that caused it. This applies to typing, tennis
elbow, guitar fingers, piano wrist, for examples.

however, as a advice or solution, that is really not a solution. You
know how there's a story about Gordian Knot. The juice of story goes,
whoever manages to untie the knot would become the king, and there
comes this joe who did it by simply cutting it with his sword, and he
became the king.

Logically, that's called cheating.

In a similar way, when we discuss solutions to keyboard typing induced
RSI, the implicit premise is that we still need to type, or that we
cannot afford to type less. Whoever solves this problem will become
the king. Then, Xah Lee says: “just stop typing!”. And whoa, he solved
a century old problem for all programers.

> We are simply not made for computers (and I wonder if computers are
> really made for us ...).

just for the sake of debate... note that nor are we made to read
written texts, or even holding the pen.

of course, you are making a lose remark, giving a sense that typing or
keyboard is a artificial activity of this century, not something more
natural such as walking, talking, or sitting as we human animals do
for thousands of years. However, what i'm pointing out is that, this
point of view is not necessarly useful when examed critically. To wit,
reading written language in printed books or onscreen, or wielding and
writing with pen, are not natural activities. Nor are using
chopsticks, driving a car. The gist is that, thru technology, may it
be as ancient as chopsticks or operating a abacus, to writing with
ball-point-pen, to today's such as typing on computer keyboard or
using a mouse, are simply part of the activity we have adapted thru
inevitable technological advances in society. The un-naturalness in
these activities is a matter of degree, not something black and white.

in hunter-gathering age, running, shooting with bows and arrows, are
natural activity. When we advanced to agricultural society, it is a
form of un-naturalness. When we advanced into building concrete
houses, massive political organization of kings and armies, it's more
un-natural. In today's info age, we see these past un-naturalness that
requires physical exertion as rather natural, but actually it's just a
matter of degree. Perhaps in next 100 years where computer-implants
and mechanical limbs are popular, then perhaps computer keyboard
typing of today would be seen as natural.

  Xah
∑ http://xahlee.org/

☄

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

[Lennart Borgman (gmail)]

Xah Lee wrote:
> On Sep 22, 7:50 am, "Lennart Borgman (gmail)"
>> This is what Alex has written there:
>>
>>   RepeatedStrainInjury – saw a doctor, started physiotherapy on
>>   2002-02-05. I bought a Kinesis keyboard. I used little programs that
>>   forced me to take a lot of breaks. It didn’t help.
>>
>> Note that the Kinesis keyboard and the other things did not help (or
>> perhaps was not enough) for Alex! He continues
>>
>>   I stopped therapy
>>   2002-10-21 and decided to work less, get up more often, started
>>   practicing Aikido, and no longer work in long shifts. That helped.
>>
>> More psyical exercise, less sitting computer work -- that was what Alex
>> believed helped.
>>
>> And that is what I think is the right way to avoid problems.
> 
> of course, the best way to stop Repeated Strain Injury is to stop or
> lessen the activity that caused it. This applies to typing, tennis
> elbow, guitar fingers, piano wrist, for examples.


Xah, aren't you totally missing the main point? I think the main point
is doing more physical activities.

There is actually nothing that says that only stopping the activity
itself helps.

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

[Xah Lee]

On Sep 23, 8:47 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> wrote:
> Xah Lee wrote:
> > On Sep 22, 7:50 am, "Lennart Borgman (gmail)"
> >> This is what Alex has written there:
>
> >>   RepeatedStrainInjury – saw a doctor, started physiotherapy on
> >>   2002-02-05. I bought a Kinesis keyboard. I used little programs that
> >>   forced me to take a lot of breaks. It didn’t help.
>
> >> Note that the Kinesis keyboard and the other things did not help (or
> >> perhaps was not enough) for Alex! He continues
>
> >>   I stopped therapy
> >>   2002-10-21 and decided to work less, get up more often, started
> >>   practicing Aikido, and no longer work in long shifts. That helped.
>
> >> More psyical exercise, less sitting computer work -- that was what Alex
> >> believed helped.
>
> >> And that is what I think is the right way to avoid problems.
>
> > of course, the best way to stop Repeated Strain Injury is to stop or
> > lessen the activity that caused it. This applies to typing, tennis
> > elbow, guitar fingers, piano wrist, for examples.
>
> Xah, aren't you totally missing the main point? I think the main point
> is doing more physical activities.

Don't think i'm missing the point. Alex's “solution” to his RSI
problem, in his very brief description of 2 paragraphs, in whole:

«RepeatedStrainInjury – saw a doctor, started physiotherapy on
2002-02-05. I bought a Kinesis keyboard. I used little programs that
forced me to take a lot of breaks. It didn’t help.

I stopped therapy 2002-10-21 and decided to work less, get up more
often, started practicing Aikido, and no longer work in long shifts.
That helped.»

and you summarized: And that is what I think is the right way to avoid
problems.

So, if we have to choose one single element between:

(1) get away from computer keyboard more.
(2) do general exercise.

It is (1) that is essential to his “solution”.

What we are doing now is about analysis and reasoning. In the
discussion between us in this subthread, at first i picked out part of
his solution about using the Kinesis keyboard. You corrected me by
saying that it's more about his second paragraph. I agree. Then i
elaborated about getting away from keyboard, and you said “aren't you
totally missing the main point? I think the main point is doing more
physical activities.”. Which, isn't a correct analysis as explained
above.

> There is actually nothing that says that only stopping the activity
> itself helps.

So, for someone with RSI symptom, we can suppose 2 solution:

(1) Stop or lessen the amount of time spent on typing.
(2) Do some amout of typing, but when not typing, do more general
exercise such as akido.

Which one is actually more likely to help? And if we are forced to
choose one, it is undeniable that (1) is the answer.

  Xah
∑ http://xahlee.org/

☄

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

[Lennart Borgman (gmail)]

Xah Lee wrote:
> So, for someone with RSI symptom, we can suppose 2 solution:
> 
> (1) Stop or lessen the amount of time spent on typing.
> (2) Do some amout of typing, but when not typing, do more general
> exercise such as akido.

Yes, that is right.

> Which one is actually more likely to help? And if we are forced to
> choose one, it is undeniable that (1) is the answer.

I think both may be necessary, but I actually think that 2 is the most
important point.

In the acute situation, like with any injury, you have of course to get
away from what is causing the injury.

However in the long run that might not at all be what helps.

>   Xah
> ∑ http://xahlee.org/
> 
> ☄
> 
> 

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

[Xah Lee]

On Sep 23, 9:47 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> wrote:
> XahLeewrote:
> > So, for someone with RSI symptom, we can suppose 2 solution:
>
> > (1) Stop or lessen the amount of time spent on typing.
> > (2) Do some amout of typing, but when not typing, do more general
> > exercise such as akido.
>
> Yes, that is right.

In my previous post, i made a critical typo.

I wrote:
«
(1) Stop or lessen the amount of time spent on typing.

(2) Do some amout of typing, but when not typing, do more general
exercise such as akido.
»

The “Do some amount of typing” should be “Do same amount of typing”.

> > Which one is actually more likely to help? And if we are forced to
> > choose one, it is undeniable that (1) is the answer.
>
> I think both may be necessary, but I actually think that 2 is the most
> important point.
>
> In the acute situation, like with any injury, you have of course to get
> away from what is causing the injury.
>
> However in the long run that might not at all be what helps.

You are a fool. LOL.

  Xah
∑ http://xahlee.org/

☄

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

[Lennart Borgman (gmail)]

Xah Lee wrote:
> On Sep 23, 9:47 am, "Lennart Borgman (gmail)"
> <lennart.borg...@gmail.com> wrote:
>> XahLeewrote:
>>> So, for someone with RSI symptom, we can suppose 2 solution:
>>> (1) Stop or lessen the amount of time spent on typing.
>>> (2) Do some amout of typing, but when not typing, do more general
>>> exercise such as akido.
>> Yes, that is right.
> 
> In my previous post, i made a critical typo.
> 
> I wrote:
> «
> (1) Stop or lessen the amount of time spent on typing.
> 
> (2) Do some amout of typing, but when not typing, do more general
> exercise such as akido.
> »
> 
> The “Do some amount of typing” should be “Do same amount of typing”.
> 
>>> Which one is actually more likely to help? And if we are forced to
>>> choose one, it is undeniable that (1) is the answer.
>> I think both may be necessary, but I actually think that 2 is the most
>> important point.
>>
>> In the acute situation, like with any injury, you have of course to get
>> away from what is causing the injury.
>>
>> However in the long run that might not at all be what helps.
> 
> You are a fool. LOL.


Maybe. But I am an optimist. You have some logical elements in your
thinking after all.

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

[Eric S Fraga]

On 2008-09-22, Xah Lee <xah@xahlee.org> wrote:
> Hi Erik Fragga,
>
> On the subject of RSI, perhaps you should use Dvorak, and you'd be
> interested in my article here:

I don't have any RSI problems due to my use of a keyboard.  If you
read my post, I said clearly that mouse usage is what causes me pain.
We are talking (I thought) about text interfaces versus GUIs.

I will add that your proposed key bindings for Emacs, however, would
indeed cause me problems.  Hitting the ALT key requires contortions
not required when using the CTRL key (which I've remapped to be on the
home row of a standard qwerty keyboard).  For that matter, I prefer
"ESC key" to "ALT+key".  I also prefer C-n and C-p to arrows as I
don't have to move my hands from the home row (I use several different
keyboards daily and the arrow keys differ in placement from keyboard
to keyboard, annoyingly).

And I am impressed at how my name changed...

-- 
Eric S Fraga, UCL
GP Key: FFFCF67D F'prnt: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D
BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.

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

[Xah Lee]

On Sep 22, 11:25 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
wrote:
> On 2008-09-22,XahLee<x...@xahlee.org> wrote:
>
> > Hi Erik Fragga,
>
> > On the subject of RSI, perhaps you should use Dvorak, and you'd be
> > interested in my article here:
>
> I don't have any RSI problems due to my use of a keyboard.  If you
> read my post, I said clearly that mouse usage is what causes me pain.
> We are talking (I thought) about text interfaces versus GUIs.
>
> I will add that your proposed key bindings for Emacs, however, would
> indeed cause me problems.  Hitting the ALT key requires contortions
> not required when using the CTRL key (which I've remapped to be on the
> home row of a standard qwerty keyboard).  For that matter, I prefer
> "ESC key" to "ALT+key".  I also prefer C-n and C-p to arrows as I
> don't have to move my hands from the home row (I use several different
> keyboards daily and the arrow keys differ in placement from keyboard
> to keyboard, annoyingly).
>
> And I am impressed at how my name changed...

if you don't know much about keyboard and ergonomics, i recommend
reading the few articles i've written on the issue. A partial list are
these:

• You Should Not Swap Cap Lock With Control
http://xahlee.org/emacs/swap_CapsLock_Ctrl.html

• How To Avoid The Emacs Pinky Problem (advice on using Control key
with emacs)
http://xahlee.org/emacs/emacs_pinky.html

• A Review of Microsoft Natural Keyboards
http://xahlee.org/emacs/ms_keyboard/ms_natural_keyboard.html

• Computer Keyboards Gallery (photos and commentaries on keyboards
design, efficiency, ergonomics)
http://xahlee.org/emacs/keyboards.html

• Keyboard Hardware Design Flaws
http://xahlee.org/emacs/keyboard_problems.html

• The Confusion of Emacs's Keystroke Representation (explains the
notations “C-q C-j”, “\n”, “^J”, “RET” etc.)
http://xahlee.org/emacs/keystroke_rep.html

• Mac OS X Keybinding and Unicode Tips (system-wide keybinding for OS
X)
http://xahlee.org/emacs/osx_keybinding.html

  Xah
∑ http://xahlee.org/

☄

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

[Eric S Fraga]

On 2008-09-23, Xah Lee <xah@xahlee.org> wrote:
> On Sep 22, 11:25 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
> wrote:
>> On 2008-09-22,XahLee<x...@xahlee.org> wrote:
>>
>> > Hi Erik Fragga,
>>
>> > On the subject of RSI, perhaps you should use Dvorak, and you'd be
>> > interested in my article here:
>>
>> I don't have any RSI problems due to my use of a keyboard.  If you
>> read my post, I said clearly that mouse usage is what causes me pain.
>> We are talking (I thought) about text interfaces versus GUIs.
>
> if you don't know much about keyboard and ergonomics, i recommend
> reading the few articles i've written on the issue. A partial list

Your arrogance (exacerbated and accentuated by your apparent inability
to read what others write) is quite amazing.  Depressing, actually.  I
know a great deal about both ergonomics and keyboards.  I really don't
need you to point me to what you've written given your rather narrow
view on most of these issues.

I can't resist (although I probably should :-/ ) adding that I've only
ever encountered C-n, as anything other than next-line, when using a
graphical web browser and, in those cases, it doesn't bring up a "new
document".

I'm bored with this now.  Time to get back to constructive writing
(and I do a *lot* of that with no problems at all with Emacs).

-- 
Eric S Fraga, UCL
BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.

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

[Xah Lee]

On Sep 23, 6:02 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
wrote:
> On 2008-09-23, Xah Lee <x...@xahlee.org> wrote:
>
> > On Sep 22, 11:25 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
> > wrote:
> >> On 2008-09-22,XahLee<x...@xahlee.org> wrote:
>
> >> > Hi Erik Fragga,
>
> >> > On the subject of RSI, perhaps you should use Dvorak, and you'd be
> >> > interested in my article here:
>
> >> I don't have any RSI problems due to my use of a keyboard.  If you
> >> read my post, I said clearly that mouse usage is what causes me pain.
> >> We are talking (I thought) about text interfaces versus GUIs.
>
> > if you don't know much about keyboard and ergonomics, i recommend
> > reading the few articles i've written on the issue. A partial list
>
> Your arrogance (exacerbated and accentuated by your apparent inability
> to read what others write) is quite amazing.  Depressing, actually.  I
> know a great deal about both ergonomics and keyboards.  I really don't
> need you to point me to what you've written given your rather narrow
> view on most of these issues.

The question is, what is the percentage of your knowledge of keyboards
and ergonomics with respect to mine.

> I can't resist (although I probably should :-/ ) adding that I've only
> ever encountered C-n, as anything other than next-line, when using a
> graphical web browser and, in those cases, it doesn't bring up a "new
> document".

Hum? I no unstand.

Do u mean to say, that as far as you know, pressing Ctrl+n invoke a
next-line command in web browsers?

> I'm bored with this now.  Time to get back to constructive writing
> (and I do a *lot* of that with no problems at all with Emacs).

In my effort to educate the tech geekers, i try to be entertaining as
well, so as to elevate you from boredom as well as mine. I hope it is
not a epic fail.

The entertainment bits are inversely proportional to the tech geeker's
level of knowledge and love. Please see:

• (Knowledge + Love) / Disrespectfulness
http://xahlee.org/Netiquette_dir/disrespectfulness.html

For your convenience, the text version is pasted below.
----------------------------------

(Knowledge + Love) / Disrespectfulness

Xah Lee, 2008-07

John wrote:

    Besides your bad english and lack of respect, etiquette and
manners makes it less than rewarding to discuss with you.

The respect in my response to people's writings is based on this
ratio: (knowledge+love)/disrespectfulness exhibited in their posts.
For example, if disrespectfulness is constant, then the greater their
knowledge and love, the greater will be my respect for them. Suppose
the knowledge+love is constant, then the greater their outward
disrespect, will gain greater of my disrepsect. If their knowledge
+love is greater than their outward disrespect, then overall they
still gain my respect. However, if their knowledge+love is less than
their show of disrespectfulness, then i dispise them.

We all have different levels of IQs, environment we grew up, areas of
expertise, weaknesses. No human animal, knows all (in fact in modern
word hardly any human animal knew 1/10^googolplex percent of
knowledge). This is when discussion, comes in. When you know
something, and you sincerely believe you know it, don't be shy. When
you don't know something, don't be a ass. The problem with most
sophomorons, is not knowing the extent of their ignorance. Coupled
with the male nature, they become aggressive in pissing fights.

When i encounter tech geekers, usually they don't know shit of the
subject relative to me, yet they are outright insulting to point of
views outside their community (may it be unix ways; perl, lisp...). If
you don't take the extra mile to kiss their ass when presenting
unorthodox views, they either call you stupid outright, or become
aggressive and hateful, to the point to kick/ban you or whatnot (e.g.
eliminating any possible discussion or explanation i could contribute
or defend of their accusations). That is when, you begin to see
fuckheads and motherfucks sprinkled in my writings.

O, i almost forgot, you wrote: «Besides your bad english....».

The vexing level of my english, is proportional to the number of
grammar pundits in the world (you can see them slaving in
alt.usage.english, for example). When society ceases to be influenced
by these morons, my english might become something you would
characterize as orthodox. (See: Language and English.)

The above is originally posted to newsgroup “comp.lang.lisp”.

2008-08-24 Addendum

Q: After having worked through most of your web site, and hence I came
across the “Disrespectfulness” essay. I do have a question: How would
you see valid value ranges for the Knowledge, Love, and
Disrespectfulness parameters? Thanks for sharing.

A:

It's just a general sense... that essay roughly describes my reactions
in newsgroups. As such, probably not worth digging into.

Knowledge means computer lang knowledge, protocols, OS, systems... or
it could be in any academic area like economics, sociology, history...
or even non-academic ones like business experiences, running a
company, managing a shop, knowing about gardening, fishing, sports,
good restaurants of a city ... all sorts.

Love is the love of other people in the most basic sense.... captured
in this quote:

    «The best index to a person's character is (a) how he treats
people who can't do him any good, and (b) how he treats people who
can't fight back. —Abigail Van Buren↗»

Disrespectfulness is any of rudeness, male aggression, etc.

My “knowledge & love” is inspired by my favorite author Bertrand
Russell's essay titled “What I Believe”. Excerpt:

    «The good life is one inspired by love and guided by knowledge.»

    «Knowledge and love are both indefinitely extensible; therefore,
however good a life may be, a better life can be imagined. Neither
love without knowledge, nor knowledge without love can produce a good
life. In the Middle Ages, when pestilence appeared in a country, holy
men advised the population to assemble in churches and pray for
deliverance; the result was that the infection spread with
extraordinary rapidity among the crowded masses of supplicants. This
was an example of love without knowledge. The late War afforded an
example of knowledge without love. In each case, the result was death
on a large scale.»

  Xah
∑ http://xahlee.org/

☄

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

[Michael Ekstrand]

Xah Lee <xah@xahlee.org> writes:
> On Sep 23, 6:02 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
> wrote:
>> On 2008-09-23, Xah Lee <x...@xahlee.org> wrote:
>>
>> > On Sep 22, 11:25 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
>> > wrote:
>> >> On 2008-09-22,XahLee<x...@xahlee.org> wrote:
>>
>> >> > Hi Erik Fragga,
>>
>> >> > On the subject of RSI, perhaps you should use Dvorak, and you'd be
>> >> > interested in my article here:
>>
>> >> I don't have any RSI problems due to my use of a keyboard.  If you
>> >> read my post, I said clearly that mouse usage is what causes me pain.
>> >> We are talking (I thought) about text interfaces versus GUIs.
>>
>> > if you don't know much about keyboard and ergonomics, i recommend
>> > reading the few articles i've written on the issue. A partial list
>>
>> Your arrogance (exacerbated and accentuated by your apparent inability
>> to read what others write) is quite amazing.  Depressing, actually.  I
>> know a great deal about both ergonomics and keyboards.  I really don't
>> need you to point me to what you've written given your rather narrow
>> view on most of these issues.
>
> The question is, what is the percentage of your knowledge of keyboards
> and ergonomics with respect to mine.

More important in this context is the fact that his knowledge of his
specific RSI problems and their solutions is much higher than yours.  He
mentioned specific ways in which he finds your "ergonomic" layout to be
more painful than his setup.  He also mentioned that his most
substantial problem is with the mouse, *not* the keyboard, a point which
you entirely ignored.  Telling people your opinions on their keyboard
setup does not accomplish anything productive or constructive when their
keyboard configuration is just fine and the mouse causes them pain.

>> I can't resist (although I probably should :-/ ) adding that I've only
>> ever encountered C-n, as anything other than next-line, when using a
>> graphical web browser and, in those cases, it doesn't bring up a "new
>> document".
>
> Hum? I no unstand.
>
> Do u mean to say, that as far as you know, pressing Ctrl+n invoke a
> next-line command in web browsers?

He means that it doesn't create a new document.  In graphical web
browsers it typically opens a new browser window, frequently viewing
your home page.  Similar to a new document, yes, but not the same thing.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.

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

[Xah Lee]

> More important in this context is the fact that his knowledge of his
> specific RSI problems and their solutions is much higher than yours.

I didn't consider him sincere, knowledgable, or respectful. Remember
my article about “(Knowledge + Love) / Disrespectfulness”?
( http://xahlee.org/Netiquette_dir/disrespectfulness.html )

So, all things considered, i considered him, based on his couple of
messages, that he's like some highschool boy trying do a pissing
fight. I embraced it, as you can see.

> mentioned specific ways in which he finds your "ergonomic" layout to be
> more painful than his setup.

Yes. One could interprete a highschool boy's retorts as meaningful and
dig into. The question is, do you really want to defend this? If so,
let me know. I'll detail the reasons why i think what i think on his
messages or yours.

> He also mentioned that his most
> substantial problem is with the mouse, *not* the keyboard, a point which
> you entirely ignored.

See above. But also, please note that the discussion was about a
criticism on emacs *scratch*. Sure, sometimes the topic digress.
However, there are good or bad digressions. For example, is the
digression natural, all agreed, consentual, mutual? Is the digression
relevant? Is it worthwhile?

For example, is it worthwhile for you digress by defending that his
mentioning of RSI and mouse is in fact a topic that we should digress
into?

One is free to digress of course. So, since he mentioned RSI, i choose
to digress on my keyboarding advises, and meanwhile, ignored his
mentioning of the mouse.

If you like, i can digress into the mouse, such as what mouses i use,
my mousing habits, my thoughts on the ergonomicality of mouses, and in
general pointing devices, the history of the mouse, the models of
mouse i've used since 1991, etc.

> Telling people your opinions on their keyboard
> setup does not accomplish anything productive or constructive when their
> keyboard configuration is just fine and the mouse causes them pain.

Yes. Telling me your opinion about a behavior you thought i had
doesn't help on the issue of the *scratch* buffer.

Can you see?

> > Do u mean to say, that as far as you know, pressing Ctrl+n invoke a
> > next-line command in web browsers?
>
> He means that it doesn't create a new document.  In graphical web
> browsers it typically opens a new browser window, frequently viewing
> your home page.  Similar to a new document, yes, but not the same thing.

Huh?

In just about all major browsers (safari, firefox, opera, and prob
IE), you can set it to open a empty page. What u talking about?

Also, the discussion about Ctrl+n originated from my remark that Ctrl
+n is familiar to all programers, in the context of discussing
stardard UI. Just because you have installed Firefox plugin that
modifies default behavior, or just because you are one of those
perhaps less than 0.01% in human animal society who actually uses a
text-based browser, it does not mean Ctrl+n behaves your modified way
in general or that people are not familiar with such a user interface.

I suggest you horn your skills in critical thinking. You could start
by reading Wikipedia article:
 http://en.wikipedia.org/wiki/Critical_thinking

Alternatively, i suggest you put time to think about tech geeker's
behavior in newsgroups. I have written several articles about it. See
here for a index:

Netiquette Anthropology
http://xahlee.org/Netiquette_dir/troll.html

  Xah
∑ http://xahlee.org/

☄

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

[Eric S Fraga]

On 2008-09-24, Xah Lee <xah@xahlee.org> wrote:
>> More important in this context is the fact that his knowledge of his
>> specific RSI problems and their solutions is much higher than yours.
>
> I didn't consider him sincere, knowledgable, or respectful. Remember

Thanks a lot.  I initially responded sincerely and, I thought,
respectfully.  You subsequently responded, ignoring everything I had
said and I simply pointed this out to you.

> So, all things considered, i considered him, based on his couple of
> messages, that he's like some highschool boy trying do a pissing
> fight. I embraced it, as you can see.

Thanks.  I feel a lot younger now!  (you could, of course, do a simple
web search and you'll see that I am not that young, unfortunately ;-)

>> He also mentioned that his most
>> substantial problem is with the mouse, *not* the keyboard, a point which
>> you entirely ignored.
>
> See above. But also, please note that the discussion was about a
> criticism on emacs *scratch*. Sure, sometimes the topic digress.

No, at that point, you brought up people wanting to use text modes
instead of graphical interfaces.  I replied that I use text interfaces
because of RSI problems with the mouse.  You then said that I should
use more a more _modern_ key binding set for Emacs.  I responded to
say that this would exacerbate my RSI.  You didn't like this.  Tough.

-- 
Eric S Fraga, UCL
BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.

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

[Giorgos Keramidas]

On Wed, 24 Sep 2008 09:31:07 +0100, Eric S Fraga <ucecesf@eeepc.chemeng.ucl.ac.uk> wrote:
>On 2008-09-24, Xah Lee <xah@xahlee.org> wrote:
>> So, all things considered, i considered him, based on his couple of
>> messages, that he's like some highschool boy trying do a pissing
>> fight. I embraced it, as you can see.
>
> Thanks.  I feel a lot younger now!  (you could, of course, do a simple
> web search and you'll see that I am not that young, unfortunately ;-)

Xah was probably feeling slightly less lucky than the average Google
user (the first hit is your personal web page at chemeng.ucl.ac.uk) :-)

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

[Alexey Pustyntsev]

Hi Eric!

Please, don't feed this troll. He is a paranoid mental masturbator who
needs serious medical treatment. This is just a waste of time, unless
you are a qualified psychiatrist willing to help the poor thing.

Eric S Fraga <ucecesf@eeepc.chemeng.ucl.ac.uk> writes:

> No, at that point, you brought up people wanting to use text modes
> instead of graphical interfaces.  I replied that I use text interfaces
> because of RSI problems with the mouse.  You then said that I should
> use more a more _modern_ key binding set for Emacs.  I responded to
> say that this would exacerbate my RSI.  You didn't like this.  Tough.
>
> -- 
> Eric S Fraga, UCL
> BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.
>

-- 
Rgds
Alexey

Today is Boomtime, the 48th day of Bureaucracy in the YOLD 3174

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

[Andreas Politz]

Alexey Pustyntsev wrote:
> Hi Eric!
> 
> Please, don't feed this troll. He is a paranoid mental masturbator who
> needs serious medical treatment. This is just a waste of time, unless
> you are a qualified psychiatrist willing to help the poor thing.

Why do you say that?

> 
> Eric S Fraga <ucecesf@eeepc.chemeng.ucl.ac.uk> writes:
> 
>> No, at that point, you brought up people wanting to use text modes
>> instead of graphical interfaces.  I replied that I use text interfaces
>> because of RSI problems with the mouse.  You then said that I should
>> use more a more _modern_ key binding set for Emacs.  I responded to
>> say that this would exacerbate my RSI.  You didn't like this.  Tough.
>>
>> -- 
>> Eric S Fraga, UCL
>> BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.
>>
> 

-ap

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

[Xah Lee]

On Sep 24, 1:31 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
wrote:
> On 2008-09-24, Xah Lee <x...@xahlee.org> wrote:
>
> >> More important in this context is the fact that his knowledge of his
> >> specific RSI problems and their solutions is much higher than yours.
>
> > I didn't consider him sincere, knowledgable, or respectful. Remember
>
> Thanks a lot.  I initially responded sincerely and, I thought,
> respectfully.  You subsequently responded, ignoring everything I had
> said and I simply pointed this out to you.
>
> > So, all things considered, i considered him, based on his couple of
> > messages, that he's like some highschool boy trying do a pissing
> > fight. I embraced it, as you can see.
>
> Thanks.  I feel a lot younger now!  (you could, of course, do a simple
> web search and you'll see that I am not that young, unfortunately ;-)
>
> >> He also mentioned that his most
> >> substantial problem is with the mouse, *not* the keyboard, a point which
> >> you entirely ignored.
>
> > See above. But also, please note that the discussion was about a
> > criticism on emacs *scratch*. Sure, sometimes the topic digress.
>
> No, at that point, you brought up people wanting to use text modes
> instead of graphical interfaces.  I replied that I use text interfaces
> because of RSI problems with the mouse.  You then said that I should
> use more a more _modern_ key binding set for Emacs.  I responded to
> say that this would exacerbate my RSI.  You didn't like this.  Tough.

Dear Doctor Eric Silly,

Your first entrace to this thread, is this, i quote in whole:

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

This snippet, in its writing style and diction, its content, its
beliefs, is typical of a juvenile tech geeker. You can find it in
numbers daily at slashdot.org .

In one sentence, in macho style, it seems to sneer at the million of
dollars of successful commercial corps (such as Microsoft, Google,
Apple) put into user interface studies and the software they produce.

It even says, like a kindergardner bragging, that “and often the
underlying OS doesn't even matter.”!!!

Then, there's tech geeking juvenile slang: “'nuff said.”. Like: “you
are stupid, 'nuff said!”.

Then it ends in a sentence to suggest to me about switch-to-buffer,
using a obfuscated notation “^xb”, apparantly aware or ignoring the
fact that i criticized this particular method in my article.

So, if this Doctor Erick is not a tech geeking moron, who is?

Maybe we could shake hands now... but if there are still issues and
questions, even to the matter of whether which of us has superior
knowledge about keyboarding and ergonomics, i'd be happy to answer.

  Xah
∑ http://xahlee.org/

☄

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

[Nikolaj Schumacher]

Xah Lee <xah@xahlee.org> wrote:

> Just because you have installed Firefox plugin that
> modifies default behavior, or just because you are one of those
> perhaps less than 0.01% in human animal society who actually uses a
> text-based browser, it does not mean Ctrl+n behaves your modified way
> in general

You should add the 6-8% of Mac users to that list of exceptions, where
Ctrl+n does behave that way in general.


regards,
Nikolaj Schumacher

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

[Xah Lee]

On Sep 24, 2:28 am, Nikolaj Schumacher <m...@nschum.de> wrote:
> XahLee<x...@xahlee.org> wrote:
> > Just because you have installed Firefox plugin that
> > modifies default behavior, or just because you are one of those
> > perhaps less than 0.01% in human animal society who actually uses a
> > text-based browser, it does not mean Ctrl+n behaves your modified way
> > in general
>
> You should add the 6-8% of Mac users to that list of exceptions, where
> Ctrl+n does behave that way in general.

Hum? I don't know what you are saying.

After a while coming back to your message, i think i got it. You mean,
basically, the Cmd key's function on the mac is roughly equivalent to
Windows's Ctrl. So, Ctrl+n doesn't actually crate a new something, it
is actually Cmd+n. Ctrl+n on the mac in fact does nothing in most
browsers.

Is that what you are saying? It's quite silly you know?

In case you seriously thought that point is worth mentioning, let me
answer about that then.

Of the common standaard keyboard shortcut keys for Open (n), Close
(w), Save (s), Save As (S), Print (p), Select All (a), Copy (c), Cut
(x), Paste (v), Undo (z), on Windows and Linux it's used together with
modifier Ctrl. On Mac, it's the Command key. These command and letter
pairs are a standard in practice, ever since Microsoft Windows
borrowed much of Mac GUI since mid 1990s, and more so post 2000, and
ever since Linux becomes somewhat popular as a desktop and KDE/Gnome
borrowed wholesale of Windows UI.

To say that these commands and keys on the Mac is actually different
than on Windows/Linux, is inappropriate in our context. As a analogy,
emacs on Windows, Mac, Linuxes, uses different modifier for Meta and
have slightly different look, but it is not sufficient to say that
emacs in one particular OS is emacs while others are not. Similarly,
in our context, when i say Ctrl+n is a standard or familiar with most
software users, you can't argue that Mac is a exception just because
it uses Cmd instead of Ctrl.

Btw, for those who wants to understand the differece of Mac and PC
keyboards, and their difference in usage since about 1995 to today,
see:

Difference Between Apple and PC keyboards
http://xahlee.org/emacs/apple_pc_kb_diff.html

  Xah
∑ http://xahlee.org/

☄

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

[Nikolaj Schumacher]

Xah Lee <xah@xahlee.org> wrote:

> After a while coming back to your message, i think i got it. You mean,
> basically, the Cmd key's function on the mac is roughly equivalent to
> Windows's Ctrl. So, Ctrl+n doesn't actually crate a new something, it
> is actually Cmd+n. Ctrl+n on the mac in fact does nothing in most
> browsers.
>
> Is that what you are saying? It's quite silly you know?

You're looking at my note from the wrong direction.

First of all, we need to clear something up:  Ctrl+n on the mac does in
fact do something.  It moves the cursor to the next line in many apps.
That includes browsers (I've tested Firefox, Safari and Camino).

Ctrl+d, Ctrl+p, Ctrl+f, Ctrl+b, Ctrl+a, Ctrl+e and Ctrl+k work as well.

> Similarly, in our context, when i say Ctrl+n is a standard or
> familiar with most software users, you can't argue that Mac is a
> exception just because it uses Cmd instead of Ctrl.

My argument goes the other way around.

I'm not saying Ctrl+n for "new thing" is not standard.  I'm just saying
that Ctrl+n for "next line" is /also/ a standard, even if less common.
(But more common than 0.01%, even in browsers)

Clearly those two clash, except on the Macs, where one of them was
conveniently moved to another modifier.  It's not silly to bring that up,
because it shows that both standards have /some/ relevance in modern
systems.

I hope you're getting what I'm saying.  It's not that I don't associate
Ctrl+n with "new window" (just because it's Cmd+n on my Mac), it's that
I somewhat associate it with both commands.  The same goes for a bunch
of other people, who aren't "cave-dwelling, text-browser-using tech
geekers".

Of course, there's nothing wrong with picking "new thing" for Ctrl+n,
because it's (by far) the most popular choice.  But you can't simply
dismiss the other meaning as obscure, especially not given Emacs' current
audience, where the "next line" interpretation is arguable more common
than anywhere else.



regards,
Nikolaj Schumacher

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

[Xah]

On Sep 24, 10:15 am, Nikolaj Schumacher <m...@nschum.de> wrote:
> Xah Lee <x...@xahlee.org> wrote:
> > After a while coming back to your message, i think i got it. You mean,
> > basically, the Cmd key's function on the mac is roughly equivalent to
> > Windows's Ctrl. So, Ctrl+n doesn't actually crate a new something, it
> > is actually Cmd+n. Ctrl+n on the mac in fact does nothing in most
> > browsers.
>
> > Is that what you are saying? It's quite silly you know?
>
> You're looking at my note from the wrong direction.
>
> First of all, we need to clear something up:  Ctrl+n on the mac does in
> fact do something.  It moves the cursor to the next line in many apps.
> That includes browsers (I've tested Firefox, Safari and Camino).
>
> Ctrl+d, Ctrl+p, Ctrl+f, Ctrl+b, Ctrl+a, Ctrl+e and Ctrl+k work as well.


> > Similarly, in our context, when i say Ctrl+n is a standard or
> > familiar with most software users, you can't argue that Mac is a
> > exception just because it uses Cmd instead of Ctrl.
>
> My argument goes the other way around.
>
> I'm not saying Ctrl+n for "new thing" is not standard.  I'm just saying
> that Ctrl+n for "next line" is /also/ a standard, even if less common.
> (But more common than 0.01%, even in browsers)
>
> Clearly those two clash, except on the Macs, where one of them was
> conveniently moved to another modifier.  It's not silly to bring that up,
> because it shows that both standards have /some/ relevance in modern
> systems.
>
> I hope you're getting what I'm saying.  It's not that I don't associate
> Ctrl+n with "new window" (just because it's Cmd+n on my Mac), it's that
> I somewhat associate it with both commands.  The same goes for a bunch
> of other people, who aren't "cave-dwelling, text-browser-using tech
> geekers".
>
> Of course, there's nothing wrong with picking "new thing" for Ctrl+n,
> because it's (by far) the most popular choice.  But you can't simply
> dismiss the other meaning as obscure, especially not given Emacs' current
> audience, where the "next line" interpretation is arguable more common
> than anywhere else.

I disagree the above is a good argument.

The Ctrl+n behavor on the mac, is limited to text editing contexts.
So, in fact, Ctrl+n does not do anything in any app, unless your are
in a text editing mode. For example, in Safari, Ctrl+n doesn't do
anything unless you are in a text form or text field, then it does
behave like a down arrow key.

These emacs based editing shortcuts on the Mac, is a special class of
keyboard shortcuts, quite distinct from typical shortcuts that control
apps. They appeared in Mac OS X only in about 2004. They do not always
work even today. The work only for apps written using the Cocoa Text
System. (practically, there are few mainstream apps this doesn't work.
I don't remember, but i think it didn't work in Firefox 2. Haven't
tested in Firefox 3 neither. It does not even in Apple's apps such as
Finder and iTune.)

These emacs-based editing shortcuts on the Mac, are also not widely
known even among Mac users. (am not even sure it is officially
documented somewhere in Help) They are not listed in any app's
graphical menu as far as i know.

So, i don't think this Mac case takes away any force in saying that
Ctrl+n for New is familiar and a universal practical standard in UI.

-------

It might be of interest to readers here that you can actually
customize these OS wide. For a complete tutorial, see:

• How To Create Your Own Keybinding In Mac Os X
http://xahlee.org/emacs/osx_keybinding.html

  Xah
∑ http://xahlee.org/

☄

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

[Nikolaj Schumacher]

Xah Lee <xah@xahlee.org> wrote:

> Do u mean to say, that as far as you know, pressing Ctrl+n invoke a
> next-line command in web browsers?

In mine it does.  Doesn't it in yours?  :)

regards,
Nikolaj Schumacher

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

[harven]

Xah Lee <xah@xahlee.org> writes:

> Do u mean to say, that as far as you know, pressing Ctrl+n invoke a
> next-line command in web browsers?

I am using Firefox, and indeed, C-n goes to next-line, because I have
installed the firemacs extension. If you are interested in emacs-like
keyboard management with Firefox, you should give it a try:
https://addons.mozilla.org/en-US/firefox/addon/4141

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

[Xah Lee]

On Sep 23, 2:16 pm, harven <har...@free.fr> wrote:
> XahLee<x...@xahlee.org> writes:
> > Do u mean to say, that as far as you know, pressing Ctrl+n invoke a
> > next-line command in web browsers?
>
> I am using Firefox, and indeed, C-n goes to next-line, because I have
> installed the firemacs extension. If you are interested in emacs-like
> keyboard management with Firefox, you should give it a try:https://addons.mozilla.org/en-US/firefox/addon/4141

Hi Harven,

I, also, have installed firemacs extension, in late 2007 or early
2008. However, i never actually used it once. Then, when i installed
FireFox 3 few months ago, i deinstalled it.

For me, in any instance of time of the day, i have 3 browsers open.

• Firefox. This is my dev browser primarily for my website. Cookies
and Javascript turned off, and with about 3 web dev related extensions
i actively use. Among them is html validator, Web developer,
Flashblock. Other extensions i have but dont use often include, for
example, Screen grab, StumbleUpon, Undo Closed Tabs Button, Firebug,
ColorZilla. These i turned on only when i need to use them, roughly
maybe once a month. They are turned off normally because it saves
quite noticeable time when you open a new window (but not new Tab).

• Opera. This is for general web browsing. This has cookies,
javascript, java, turned off normally. Typically, my web browsing
primarily consists of reading Wikipedia articles. In anytime during
the day, i typically have 10 to 20 Wikipedia articles open, in tabs
around 2 or 3 windows.

• Safari. This is used for browsing sites i actally have a account.
For example, google (various services i use e.g. gmail, google group,
blogger, iGoogle, etc.), yahoo (services i use includes yahoo mail,
yahoo groups, flickr), youtube, youporn, livejournal, financial
websites, etc. This browser has cookies, Javascript, Java on.

About few times a week, i also launch iCab, Camino, Flock. Typically,
these are used when i need to browse random sites that require
Javascript or Flash (most videos) and i don't want to turn them on in
Opera. Also, these are used for web dev as alternative... checking
behavior etc.

How do i manage to switch or memorize all these? In my OS wide
keyboarding system, i have set it up so that one single key press
switches me to previous app. This accounts maybe 50% of my app
switching needs. The other 50%, is done by single app button key
press. i.e. i use a Microsoft ergonomic keyboard that has about 9 app
launching special buttons. These are set to, for example: Desktop,
Safari, Opera, Apple Mail, iTune, Adium (multi protocol IM), Second
Life (virtual world app), Colloquy (irc client). Even that is not
enough. I have F6 set to launch/switch to Firefox, F7 to emacs, F5 to
terminal. Cmd+F7 to Camino browser,  Shift+F7 to Flock browser.

About 30% of time, i press Context Menu key to switch to last app. The
other 30% of time i press F6 or F7 to Firefox or Emacs. The other
maybe 30% i press one of the app launching keys to switch to a
specific app i have in mind.

The rest maybe 10% of time i switch by, in order of most frequetly
used method to less: use Mouse with the Dock, Cmd+Tab or Cmd+Shift
+Tab, QuickSilver (keyboard method of app launching by keyword). (yes,
i kinda need all these ways for different occations)

These app switching ways are in my muscle memory. Also, they change
slightly every few weeks depends on changing need. For example, if i
have a project working on math... that often i need to switch to
Mathematica, GeoGebra, 3D-XplorMath ... or i'm in a session of heavy
graphics editing where i need X/Gimp or InkScape ... etc, i set new
keys to launch/switch to these apps. For example, i used to also have
Cmd+F6 and Shift+F6 to launch different emacs variants such as Emacs
in X-windows, Aquamacs, NeXT Emacs (aka EmacsApp).

The above keyboarding setup and activities, are achieved by using:

• Microsoft Ergonomic Keyboard.
• Microsoft IntelliType keyboard macro app. (comes with the keyboard)
• OS X's Dock and Keyboard control panel (which has a limited way to
set keyboard shortcuts).
• QuickSilver (a typing based launching/switching app (still GUI
though))
• 2 mouses installed. One for each hand. (i've been using 2 mouses
since, maybe 1994. Have always wanted to replace one with pen-device
or roller ball, but never actually did.)

Note also, i have emacs w3m web browser installed (as well as lynx,
btw). Also, i have elisp so that when i press a key on a url in emacs,
it launches me to a specific browser depending on the url.

References and further readings for tech geekers:

• Links To Wikipedia from XahLee.org (lists all links to Wikipedia
from my site (over 4 thousand. For each article i linked, i estimate i
have read 10 more))
http://xahlee.org/wikipedia_links.html

• Lispers and Wikipedia (essay)
http://xahlee.org/emacs/lispers_n_wikipedia.html

• A Review of Microsoft Natural Keyboards (the keyboard i use.
Includes some commentary on IntelliType)
http://xahlee.org/emacs/ms_keyboard/ms_natural_keyboard.html

• Computer Keyboard Gallery (commentary on keyboards, key macros,
keys, ergonomics, efficiency, design)
http://xahlee.org/emacs/keyboards.html

  Xah
∑ http://xahlee.org/

☄

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

[Nikolaj Schumacher]

Cor Gest <cor@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

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

[Xah Lee]

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/

☄

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

[Chetan]

Xah Lee <xah@xahlee.org> writes:

> 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/
>
> ☄
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

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

[Kevin Rodgers]

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

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

[Kevin Rodgers]

Kevin Rodgers wrote:
> Xah Lee wrote:
>> 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))
           ^^^^^^^^^^^^^^^^^^^^

Nikolaj Schumacher's recent message prompted me to check that little
hack, and I see that it's got a typo.  It should be:

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

You might like (auto-save-mode 1) in there as well.

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Xah Lee]

On Sep 24, 12:35 am, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> Kevin Rodgers wrote:
> >XahLeewrote:
> >> 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))
>
>            ^^^^^^^^^^^^^^^^^^^^
>
> Nikolaj Schumacher's recent message prompted me to check that little
> hack, and I see that it's got a typo.  It should be:
>
> (defun switch-to-new-buffer ()
>    "Switch to a new *scratch* buffer."
>    (interactive)
>    (switch-to-buffer (generate-new-buffer "*scratch*"))
>    (setq buffer-offer-save t))
>
> You might like (auto-save-mode 1) in there as well.

A new buffer is not a existing buffer, so the switch in the name is
unfit. Also, since the function's purpose is creating a new *scratch*,
you should have that in the name to reflect the fact.

So, given your code, one step of improvement is to change the name to
new-scratch-buffer or create-scratch-buffer.

But, as i detailed, since scratch is simply a new buffer, and since
now you can create multiple scratches, it ceases to be one special
buffer emacs called *scratch*. So, this comes back to my original
suggestion, that it might simply be better to just have create-new-
buffer. And, if you agree this far, then since you now have a
mechanism to create new buffers proper, and the few emacs developers
agree that *scratch* has problems albeit minor one, we might simply at
this point get rid of the *scratch* because create-new-buffer
completely covers its functionality.

This is exactly what is proposed in my article, alone with code.
See
http://xahlee.org/emacs/modernization_scratch_buffer.html

  Xah
∑ http://xahlee.org/

☄

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

[Kevin Rodgers]

Xah Lee wrote:
> On Sep 24, 12:35 am, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
>> Kevin Rodgers wrote:
>> Nikolaj Schumacher's recent message prompted me to check that little
>> hack, and I see that it's got a typo.  It should be:
>>
>> (defun switch-to-new-buffer ()
>>    "Switch to a new *scratch* buffer."
>>    (interactive)
>>    (switch-to-buffer (generate-new-buffer "*scratch*"))
>>    (setq buffer-offer-save t))
>>
>> You might like (auto-save-mode 1) in there as well.
> 
> A new buffer is not a existing buffer, so the switch in the name is
> unfit. Also, since the function's purpose is creating a new *scratch*,
> you should have that in the name to reflect the fact.

In Emacs, you can create a buffer without making it the current buffer
and/or without displaying it.  Emacs uses the verb "switch" to mean
"display the buffer and select the window in which it is displayed".

> So, given your code, one step of improvement is to change the name to
> new-scratch-buffer or create-scratch-buffer.

Fair enough: switch-to-new-scratch-buffer.

> But, as i detailed, since scratch is simply a new buffer, and since
> now you can create multiple scratches, it ceases to be one special
> buffer emacs called *scratch*.

The *scratch* buffer _is_ special: If you kill it, it is regenerated,
and its major mode is determined by initial-major-mode.  No other buffer
respects that variable.

In contrast, the major mode of the new *scratch*<N> buffers is
determined by default-major-mode.

> So, this comes back to my original
> suggestion, that it might simply be better to just have create-new-
> buffer. And, if you agree this far, then since you now have a
> mechanism to create new buffers proper, and the few emacs developers
> agree that *scratch* has problems albeit minor one, we might simply at
> this point get rid of the *scratch* because create-new-buffer
> completely covers its functionality.

I do not agree that it would be better to eliminate the *scratch* buffer
in deference to a create-new-buffer command.  I do not know which Emacs
developers think *scratch* has problems, or what those alleged problems
are.

You can pry the *scratch* buffer from my cold, dead fingers.  :-)

> This is exactly what is proposed in my article, alone with code.
> See
> http://xahlee.org/emacs/modernization_scratch_buffer.html

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Xah]

On Sep 25, 9:52 pm, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:

> In Emacs, you can create a buffer without making it the current buffer
> and/or without displaying it.

Yes, but that's used in elisp coding only. For interactive use, it is
of little use to create a new buffer and not have it in front.

> The *scratch* buffer _is_ special: If you kill it, it is
> regenerated,

right, but that's being special because it is special. Kinda
tautology.
If you follow my proposal, that specialness of scratch due to its
regenaration is not needed.

> and its major mode is determined by initial-major-mode.
> No other buffer respects that variable.
> In contrast, the major mode of the new *scratch*<N> buffers is
> determined by default-major-mode.

Ok. But when *scratch* buffer is no longer there as my proposal,
perhaps emacs don't need initial-major-mode anymore. (a simplification
without reducing power!) Or, initial-major-mode can still be used for
whatever other purposes it may have had.

in my previous message i said:

«But, as i detailed, since scratch is simply a new buffer, and since
now you can create multiple scratches, it ceases to be one special
buffer emacs called *scratch*.»

Note the word: “ceases”.

really, please have a open mind and really try to see the other side
of the coin.

> I do not agree that it would be better to eliminate the *scratch* buffer
> in deference to a create-new-buffer command.

asides from the above points (which i give a counter now), why do you
not agree?

> I do not know which Emacs
> developers think *scratch* has problems, or what those alleged problems
> are.

In this thread, Alan has expressed such a opinion after lengthy
debate, as well as another (i think it was Nikolaj). They admitted, or
tentatively said, at least, that if scratch is a usability problem, it
is just a minor, trivial one.

Please, have a open mind and read the thread, as opposed to everyone
trying to win a argument and i more or less repeat every part of my
original writing by rephrasing in every reply.

> You can pry the *scratch* buffer from my cold, dead fingers.  :-)

How about this... most, if not all, oppositions to the proposal goes
from the point of view of defending scratch.  How about give me some
reasons why the proposal is not better than the scratch way?

For example, by the proposal, any emacs old time users can simply
create a scratch by a keyboard shortcut assigned to create-new-buffer.
create-new-buffer can create new buffer by initial-major-mode or
default-major-mode, whichever you might think is better. The create-
new-buffer can have a binding of maybe C-x c. It can be used to create
multiple buffers for scratch purposes. If you don't like the
“untitled” name, you could say it should be “*scratch*”. Why do you
not like these? What reason, would you think, that this is not better
than say emacs staying unchanged, or your proposal of switch-to-new-
scratch-buffer?

Following the above train of thought, perhaps than you don't have
objections now? Is it just the “untiled” name that you guys didn't
think is good? Or is it that you guys really think switch-to-new-
scratch-buffer is a better name than create-new-buffer?

  Xah
∑ http://xahlee.org/

☄

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

[Xah Lee]

On Sep 19, 7:35 pm, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
> XahLeewrote:
> > 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

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:

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

  Xah
∑ http://xahlee.org/

☄

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

[Kevin Rodgers]

Xah Lee wrote:
> On Sep 19, 7:35 pm, Kevin Rodgers <kevin.d.rodg...@gmail.com> wrote:
>> XahLeewrote:
>>> 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))
             ^^^^^^^^^^^^^^^^^^^^
Sorry, I meant buffer-offer-save.

>> If it's such a huge problem for 99% of users, you could propose to the
>> maintainers that it be added to files.el
> 
> 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

Here's my attempt at critical thinking:

1. You said that find-file and switch-to-buffer each have problems, so I
wrote a new command that has neither problem.  That is called a
solution.

2. You said that neither function is designed for creating a new
temporary buffer.  That is true of find-file, which can create a new
buffer, but a buffer whose contents are to be persisted i.e. not
temporary.  I think switch-to-buffer _is_ designed for creating a new
temporary buffer, just a buffer that has a user-specified name.

3. You contradict yourself to some degree by complaining that temporary
buffers can be killed without prompting the user about whether and under
what name to save them.  I think it would be clearer if you said "empty"
buffer instead of "temporary".

> If you didn't read the original article, please see:
> 
> http://xahlee.org/emacs/modernization_scratch_buffer.html

I prefer progress to modernization.

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Xah Lee]

On Sep 24, 12:54 am, Kevin Rodgers <kevin.d.rodg...@gmail.com>
> Here's my attempt at critical thinking:
>
> 1. You said that find-file and switch-to-buffer each have problems, so I
> wrote a new command that has neither problem.  That is called a
> solution.

Yes.

> 2. You said that neither function is designed for creating a new
> temporary buffer.  That is true of find-file, which can create a new
> buffer, but a buffer whose contents are to be persisted i.e. not
> temporary.  I think switch-to-buffer _is_ designed for creating a new
> temporary buffer, just a buffer that has a user-specified name.

this i don't  agree. Quote from my article:

«
    * There is no easy, intuitive way to create multiple scratch
buffers. (it is done by using the switch-to-buffer command (C-x b) and
give name that is not one of existing buffers.)

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

More specifically, in different wording now: the problem with switch-
to-buffer for creating new buffer is that it is simply not designed
for it. It is only a side effect. (similar to, say, the unix “touch”
command is used to create new file, and unix “mv” command is used for
renaming, and in unix the boulean operators for “and” (&&) and
“or” (||) are used for program flow... and quite a lot such quirks in
various langs.) Sure, it you can use a hammer as a weapon and various
things but not the right design for something is a problem. More
specifically:

• switch-to-buffer the name does not convey it's use as a create-new-
buffer.

• By using it for the purpose of creating new buffer and as well as
switching buffer, it has multiple purposes. Thes 2 purpsose are
semantically distinct and in practice doesn't mix.

• when user uses switch-to-buffer for creating new buffer, it again,
just like find-file, promp user to type a name. Also, user needs to
give a name not one of existing buffers. The problem with trivial
prompting is well know is UI, especiall its problems can be seen in
Microsoft Windows OS, where every minute it prompts users for this or
that which is quite annoying. A better way, to let user decided to
name something when user needs to.


> 3. You contradict yourself to some degree by complaining that
> temporary buffers can be killed without prompting the user about
> whether and under what name to save them.  I think it would be clearer
> if you said "empty" buffer instead of "temporary".

I'm not sure i understood exactly what u mean.

What i meant in my article or post was that, emacs won't offer save
for buffers not associated with a file. This is so for buffers created
using the switch-to-buffer command.

> I prefer progress to modernization.

The “modernization” is just a descriptive tag. Am not sure exactly
what you mean. Modernization is simply a collective term for emacs
improvements that happens to make emacs more compatible with modern
terminologies, UI sandards. Many tech geekers will perhaps think
“modernization” means “let's make emacs like Microsoft”. No. It is not
the intention nor the goal. (Of interest to note, that it is EXACTLY
Linux's KDE's prominently published manifesto, for example, when it
starts in about 1998.)

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

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

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

Your solution based on switch-to-buffer:

> (defun switch-to-new-buffer ()
>    "Switch to a new *scratch* buffer."
>    (interactive)
>    (switch-to-buffer (generate-new-buffer "*scratch*"))
>    (setq buffer-offer-save t))
>
> You might like (auto-save-mode 1) in there as well.

A new buffer is not a existing buffer, so the switch in the name is
unfit. Also, since the function's purpose is creating a new *scratch*,
you should have that in the name to reflect the fact.

So, given your code, one step of improvement is to change the name to
new-scratch-buffer or create-scratch-buffer.

But, as i detailed, since scratch is simply a new buffer, and since
now you can create multiple scratches, it ceases to be one special
buffer emacs called *scratch*. So, this comes back to my original
suggestion, that it might simply be better to just have create-new-
buffer. And, if you agree this far, then since you now have a
mechanism to create new buffers proper, and the few emacs developers
agree that *scratch* has problems albeit minor one, we might simply at
this point get rid of the *scratch* because create-new-buffer
completely covers its functionality.

This is exactly what is proposed in my article, alone with code.
See
http://xahlee.org/emacs/modernization_scratch_buffer.html

PS thanks for the (setq buffer-offer-save t) in your code. It is a
solution to my kludge in my create-new-buffer code about forcing emacs
to offer save.

  Xah
∑ http://xahlee.org/

☄

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

[Xah Lee]

i wrote:
> PS thanks for the (setq buffer-offer-save t) in your code. It is a
> solution to my kludge in my create-new-buffer code about forcing emacs
> to offer save.

oops, my mistake.

I actually have the line
(setq buffer-offer-save t)
in my code for new-empty-buffer, but emacs still closes the buffer
without saving, seemingly contrary to its doc.

The solution i made, is to create a close-current-buffer which offers
to save.

The snipped of code is here:

   ;; offer to save buffers that are non-empty and modified, even for
non-file visiting buffer. (because kill-buffer does not offer to save
buffers that are not associated with files)
   (when (and (buffer-modified-p)
              (not isEmacsBufferBefore)
              (not (string-equal mode-name "Dired by name"))
              (not (string-equal mode-name "Dired by date"))
              (not (string-equal "" (save-restriction (widen) (buffer-
string)))))
     (if (y-or-n-p
            (concat "Buffer " (buffer-name) " modified; Do you want to
save?"))
       (save-buffer)
       (set-buffer-modified-p nil)))


The complete code, again, is here:
http://xahlee.org/emacs/ergonomic_keybinding_dvorak.el
http://xahlee.org/emacs/ergonomic_keybinding_qwerty.el

  Xah
∑ http://xahlee.org/

☄

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

[rustom]

On Sep 24, 4:42 pm, Xah Lee <x...@xahlee.org> wrote:

> I actually have the line
> (setq buffer-offer-save t)
> in my code for new-empty-buffer, but emacs still closes the buffer
> without saving, seemingly contrary to its doc.

Do you have it on a hook? Like so?

(add-hook 'lisp-interaction-mode-hook (function (lambda () (setq
buffer-offer-save t))))

The above works for me -- asking to save the scratch buffer *if
changed*
Only problem is that fundamental-mode does not AFAIK have a hook.
Wonder why...

Bug? buffer-offer-save

[Xah Lee]

To test this which seems like a bug to me, do this:

eval this code:

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

then call it. You'll have a new buffer. Now type something in it. Now,
go to the menu “File‣Close”.

You'll see that emacs closes the buffer immediately without offering
save.

  Xah
∑ http://xahlee.org/

☄


On Sep 24, 5:51 am, rustom <rustompm...@gmail.com> wrote:
> On Sep 24, 4:42 pm, Xah Lee <x...@xahlee.org> wrote:
>
> > I actually have the line
> > (setq buffer-offer-save t)
> > in my code for new-empty-buffer, but emacs still closes the buffer
> > without saving, seemingly contrary to its doc.
>
> Do you have it on a hook? Like so?
>
> (add-hook 'lisp-interaction-mode-hook (function (lambda () (setq
> buffer-offer-save t))))
>
> The above works for me -- asking to save the scratch buffer *if
> changed*
> Only problem is that fundamental-mode does not AFAIK have a hook.
> Wonder why...

Re: Bug? buffer-offer-save

[Juanma Barranquero]

On Wed, Sep 24, 2008 at 15:33, Xah Lee <xah@xahlee.org> wrote:
> To test this which seems like a bug to me, do this:

> then call it. You'll have a new buffer. Now type something in it. Now,
> go to the menu "File‣Close".
>
> You'll see that emacs closes the buffer immediately without offering
> save.

The docstring for buffer-offer-save says:

  Non-nil in a buffer means always offer to save buffer on exit.
  Do so even if the buffer is not visiting a file.

But File / Close is not exiting, is killing a buffer. That's not
different of just creating a new buffer, typing something on it and
then doing C-x k <ENTER>.

buffer-offer-save is not intended to protect a buffer against killing.
You can use `kill-buffer-query-functions' for that (or some available
packages, like Noah S. Friedman's protbuf.el).

   Juanma

Re: Bug? buffer-offer-save

[Juanma Barranquero]

On Wed, Sep 24, 2008 at 16:31, Juanma Barranquero <lekktu@gmail.com> wrote:

> You can use `kill-buffer-query-functions' for that (or some available
> packages, like Noah S. Friedman's protbuf.el).

Or emacs-lock.el, which is included in the standard distribution.

   Juanma

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

[Kevin Rodgers]

Xah Lee wrote:
> On Sep 24, 12:54 am, Kevin Rodgers <kevin.d.rodg...@gmail.com>
>> Here's my attempt at critical thinking:
>>
>> 1. You said that find-file and switch-to-buffer each have problems, so I
>> wrote a new command that has neither problem.  That is called a
>> solution.
> 
> Yes.
> 
>> 2. You said that neither function is designed for creating a new
>> temporary buffer.  That is true of find-file, which can create a new
>> buffer, but a buffer whose contents are to be persisted i.e. not
>> temporary.  I think switch-to-buffer _is_ designed for creating a new
>> temporary buffer, just a buffer that has a user-specified name.
> 
> this i don't  agree. Quote from my article:
> 
> «
>     * There is no easy, intuitive way to create multiple scratch
> buffers. (it is done by using the switch-to-buffer command (C-x b) and
> give name that is not one of existing buffers.)

We'll have to disagree: I think that is both easy and intuitive.

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

What part of the initial contents of the *scratch* buffer is not clear:

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

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

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

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

Agreed.  I think you should lobby the Emacs maintainers to include 
something like the switch-to-new-buffer command I proposed.  But it
does need to be enhanced to prompt for saving when it is killed.

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

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

>> 3. You contradict yourself to some degree by complaining that
>> temporary buffers can be killed without prompting the user about
>> whether and under what name to save them.  I think it would be clearer
>> if you said "empty" buffer instead of "temporary".
> 
> I'm not sure i understood exactly what u mean.

Temporary objects are those which are not intended to be saved.

> What i meant in my article or post was that, emacs won't offer save
> for buffers not associated with a file. This is so for buffers created
> using the switch-to-buffer command.

Yes, it is a convenient feature.  :-)

>> I prefer progress to modernization.
> 
> The “modernization” is just a descriptive tag. Am not sure exactly
> what you mean. Modernization is simply a collective term for emacs
> improvements that happens to make emacs more compatible with modern
> terminologies, UI sandards. Many tech geekers will perhaps think
> “modernization” means “let's make emacs like Microsoft”. No. It is not
> the intention nor the goal. (Of interest to note, that it is EXACTLY
> Linux's KDE's prominently published manifesto, for example, when it
> starts in about 1998.)

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

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

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

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

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

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Xah]

Kevin Rodgers wrote:

> > «
> >     * There is no easy, intuitive way to create multiple scratch
> > buffers. (it is done by using the switch-to-buffer command (C-x b) and
> > give name that is not one of existing buffers.)
>
> We'll have to disagree: I think that is both easy and intuitive.

What seems to you intuitive is not intuitive to the general text
editing audience. The text editing audience is broad, including all IT
professionals, those in academics. Many of these people, wouldn't have
clude if you ask them to define variable or algorithm or byte. Perhaps
you are thinking these people are stupid. Perhaps when compared to you
as a tech geeker, they are quite ignorant about computers. But the
world is big, there are all walks of life. Many of them are in fact
scientists, engineers, mathematicians, lawers. You wouldn't know shit
if i ask you some elementary math concepts (trust me). Similarly, you
don't know the most elementary thing about laws, engineering, ... all
all sort of fields. One element of User Interface design is that the
user don't have to learn anything in order to use it, as much as
possible.

Emacs has too many unusual ways... (btw, i'm damn repeating myself
again and again and again here... in this thread i've already wrote
paragraph(s) that details this).

Please, have a open mind. Open mind is not easy, you really have to
put effort into it.

For example, let me ask this: have you ever, actually try to look into
the knowledge of User Interface? What it entails? What academic field
in involves? Have you actually read a text book on it? Whats the
latest research on it? Who are the dignitaries in the research? What
are the common, standard, or well known reference for UI?

again i'm repeating, and you may think i sound like ergomaniac, or you
might think i'm bullshitting ... but the opinions expressed here by
tech geekers are really completely ignorant. Ask any UI expert,
researcher, they'll laugh.

The things i say, just about every aspect of this thread's argument,
can be reasonably verified, acertined. But you guys didn't even go up
to the level of question about verification, such as how can we
carried out, etc. You you guys are saying, basically at the level of
“emacs is not Microsoft and emacs should not dumb down”!!

> >     * When the scratch buffer is closed, emacs does not prompt user to
> > save it. This easily causes data loss.
>
> What part of the initial contents of the *scratch* buffer is not clear:
>
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.

See above. One element of software UI design is that it should keep it
to minimal for users having to spend time learning things that is not
directly relevant to her tasks.

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

Again, the discussion, criticism, is not about “Hi guys, do you know a
way so that i can do xyz in emacs?”. It is not about how one
individual can customize emacs to some way.

I have written this again and again... Please see:

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

the faq setion, i quote:

Q: Why don't you make these changes yourself? It is easy.

A: The issue is not about individual's convenience. Let's say you
lobby for greener planet. Then somebody retorts: “why don't you just
plant more trees in your backyard?”.

When i wrote this paragraph:

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

It is one of the items that details a problem of *scratch*, in support
of my proposal. It is not about “how can i, Xah Lee, set emacs so that
the *scratch* buffer start in xyz mode”.

No disrespect, but please perhaps take a course in college about
critical thinking or philosophy:
http://en.wikipedia.org/wiki/Critical_thinking

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

> >     * Emacs does not provide a user level function to create a new
> > buffer. It has menu “File‣Open file...” (a wrapper to the find-file
> > command), which immediately prompt user for a full file path. This is
> > annoying. Modern apps's New File command actually just create a new
> > untitled file without prompting, and only when user save it it prompt
> > a file name. If user closes it, it prompts for saving.
> > »
>
> Agreed.  I think you should lobby the Emacs maintainers to include
> something like the switch-to-new-buffer command I proposed.  But it
> does need to be enhanced to prompt for saving when it is killed.

You can help me with it, by filing a bug report on the *scratch*
buffer, borrowing whatever part in my article you think you agree, or
perhaps completely on your own reasons.

As you perhaps know, i've had quite few heated arguments here. This
thread is now 120 messages going to the level of “fuck you's”. About 3
or 4 similar threads on other emacs issues has happend in the past 2
or 3 monhs.

I'm not getting paid to debate. The several items in emacs
modernization proposals doesn't benefit me directly in any way, and it
is not likly to be incorporated into emacs anytime soon.

Instead of suggesting me to do something, why don't you do something
about it? I'm not trying to be rude, and i very much appreciate your
argument here, one of the 3 or 4 in this thread that actually are
sincere and has content, in my opinion.

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

See above.

Also, i have already wrote detailed articles on several aspects of
modernization. Totaly word count is probably over 20 tousand now. For
example, starting with this link:
http://xahlee.org/emacs/modernization.html

it links to other articles that give support or more detail, some part
even include patch.

So, i don't mean this to be directed at you, but for once, instead of
being argumentative and telling me what i should and should not do,
perhaps you can look at my proposals earnestly, pick out whatver part
you think are valuable, file a bug report or start a discussion in
emacs dev list, and share the burden of improving emacs.

> >> 3. You contradict yourself to some degree by complaining that
> >> temporary buffers can be killed without prompting the user about
> >> whether and under what name to save them.  I think it would be clearer
> >> if you said "empty" buffer instead of "temporary".
>
> > I'm not sure i understood exactly what u mean.
>
> Temporary objects are those which are not intended to be saved.

Ok. i see what you are saying.

> > What i meant in my article or post was that, emacs won't offer save
> > for buffers not associated with a file. This is so for buffers created
> > using the switch-to-buffer command.
>
> Yes, it is a convenient feature.  :-)

Emacs not prompting to save for any buffer not associated with a file,
is a major problem. Please check with any respected UI expect...

i don't think it's fruitful for me to keep arguing. I've outlined all
the reasons i can think of in my article. The large discussions in 120
messages thread, almost added no value. ...

maybe to be constructive, how about you giving me a reason why not
prompting for save is good?

ok, let me start... the emacs way of not prompting, you argue that's
because some buffers are just temp, so user don't need to be prompted
because they used it as throwaway ones in the first place. I argue no,
because having user to remember which buffer is temp, or having user
to be aware that the buffer is the *scratch* one, is a burden on the
mind. Of course, it's not a major one, but such little things are
problems. On the other hand, if you follow my proposal, user no longer
need to keep in mind which buffer is meant for temp. As soon as they
call close command, emacs will promp them to save if necessary.

Why do you think this is worse?

> >> I prefer progress to modernization.
>
> > The “modernization” is just a descriptive tag. Am not sure exactly
> > what you mean. Modernization is simply a collective term for emacs
> > improvements that happens to make emacs more compatible with modern
> > terminologies, UI sandards. Many tech geekers will perhaps think
> > “modernization” means “let's make emacs like Microsoft”. No. It is not
> > the intention nor the goal. (Of interest to note, that it is EXACTLY
> > Linux's KDE's prominently published manifesto, for example, when it
> > starts in about 1998.)
>
> Whether a technology or UI convention (not standard) is good has little
> to do with how modern it is, regardless of its sponsor.

to be perfectly logical, that's right, but it kinda disregard common
sense. As a analogy, whether a technology is better does not depend on
whether it is modern. So, irregation, transportations methods in say
1500s, may actually be better than today's. But that's silly.

In software UI, sure, the issue is not that clear cut. However, you
cannot brush away, or in the case of tech geekers, to sneer the UI
designed by successful companies such as Microsoft, Apple, Google.

In other point of view, why not take the perspective and think, to
what degree you are simply being a emacs fanatic and refuse to see
things? Surely, you can imagine how vi users will argue to the death
if you tell them some vi ways is inferior to emacs. Sure, there's a
lot fanaticism. Are you saying fanatism is good? Are you saying that
Microsoft, Apple, Google, etc are mere marketing and exploination of
the dumb?

I get quite worked up when discussiing with you tech geekers...
sometimse i don't care... you guys are just extremely idiotic.

You can quote me on this. Argue with me, argue with all your silly
argument with me and snowball this thread... so perhaps we can get it
to some wider public attention. When the discussion of tech geekers
such as this thread goes to the wide public, perhaps the public at
large, all expert of various fields, will come to know that i'm a
nutcase, but there's one thing they'll agree on: how ignorant and
downright stupid the tech geekers are about UI, critical thinking.

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

...  I tried to punch my keyboard as fast as i could in this reply,
but my fingers got very tired at this point.

Have a good day Kevin. (^_^)

  Xah
∑ http://xahlee.org/

☄

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

[Alan Mackenzie]

Hi, Xah!

Surely this thread of discussion is approaching its end, now.

On Fri, Sep 26, 2008 at 06:28:03AM -0700, Xah wrote:
> Kevin Rodgers wrote:

> > > «
> > >     * There is no easy, intuitive way to create multiple scratch
> > > buffers. (it is done by using the switch-to-buffer command (C-x b) and
> > > give name that is not one of existing buffers.)

> > We'll have to disagree: I think that is both easy and intuitive.

> What seems to you intuitive is not intuitive to the general text
> editing audience. The text editing audience is broad, including all IT
> professionals, those in academics. Many of these people, wouldn't have
> clude if you ask them to define variable or algorithm or byte. Perhaps
> you are thinking these people are stupid. Perhaps when compared to you
> as a tech geeker, they are quite ignorant about computers. But the
> world is big, there are all walks of life. Many of them are in fact
> scientists, engineers, mathematicians, lawers.

We know all this.

> You wouldn't know shit if i ask you some elementary math concepts
> (trust me). Similarly, you don't know the most elementary thing about
> laws, engineering, ... all all sort of fields.

Again, the Emacs developers, certainly the users, collectively have
substantial knowledge in all these fields.

> One element of User Interface design is that the user don't have to
> learn anything in order to use it, as much as possible.

Possibly.  But that element of UI is subordinate to efficiency in things
like Emacs or a modern airliner.

> Emacs has too many unusual ways... (btw, i'm damn repeating myself
> again and again and again here... in this thread i've already wrote
> paragraph(s) that details this).

Yes, Emacs has lots of "unusual" ways, and yes, you are repeating
yourself.  But consider how these "unusual" things have come about;
they've sort of evolved: new things have been tried, and if they've been
good they've become part of Emacs, otherwise they've been discarded and
forgotten about.  Emacs's features aren't random.

> Please, have a open mind. Open mind is not easy, you really have to
> put effort into it.

Please, you too.

> For example, let me ask this: have you ever, actually try to look into
> the knowledge of User Interface? What it entails? What academic field
> in involves? Have you actually read a text book on it? Whats the
> latest research on it? Who are the dignitaries in the research? What
> are the common, standard, or well known reference for UI?

No, I haven't.  Have you?  Emacs, by the very way it has developed, has a
good UI.  If you could cite me any papers written by UI academics about
Emacs, I'd certainly be interested to read them.  I'm sure I could learn
quite a bit.

> again i'm repeating, and you may think i sound like ergomaniac, or you
> might think i'm bullshitting ... but the opinions expressed here by
> tech geekers are really completely ignorant. Ask any UI expert,
> researcher, they'll laugh.

Would they really?  Again, have you seen any relevant publications where
some UI expert has criticised Emacs's interface.  Perhaps we could
improve it.

> The things i say, just about every aspect of this thread's argument,
> can be reasonably verified, acertined.

That's unlikely; unless I've missed something, you haven't yet cited any
authoritative sources.  Mostly, you've just cited your own work.

> But you guys didn't even go up to the level of question about
> verification, such as how can we carried out, etc. You you guys are
> saying, basically at the level of ???emacs is not Microsoft and emacs
> should not dumb down???!!

Yes, indeed.  Many of these other programs are intended to be easy to
learn.  Emacs is intended, instead, to be easy to use.  The aims are
different, so the results are different.

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

> > What part of the initial contents of the *scratch* buffer is not clear:

> > ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> > ;; If you want to create a file, visit that file with C-x C-f,
> > ;; then enter the text in that file's own buffer.

> See above. One element of software UI design is that it should keep it
> to minimal for users having to spend time learning things that is not
> directly relevant to her tasks.

No.  As said above, Emacs is designed to be _efficient_.  One of the
costs of this is that there a lot of little details that users need to
learn.  It's a tradeoff.  People who don't want to put in the learning
time should be using a different editor.

[ .... ]

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

> Again, the discussion, criticism, is not about ???Hi guys, do you know
> a way so that i can do xyz in emacs????. It is not about how one
> individual can customize emacs to some way.

Sorry, Xah, but that is PRECISELY what Emacs is about.  Emacs was
designed explicitly to be as configurable as possible.  That way, each
user can set up her own Emacs to suit her way of working.  I couldn't
work well with Emacs set up the way you're advocating, and I doubt you'd
much like the way I've set up my Emacs.  There are some defaults in Emacs
which, to me, are utterly stupid and crazy, and I've spent many, many
hours trying to explain to the rest of the Emacs developers why some of
their ideas are so stupid.  ;-)  They, in their turn, have defended their
stupidity, and argued that they're the best thing ever invented.  ;-)

There are no absolutes here.  Users vary enormously.

> I have written this again and again...

Yes, you have.  But that doesn't make what you've written any truer or
more valid than if you'd only written it once.

[ .... ]

> It is one of the items that details a problem of *scratch*, in support
> of my proposal. It is not about ???how can i, Xah Lee, set emacs so
> that the *scratch* buffer start in xyz mode???.

It isn't an intrinsic problem with *scratch*.  The problem is in the
relationship between the user and the *scratch* buffer.  The solution is
to configure Emacs until that relationship functions smoothly.

> No disrespect, but please perhaps take a course in college about
> critical thinking or philosophy:
> http://en.wikipedia.org/wiki/Critical_thinking

That is very disrespectful.  There has been no lack of quality critical
thinking from most of the people in this debate.

Would you please now reassure all of us that you have taken, or will take
heed of what we've been telling you, and will incorporate our points into
your thinking, whether you agree with them or not.

> -----------------------

[ .... ]

> > Agreed.  I think you should lobby the Emacs maintainers to include
> > something like the switch-to-new-buffer command I proposed.  But it
> > does need to be enhanced to prompt for saving when it is killed.

> You can help me with it, by filing a bug report on the *scratch*
> buffer, borrowing whatever part in my article you think you agree, or
> perhaps completely on your own reasons.

But you could do this yourself, couldn't you?

> As you perhaps know, i've had quite few heated arguments here. This
> thread is now 120 messages going to the level of ???fuck you's???.
> About 3 or 4 similar threads on other emacs issues has happend in the
> past 2 or 3 monhs.

Indeed.  Remember me telling you a few days ago that using swear words
(even without 6 surrounding question marks ;-) doesn't help you get your
message across?  If we looked at the thread to see who has been using
these bad words most, I wonder who would it be?

> I'm not getting paid to debate. The several items in emacs
> modernization proposals doesn't benefit me directly in any way, and it
> is not likly to be incorporated into emacs anytime soon.

No.  They're never going to be incorporated until somebody implements
them.

> Instead of suggesting me to do something, why don't you do something
> about it? I'm not trying to be rude, and i very much appreciate your
> argument here, one of the 3 or 4 in this thread that actually are
> sincere and has content, in my opinion.

Is there any reason you can't implement these things yourself?  Or is
there some reason you don't want to?

[ .... ]

> > >> 3. You contradict yourself to some degree by complaining that
> > >> temporary buffers can be killed without prompting the user about
> > >> whether and under what name to save them.  I think it would be
> > >> clearer if you said "empty" buffer instead of "temporary".

> > > I'm not sure i understood exactly what u mean.

> > Temporary objects are those which are not intended to be saved.

> Ok. i see what you are saying.

> > > What i meant in my article or post was that, emacs won't offer save
> > > for buffers not associated with a file. This is so for buffers
> > > created using the switch-to-buffer command.

> > Yes, it is a convenient feature.  :-)

> Emacs not prompting to save for any buffer not associated with a file,
> is a major problem. Please check with any respected UI expect...

Emacs also doesn't offer to save the contents of the minibuffer, or any
of a whole host of other buffers.

> i don't think it's fruitful for me to keep arguing. I've outlined all
> the reasons i can think of in my article. The large discussions in 120
> messages thread, almost added no value. ...

Surely you have learnt quite a bit from it?  I've learnt that in many
programs, Ctrl-n creates a new thingy.

> maybe to be constructive, how about you giving me a reason why not
> prompting for save is good?

This is one of those "relationship" things.  For some people, this
prompting would be useful, for many (including Kevin and me) it would be
a nuisance.

> ok, let me start... the emacs way of not prompting, you argue that's
> because some buffers are just temp, so user don't need to be prompted
> because they used it as throwaway ones in the first place. I argue no,
> because having user to remember which buffer is temp, or having user
> to be aware that the buffer is the *scratch* one, is a burden on the
> mind. Of course, it's not a major one, but such little things are
> problems. On the other hand, if you follow my proposal, user no longer
> need to keep in mind which buffer is meant for temp. As soon as they
> call close command, emacs will promp them to save if necessary.

And this prompting to save is an unnecessary and unpleasant nag.  When
you get something like this time after time after time, eventually you
just press the 'n' key automatically, without thinking.  Sooner or later,
you'll do the same when it's prompting you about a valuable buffer.  So
this feature of prompting to save *scratch* would cause you to lose
valuable buffers.  (This has happened to me in other programs.)

> > >> I prefer progress to modernization.

> > > The ???modernization??? is just a descriptive tag. Am not sure
> > > exactly what you mean. Modernization is simply a collective term
> > > for emacs improvements that happens to make emacs more compatible
> > > with modern terminologies, UI sandards. Many tech geekers will
> > > perhaps think ???modernization??? means ???let's make emacs like
> > > Microsoft???. No. It is not the intention nor the goal. (Of
> > > interest to note, that it is EXACTLY Linux's KDE's prominently
> > > published manifesto, for example, when it starts in about 1998.)

My impression of your proposals is that they would make Emacs more like
these other programs, and in so doing make Emacs worse.  For example, it
stands to reason that you reserve short key bindings for frequently used
commands.  Yet you are advocating using a shortest binding (Ctrl-n) for
opening a new buffer, something which is done only rarely.  (I use it, on
average, less than once per Emacs session.)

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

> to be perfectly logical, that's right, but it kinda disregard common
> sense. As a analogy, whether a technology is better does not depend on
> whether it is modern. So, irregation, transportations methods in say
> 1500s, may actually be better than today's. But that's silly.

A better way of looking at it is how long a technology has been developed
for.  Since irrigation has developed over several millennia, you'd expect
it to have attained an optimum by now.  Similarly, the Emacs UI has
developed over ~30 years.  The sort of things you want to put in are
much newer by comparison, and exist mainly in environments where they're
not subject to selection and improvement.

> In software UI, sure, the issue is not that clear cut. However, you
> cannot brush away, or in the case of tech geekers, to sneer the UI
> designed by successful companies such as Microsoft, Apple, Google.

Oh, we could, but there's no need to.  Those UIs have different design
objectives from Emacs's.

> In other point of view, why not take the perspective and think, to
> what degree you are simply being a emacs fanatic and refuse to see
> things? Surely, you can imagine how vi users will argue to the death
> if you tell them some vi ways is inferior to emacs. Sure, there's a
> lot fanaticism. Are you saying fanatism is good? Are you saying that
> Microsoft, Apple, Google, etc are mere marketing and exploination of
> the dumb?

I'm really not sure what you mean by "Emacs fanatic".  Of course the
people on this mailing list will tend to be Emacs fanatics.  You are,
yourself, are you not?

> I get quite worked up when discussiing with you tech geekers...
> sometimse i don't care... you guys are just extremely idiotic.

That's what's known as an "ad hominem attack".  Rather than debating the
issues with people, you attack them personally.

> You can quote me on this. Argue with me, argue with all your silly
> argument with me and snowball this thread... so perhaps we can get it
> to some wider public attention. When the discussion of tech geekers
> such as this thread goes to the wide public, perhaps the public at
> large, all expert of various fields, will come to know that i'm a
> nutcase, but there's one thing they'll agree on: how ignorant and
> downright stupid the tech geekers are about UI, critical thinking.

Just what is it that makes you think that you're right, and we're all
wrong?  That's not a rhetorical question.  After so many people have
disagreed with you on this thread, have you not examined your own
thinking to see whether or not you might have gone wrong somewhere?
Perhaps made a few unwarranted assumptions, and then followed them with
impeccable logic?

> Have a good day Kevin. (^_^)

I'm not Kevin, but you have a good day too, Xah!

>   Xah
> ??? http://xahlee.org/

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Kevin Rodgers]

Xah wrote:
> Kevin Rodgers wrote:
>> Agreed.  I think you should lobby the Emacs maintainers to include
>> something like the switch-to-new-buffer command I proposed.  But it
>> does need to be enhanced to prompt for saving when it is killed.
> 
> You can help me with it, by filing a bug report on the *scratch*
> buffer, borrowing whatever part in my article you think you agree, or
> perhaps completely on your own reasons.

I will not file a bug report, because I don't think there is a bug to
fix.  I have already helped you (more than you have helped yourself)
by trying to implement the features you've requested.

> As you perhaps know, i've had quite few heated arguments here. This
> thread is now 120 messages going to the level of “fuck you's”. About 3
> or 4 similar threads on other emacs issues has happend in the past 2
> or 3 monhs.
> 
> I'm not getting paid to debate.

And I am not getting paid to hack for you.  But I continue to hack, and
you continue to debate.

> The several items in emacs
> modernization proposals doesn't benefit me directly in any way, and it
> is not likly to be incorporated into emacs anytime soon.

This is the crux of the matter: If your proposals don't benefit you,
then absent a chorus of actual users who _would_ benefit from them, the
Emacs maintainers have no evidence that it is worth their effort to
implement them.

I myself have proposed several excellent improvements over the last 10
or 20 years that were not incorporated into Emacs.  :-)

> Instead of suggesting me to do something, why don't you do something
> about it? I'm not trying to be rude, and i very much appreciate your
> argument here, one of the 3 or 4 in this thread that actually are
> sincere and has content, in my opinion.

That is both laughable and rude.  I have done far more than you to
advance your proposal: I have implemented something.

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Xah]

Kevin Rodgers wrote:
> I have already helped you (more than you have helped yourself)
> by trying to implement the features you've requested.

In this thread, the only technical tip i got from is from Alan, about

(kill-line 0)

is equivalent to kill-line-backward.

> by trying to implement the features you've requested.

Lol. In my very first post in this thread, i've given the complete
code for the patch.

See: http://groups.google.com/group/gnu.emacs.help/msg/9b1ce96b9e39e47d

> > Instead of suggesting me to do something, why don't you do something
> > about it? I'm not trying to be rude, and i very much appreciate your
> > argument here, one of the 3 or 4 in this thread that actually are
> > sincere and has content, in my opinion.
>
> That is both laughable and rude.  I have done far more than you to
> advance your proposal: I have implemented something.

See above.

  Xah
∑ http://xahlee.org/

☄

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

[Chetan]

This thread has been going around for a long time. I was spending so
much time reading this that I thought it would be easier to just do it.
I was wondering if this is the right time to post it, then I saw that
some pieces were posted earlier. My changes were slightly different, but
do essentially the same. It isn't that difficult to prevent scratch
buffer from generating agin.

Personally, I am used to the way emacs works. The great thing about
emacs is that anyone can customize the keyboard (and almost everything
else) to be the way I like. After years of use, it is unlikely that my
own key assignments will change.

If anybody is interested, I might post it here.

Chetan

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

[Andreas Politz]

Chetan wrote:
> This thread has been going around for a long time. I was spending so
> much time reading this that I thought it would be easier to just do it.
> I was wondering if this is the right time to post it, then I saw that
> some pieces were posted earlier. My changes were slightly different, but
> do essentially the same. It isn't that difficult to prevent scratch
> buffer from generating agin.
> 
> Personally, I am used to the way emacs works. The great thing about
> emacs is that anyone can customize the keyboard (and almost everything
> else) to be the way I like. After years of use, it is unlikely that my
> own key assignments will change.

That's a nice freudian slip and summarization.

-ap

> If anybody is interested, I might post it here.
> 
> Chetan
> 

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

[Xah]

Andreas Politz wrote:
> > Personally, I am used to the way emacs works. The great thing about
> > emacs is that anyone can customize the keyboard (and almost everything
> > else) to be the way I like. After years of use, it is unlikely that my
> > own key assignments will change.
>
> That's a nice freudian slip and summarization.

Yeah. Many emacsers like to say how they like the way emacs is, yet
they have a lot customization that changes emacs default ways.

All the resistance about the *scratch* we see here, is not really
about some technical issue or UI rational, it's more about a
psychological identity of emacs. “*scratch*” is one of the outstanding
idiosyncracy of emacs. Saying to get rid of it is like admitting a
disease.

Similar things happens with Mac's one-button mouse. For like over a
decade, mac fanatics defend how one button is superior. In the early
1990s when computer are not that popular, one button mouse with its
associated UI does have a ease of use over 2 buttons. But beginning
about late 1990s, it clearly inferior than 2 buttons as home computers
becomes household item and Windows has been accustomized users for a
number of years. During these time, you still see how Apple fanatics
drivel and insist the 1-button is absolutely superior. Since about
maybe 2002, even Apple itself ditched single button mouse, with some
psychological twist the 2-button mouse they produced appear as one
button mouse, and the new design is beautiful, but ergonomically the
most painful and unusable. Lol.

  Xah
∑ http://xahlee.org/

☄

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

[Chetan]

Here are my changes.

;;; Buffer created by this function is a temp buffer. It has no auto-save. It is saved by 
;;; save-some-buffers only with prefix argument, will not be saved by M-x compile etc.
(defun create-new-buffer(name &optional scratch)
  "Generate a new buffer with the specified name in default major mode. There is no auto save for this buffer until a file name is specified. The optional argument scratch specifies if the buffer is for scratch purposes and will not be deleted."
  (let ((buf (generate-new-buffer name)))
    (set-buffer-major-mode buf)
    (switch-to-buffer buf)
    (setq buffer-offer-save (not scratch))))

;;; save-some-buffers C-x s will not save it
;;; save-buffer C-x C-s will ask for a file name if not specified
;;; no auto save since there is no recovery
(defun new-buffer(&optional name mode)
  "Create a new buffer that can be saved later to a file."
  (interactive)
  (let ((default-major-mode (or mode 'text-mode)))
    (create-new-buffer (or (stringp name) "Untitled")))
  (add-hook 'kill-buffer-query-functions 'buffer-kill-query nil t))

(defun new-scratch-buffer(&optional arg)
  "Create a new temporary buffer."
  (interactive)
  (create-new-buffer "*scratch*" t))

(defun choice (msg possibilities)
  (let ((cursor-in-echo-area t) nmsg answer)
    (while (not (memq answer possibilities))
      (setq nmsg (format "%s [%s] " msg 
			(mapconcat (function (lambda(x) (char-to-string (downcase x)))) possibilities "/")))
      (cond (t
	     (message "%s" (propertize nmsg 'face 'minibuffer-prompt))
	     (setq answer (capitalize (read-char-exclusive))))
	    (nil
	     (setq answer (capitalize (string-to-char (read-from-minibuffer nmsg)))))))
    answer))

(defun buffer-kill-choice (msg)
  (let ((possibilities (list ?C ?K ?S)) answer ev)
    (setq answer (choice msg possibilities))
    (cond ((eq answer ?C) (message "Buffer retained.") nil)
	  ((eq answer ?K) t)
	  ((eq answer ?S) (save-buffer) t))))

(defun buffer-kill-query ()
    (cond ((and buffer-offer-save
		(buffer-modified-p))
	   (cond ((and (null buffer-file-name)
		       (> (buffer-size) 0))
		  (buffer-kill-choice (format "Buffer %s has not been saved to a file. Cancel/Kill/Save?"
					      (buffer-name))))
		 (t t)))
	  (t t)))

(when (featurep 'menu-bar)
  (setq menu-bar-buffers-menu-command-entries
	(append menu-bar-buffers-menu-command-entries
		(list (list 'new-buffer
			    'menu-item
			    "Create New Buffer"
			    'new-buffer
			    :help "Create a new buffer and select it in the current window")))))

;;; end

===============
Diff -U3 from 22.3 version of file

--- simple.org.el	
+++ simple.el	
@@ -90,9 +90,8 @@
 			     buffer visible-ok frame)
       (get-next-valid-buffer (nreverse (buffer-list frame))
 			     buffer visible-ok frame)
-      (progn
-	(set-buffer-major-mode (get-buffer-create "*scratch*"))
-	(get-buffer "*scratch*"))))
+      (get-buffer "*scratch*")
+      (current-buffer)))
 
 (defun next-buffer ()
   "Switch to the next buffer in cyclic order."

===============
File buffer.c function Fother_buffer.

  if (NILP (buf))
    {
#if 0
      buf = Fget_buffer_create (build_string ("*scratch*"));
      Fset_buffer_major_mode (buf);
#else
      buf = buffer;
#endif
    }
  return buf;
}

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

[Xah]

am tired arguing with you Alan.

let's assume that there is a gab of knowledge between you and me, and
me having much higher knowledge than you. Then, what do i get in
teaching you thru exchange of messages? You know, when the knowledge
gab is too wide, it is basically impossible to argue with fruitful
outcome. Imagine, a math professor trying to argue some highschooler
who just learned calculus.

Of course, you maybe think the same of me. So, what can i do?

in comp.lang.lisp for example, i argued with lots of Common Lisper
morons, which often results in the same way. i.e. after several
threods of hundred or more messages, basically they think i'm a moron,
i think they are a moron, and it has become a impasse, as if we don't
speak the same language. So, what can i do?

About 3 or 4 times in the past year i have written detailed essay
about the situation, and possible resolutions. I'm not going to spend
some 1 hour to dig them up and spend perhaps another 2 hours to
rephrase and reorganize them so it suites you here... but basically i
proposed each arguer putting down money, hire accomploshied experts,
etc. The result is that, it doesn't help. They either ignore it, or
put their tails between their ass and disappear or say some friendly
words, or whatever ... suffice it to say that some these morons, still
think i'm the moron. (i do think, that many tech geekers, did see get
persuaded by my arguments.) (You can see a related article here:

How Shall I Respond
http://xahlee.org/Netiquette_dir/how_shall_i_respond.html
)

So, what can i do with you or you with me? For sincerity and persuit
of truth, i am willing to pay $50 to have this argument about
*scratch* fully resolved. I propose, that each of us put $50 into this
argument. For nothing else, it is a reasonable proof of sincerity and
effort to get a real quality argument going. How do we carry it out?
that's always been problematic... but we can start, by , i send you
$50 thru paypal, and you send me $50 thru paypal. I trust you, and you
trust me. Then we start to argue really seriously. If in the end, you
find that my argument is stronger, you pay me $50 back. Same me to
you. What do you say?

Also, we could get the money to hire a arbitator who is someone we
both agree to be UI expert and honest.... but this gets more
complicated as to choosing someone, the logistics of it, etc. But i'm
open to suggestions.

also, in good argument, we should formulate precisely exactly what we
are arguing... i'm too tired with this thread now i'm not gonna spend
any more minute to begin such a formulation... perhaps you might want
to start such a suggestion, or we can go with the above $50 exchange
first.

So, if you agree, i send you $50 thru paypal, and post the receipt.
So, once you get it, and others see my “payment sent receipt” posted,
you'd do the same. Then we begin.

Btw Alan, you guys are motherfucking morons, i say. You guys, are
absolutely devoid critical thinking abilities, and lack of knowledge
of UI, and in fact blantantly ignorant plain facts such as emacs
utterly bad design with its keybindings. This paragraph is just so
that you (guys) know what my confience and my view of your guys are,
before we start a formal argument with money down. I want you to know
how cocky i am, so, if you lose at the end, you know you how really
asinine you people are relative to me. (btw, you could try to blame me
that by having this paragraph i wasn't really sincere about the $50
money down to start argument. I am sincere really. Just post a reply,
and if you really indicated that you want to go ahead with this,
you'll get my $50. And, also remember, morons, the final judgement of
who won the argument is not me. It is you. Quote: “If in the end, you
find that my argument is stronger, you pay me $50 back. Same me to
you.”)

btw, i didn't read your last 2 or 3 posts here, Alan. It's not worth
my time. I did spend maybe 10 seconds about the first few paragraphs.
I have exchanged perhaps 15 or more messages with you in the past 6
months. I know quite well what kinda things you'd say. However, if we
began this argument with money down to begin, of course i will read
every detail and think about about it.

> But that element of UI is subordinate to efficiency in things
> like Emacs or a modern airliner.

No. Many emacs ways are in fact inefficient to a very high degree. One
most obvious example is its keyboard shortcut system.

See:
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html

plain text version follows:
--------------------
Why Emacs's Keyboard Shortcuts Are Painful

Xah Lee, 2007-07

A important aspect in designing a keyboard shortcut set, for a
application that has intensive, repetitive, prolonged human-machine
interaction (such as coding and text editing), is to consider
ergonomic principles. Specifically: allocate keyboard shortcuts for
the most frequently used commands, and, the top most frequently used
commands should have most easily-pressed keystrokes. For example, they
should be on the home row.

This article shows why Emacs's keyboard shortcut set is the most
ergonomically bad.
The Swapping of Control and Meta Modifiers

Emacs's keyboard shortcuts is very inefficient. The primary cause is
because, emacs's keyboard shortcuts are designed with a keyboard that
practically has the Ctrl and Alt key positions swapped.
Space-Cadet keyboard-2m

above: The Space-cadet keyboard. (Large Size: Space..._2.jpg
(2003x813)) (Source↗ 2008-07)

The common keyboard used around emacs era in the 1980s are those
keyboards from Lisp Machines↗. (see Space-cadet keyboard↗) The
keyboard on lisp machines have the Control key right besides the space
bar (similar to the position of Alt keys on PC keyboards), and Meta to
the left of Control. So, the Control key is the primary modifier, and
the Meta is secondary to Control. This is why, the shortcuts for the
most used commands in emacs involve the Control key instead of the
Meta key. (Example: The cursor movements: C-p, C-n, C-f, C-b, C-a, C-
e, the cut/paste/undo C-w, C-y, C-/, the kill-line C-k, the mark C-
SPC, the search C-s.) Lisp Machine's keyboards fell out of use alone
with Lisp Machines. Since the 1990s, the IBM PC keyboard↗ (and its
decedents) becomes the most popular and is used by some 98% of
personal computers today. The PC keyboard does not have Meta key but
have Alt instead. The Alt is placed right beside the space bar, while
Control is placed far to the corner.

Emacs did not change its keyboard shortcut bindings to adapt the PC
keyboard. Emacs simply remapped its Meta shortcuts to the Alt key by
default. (and kept on using the terminology Meta)

The tragedy of the Control/(Alt/Meta) swap made emacs keyboard
shortcuts very painful, and the frequent need to press the far-away
Control key creates the Emacs Pinky syndrome. (Many emacs-using
programer celebrities have injured their hands with emacs. (e.g.
Richard Stallman↗, Jamie Zawinski↗), and emacs's Ctrl and Meta
combinations are most cited as the major turn-off to potential users
among programers)

(For more photos of Lisp Machine's keyboards (all have Control as
primary), see: lisp_machine_symbolics_keyboard.jpg (photo by Rainer
Joswig↗. Used with permission), Symbolics keyboard PN 364000↗,
Symbolics keyboard PN 365407 Rev C↗ by Peter Paine )
The Choice Of Keys

The shortcut's key choices are primarily based on first letter of the
commands, not based on key position and finger strength or ease of
pressing the key. For example, the single char cursor moving shortcuts
(C-p previous-line ↑, C-n next-line ↓, C-b backward-char ←, C-f
forward-char →) are scattered around the keyboard with positions that
are most difficult to press. (these shortcuts all together accounts
for 43% of all commands executed by a keyboard shortcut) Of these, the
most frequently used is C-n (next-line), which accounts for 20% of all
shortcut calls, but is assigned to the letter n, positioned in the
middle of the keyboard, which is one of the most costly key to press.
Similarly, the second most used among these is the C-p (previous-
line), accounting for 16% of all shortcut command calls, is located in
a position above the right hand's pinky, also one of the most costly
key to press.

(Here we assumes the QWERTY keyboard layout. On the Dvorak layout, it
is about as bad.)
emacs cursor qwerty emacs cursor dvorak

above: Emacs's ursor moving keys on qwerty and dvorak.

See also, a newsgroup post on “comp.emacs”. “Re: effective
emacs” (2008-06-01) by Daniel Weinreb↗.
http://groups.google.com/group/comp.emacs/msg/0342e0bc1aa05c0d.

    «Emacs's default cursor moving shortcuts are “Ctrl+f”, “Ctrl+b”,
“Ctrl
    +n”, “Ctrl+p”. The keys f, b, n, p are scattered around the
keyboard
    and are not under the home row.»

    That's true.  At the time Guy Steele put together the Emacs
default
    key mappings, many people in the target user community (about 20
    people at MIT!) were already using these key bindings.  It would
    have been hard to get the new Emacs bindings accepted by the
    community if they differed for such basic commands.  As you point
    out, anyone using Emacs can very easily change this based on
    their own ergonomic preferences.

Outdated Commands

A significant portion of emacs's major shortcuts (those with M-‹key›
or C-‹key›) are mapped to commands that are almost never used today.
Some of these occupies the most precious space (Home row with thumb:
For example: M-s (center-line), M-j (indent-new-comment-line), M-k
(kill-sentence)). Most programer who have used emacs for years never
use these commands. For example:

digit-argument, M-1 to M-9
negative-argument, M--

move-to-window-line, M-r
center-line, M-s
transpose-words, M-t
tab-to-tab-stop, M-i

M-g prefix, M-g
indent-new-comment-line, M-j
tmm-menubar, M-'

zap-to-char, M-z
back-to-indentation, M-m
tags-loop-continue, M-,
find-tag, M-.

Difficult Keystrokes for Frequently Used Commands

Some commands that are used by every emacs user many times every hour,
such as Open (find-file; C-x C-f), Save (save-buffer; C-x C-s), Close
(kill-buffer; C-x k), Next Window/Tab (next-buffer C-x →) all require
multiple keystrokes with the difficult Control key.
Standard Name	Emacs Command Name	Keystroke
Open	find-file	C-x C-f
Save	save-buffer	C-x C-s
Close	kill-buffer	C-x k
Next Tab	next-buffer	C-x →
Previous Tab	previous-buffer	C-x ←
No Employment of the Shift Key

For historical reasons, emacs does not use any keybindings involving
the Shift with a letter. (e.g. there's no “Meta Shift a”, or “Control
Shift a”) This is so because in early computing environment, Ctrl+Shift
+‹letter› cannot be distinguished from the non-Shift version, due to a
practical combination of ASCII↗, Computer terminal↗, telnet↗.

Today, however, employing the Shift key as part of a shortcut with
other modifiers is common and convenient. For example, on Mac OS X,
Undo and Redo are Cmd+Z and Cmd+Shift+Z, Save and Save As are Cmd+S
and Cmd+Shift+S. On Mac and Windows, moving to next/previous field/
window/application often use the Shift key for reversing direction. In
text editing on both Mac and Windows, a modifier key with a arrow key
will move cursor by word/paragraph, and with Shift down will select
them while moving.

Using the Shift key as a reverse operation is very easy to remember,
and doesn't take another precious shortcut letter. By not using the
Shift key, commands with a logical reverse operation necessarily have
to find other key space, and overall making the shortcut set more
difficult to remember, or scattered, or more difficult to press.
A Flaw in Keybinding Policy

Any major software, maintains a guide for the developers about the
choices of keyboard shortcuts, so that the shortcuts will be
consistent. Emacs has this in its Emacs Lisp manual: Elisp Manual: Key-
Binding-Conventions.

This guide, indicates that the only key space reserved for users to
define, are the function keys F5 to F9, and key stroke sequence
starting with Ctrl+c followed by a single letter key.

This is a severe restraint to the utility of customized shortcuts. F5
to F9 are only 6 keys. The key sequence starting with C-c followed by
a letter, is a difficult sequence to execute, and there are only 26
spaces there.

The function keys, F1 to F12, are very good candidates for user
defined shortcut space, similarly for the digit key shortcuts, 0 to 9.
These keys can be used with any combination of Control, Meta, Shift.
For example, a user might define them to insert various templates,
headers/footers, a system of customized HTML/XML tags. Or, she might
assign them to various special emacs modes such as dired, shell, ftp,
email, calendar, calc, *scratch*, make-frame-command (Open a new
window), insert signature.

It seems too drastic a policy, to limit user defined keys to only F5
to F9, and key sequence of Control+c followed by a single letter key.
Epilogue: Failure to Change

Today, most commonly used keyboard shortcuts have been somewhat
informally standardized. For example, C/X/V is for Copy/Cut/Paste. O
is for Open. S is for Save, Shift-S is for Save As. P is for Print. F
is for Find/Search. Tab is for next, Shift tab for previous. These are
common conventions today in every application across Microsoft Windows
and Macintosh (and in Linux too in general).

These shortcut conventions are primarily brought about by Apple
Computer Inc's Human interface guidelines↗ and IBM's Common User
Access↗ in the 1990s.

In the early 1990s, DOS era software, each application has its own
scheme of shortcuts. The following is a excerpt from the Wikipedia
article on Common User Access↗:

    CUA was a detailed specification and set strict rules about how
applications should look and function. Its aim was in part to bring
about harmony between MS-DOS applications, which until then had
implemented totally different user interfaces.

    Examples:

        * In WordPerfect, the command to open a file was [F7], [3].
        * In Lotus 1-2-3, a file was opened with [/] (to open the
menus), [W] (for Workspace), [R] (for Retrieve).
        * In Microsoft Word, a file was opened with [Esc] (to open the
menus), [T] (for Transfer), [L] (for Load).
        * In WordStar, it was [Ctrl]+[K]+[O].
        * In Emacs, a file was opened with [Ctrl]+[x] followed by
[Ctrl]+[f] (for find-file).

    Some programs used [Esc] to cancel an action, some used it to
complete one; WordPerfect used it to repeat a character. Some programs
used [End] to go to the end of a line, some used it to complete
filling in a form. [F1] was often help but in WordPerfect that was
[F3]. [Ins] sometimes toggled between overtype and inserting
characters, but some programs used it for “paste”.

    Thus, every program had to be learned individually and its
complete user interface memorized. It was a sign of expertise to have
learned the UIs of dozens of applications, since a novice user facing
a new program would find their existing knowledge of a similar
application absolutely no use whatsoever.

Commercial software have updated themselves with time (or went
extinct), but emacs has not.

If we take a survey of the market share of text editors (including
IDEs) among professional programers (as defined by those who make a
living by computer programing), then, it is my guess, that emacs from
mid 1980s to early 1990s, has more than 50% of market share, but
gradually declined. Today, perhaps less that 5% of professional
programers use emacs (possibly even below 1%). I think, part of the
reason being that emacs has not modernized (not in the sense of being
fashionable, but in the sense of keeping with hardware and software
changes in the IT industry). The other major reason, is because emacs
itself is not a IDE in a modern sense, and most programing development
using compiled languages such as Pascal, C, C++, Java, C#, have moved
on with IDE platforms integrated with these languages's compiler
application.

See also: The Modernization of Emacs.

2008-07-15 Addendum: Thanks to Rainer Joswig↗ for some correction
about the history of the lisp machine's keyboards.
http://groups.google.com/group/comp.lang.lisp/msg/3b3dcdc52f507b02 .

  Xah
∑ http://xahlee.org/

☄

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

[Sean Sieger]

Xah <xahlee@gmail.com> writes:

    ... gab of knowledge ...

Earlier, Andreas pointed out a freudian slip---parapraxes, Freud called
them---but this one takes the cake.

By some poetic maneuver, lacuna is the word that comes to my mind, as
in: gab of lacunae.

    So, what can i do with you or you with me? For sincerity and persuit
    of truth, i am willing to pay $50 to have this argument about
    *scratch* fully resolved. I propose, that each of us put $50 into this
    argument. For nothing else, it is a reasonable proof of sincerity and
    effort to get a real quality argument going. How do we carry it out?
    that's always been problematic... but we can start, by , i send you
    $50 thru paypal, and you send me $50 thru paypal. I trust you, and you
    trust me. Then we start to argue really seriously. If in the end, you
    find that my argument is stronger, you pay me $50 back. Same me to
    you. What do you say?

I say, you can't even be expected or trusted to supply the expert
testimony on UI standards and design you've offered in the past---and
been taken up on!  And I ask, why ... WHY would anyone take you up on
this bet?  I was looking forward to that very testimony ... quotes and
so on.

After you lose the bet you'll say, ``Ah!  Moron!  Had my fingers crossed
behind my back, didn't I?''

Thanks, Xah, I'm going to start studying Elisp again.

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

[B. T. Raven]

Xah wrote:
> am tired arguing with you Alan.
> 
> let's assume that there is a gab of knowledge between you and me, and
> me having much higher knowledge than you. 

That's a wildly unwarranted assumption. You should take up investment 
banking.

Then, what do i get in
> teaching you thru exchange of messages? You know, when the knowledge
> gab is too wide, it is basically impossible to argue with fruitful
> outcome. Imagine, a math professor trying to argue some highschooler
> who just learned calculus.


> 
> Of course, you maybe think the same of me. So, what can i do?
> 
> in comp.lang.lisp for example, i argued with lots of Common Lisper
> morons, which often results in the same way. i.e. after several
> threods of hundred or more messages, basically they think i'm a moron,
> i think they are a moron, and it has become a impasse, as if we don't
> speak the same language. So, what can i do?

Maybe you could humbly consider the possibility that you are indeed a 
moron of some stripe. (I don't believe this but it is obvious that in 
some subtle way you don't speak the same language. Research the topic of 
"Private Languages.") That should put the fear of God in you.

> 
> About 3 or 4 times in the past year i have written detailed essay
> about the situation, and possible resolutions. I'm not going to spend
> some 1 hour to dig them up and spend perhaps another 2 hours to
> rephrase and reorganize them so it suites you here...

Your attempts at polishing your prose have not yet yielded any 
improvement that I can see.

  but basically i
> proposed each arguer putting down money, hire accomploshied experts,
> etc. The result is that, it doesn't help. They either ignore it, or
> put their tails between their ass and disappear or say some friendly
> words, or whatever ... suffice it to say that some these morons, still
> think i'm the moron. (i do think, that many tech geekers, did see get
> persuaded by my arguments.) (You can see a related article here:
> 
> How Shall I Respond
> http://xahlee.org/Netiquette_dir/how_shall_i_respond.html
> )

Research Harold Bloom's "Anxiety of Influence" and you will come to 
understand your ineluctable belatedness vis a vis the Emacs developers. 
Instead of nitpicking you should be grateful to them for providing you 
with such a useful and interesting tool.

> 
> So, what can i do with you or you with me? For sincerity and persuit
> of truth, i am willing to pay $50 to have this argument about
> *scratch* fully resolved. I propose, that each of us put $50 into this
> argument. For nothing else, it is a reasonable proof of sincerity and
> effort to get a real quality argument going. How do we carry it out?
> that's always been problematic... but we can start, by , i send you
> $50 thru paypal, and you send me $50 thru paypal. I trust you, and you
> trust me. Then we start to argue really seriously. If in the end, you
> find that my argument is stronger, you pay me $50 back. Same me to
> you. What do you say?

You are a babe in the woods.

> 
> Also, we could get the money to hire a arbitator who is someone we
> both agree to be UI expert and honest.... but this gets more
> complicated as to choosing someone, the logistics of it, etc. But i'm
> open to suggestions.


Vide supra

> 
> also, in good argument, we should formulate precisely exactly what we
> are arguing... i'm too tired with this thread now i'm not gonna spend
> any more minute to begin such a formulation... perhaps you might want
> to start such a suggestion, or we can go with the above $50 exchange
> first.

You have already squandered most of the good will this ng felt toward 
you originally.

> 
> So, if you agree, i send you $50 thru paypal, and post the receipt.
> So, once you get it, and others see my “payment sent receipt” posted,
> you'd do the same. Then we begin.
> 
> Btw Alan, you guys are motherfucking morons, i say. 


It's clear, to me at least, that your notion of high English writing 
style doesn't derive from George Orwell or others of that ilk but, more 
likely, from visiting brothels in the middle of the desert.

You guys, are
> absolutely devoid critical thinking abilities, and lack of knowledge
> of UI, and in fact blantantly ignorant plain facts such as emacs
> utterly bad design with its keybindings. This paragraph is just so
> that you (guys) know what my confience and my view of your guys are,
> before we start a formal argument with money down. I want you to know
> how cocky i am, so, if you lose at the end, you know you how really
> asinine you people are relative to me. (btw, you could try to blame me
> that by having this paragraph i wasn't really sincere about the $50
> money down to start argument. I am sincere really. Just post a reply,
> and if you really indicated that you want to go ahead with this,
> you'll get my $50. And, also remember, morons, the final judgement of
> who won the argument is not me. It is you. Quote: “If in the end, you
> find that my argument is stronger, you pay me $50 back. Same me to
> you.”)

Born in the USA (yesterday).

> 
> btw, i didn't read your last 2 or 3 posts here, Alan. It's not worth
> my time. I did spend maybe 10 seconds about the first few paragraphs.
> I have exchanged perhaps 15 or more messages with you in the past 6
> months. I know quite well what kinda things you'd say. However, if we
> began this argument with money down to begin, of course i will read
> every detail and think about about it.
> 
>> But that element of UI is subordinate to efficiency in things
>> like Emacs or a modern airliner.
> 
> No. Many emacs ways are in fact inefficient to a very high degree. One
> most obvious example is its keyboard shortcut system.
> 
> See:
> http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html

Perversely, you are right about some of your observations here but I 
suspect that I agree only because I myself am perverse enough to prefer 
dvorak to qwerty.

> 
> plain text version follows:
> --------------------
> Why Emacs's Keyboard Shortcuts Are Painful
> 
> Xah Lee, 2007-07
> 
> A important aspect in designing a keyboard shortcut set, for a
> application that has intensive, repetitive, prolonged human-machine
> interaction (such as coding and text editing), is to consider
> ergonomic principles. Specifically: allocate keyboard shortcuts for
> the most frequently used commands, and, the top most frequently used
> commands should have most easily-pressed keystrokes. For example, they
> should be on the home row.
> 
> This article shows why Emacs's keyboard shortcut set is the most
> ergonomically bad.
> The Swapping of Control and Meta Modifiers
> 
> Emacs's keyboard shortcuts is very inefficient. The primary cause is
> because, emacs's keyboard shortcuts are designed with a keyboard that
> practically has the Ctrl and Alt key positions swapped.
> Space-Cadet keyboard-2m
> 
> above: The Space-cadet keyboard. (Large Size: Space..._2.jpg
> (2003x813)) (Source↗ 2008-07)

Remember that RMS wasn't and maybe still isn't a touch typist. If you 
are such a blazing fast keyboarder then maybe you should have Guy 
Steel's old job as Stallman's amanuensis. You would have to pledge 
strict unthinking obedience in advance. If by some remote chance he is 
amazed at your productivity he may have a closer look at your key 
bindings. This makes a lot more sense to me than swapping virtual $50 
dollar bills via PayPal.

> 
> The common keyboard used around emacs era in the 1980s are those
> keyboards from Lisp Machines↗. (see Space-cadet keyboard↗) The
> keyboard on lisp machines have the Control key right besides the space
> bar (similar to the position of Alt keys on PC keyboards), and Meta to
> the left of Control. So, the Control key is the primary modifier, and
> the Meta is secondary to Control. This is why, the shortcuts for the
> most used commands in emacs involve the Control key instead of the
> Meta key. (Example: The cursor movements: C-p, C-n, C-f, C-b, C-a, C-
> e, the cut/paste/undo C-w, C-y, C-/, the kill-line C-k, the mark C-
> SPC, the search C-s.) Lisp Machine's keyboards fell out of use alone
> with Lisp Machines. Since the 1990s, the IBM PC keyboard↗ (and its
> decedents) becomes the most popular and is used by some 98% of
> personal computers today. The PC keyboard does not have Meta key but
> have Alt instead. The Alt is placed right beside the space bar, while
> Control is placed far to the corner.

Most of these don't matter with the exception of c, h, t, n, for cursor 
movement in the dvorak layout. I am not nearly as cavalier as you are 
about abandoning the mnemonic connotations of the keybindings as they 
have evolved under wise and prudent aegis of the developers.

> 
> Emacs did not change its keyboard shortcut bindings to adapt the PC
> keyboard. Emacs simply remapped its Meta shortcuts to the Alt key by
> default. (and kept on using the terminology Meta)
> 
> The tragedy of the Control/(Alt/Meta) swap made emacs keyboard
> shortcuts very painful, and the frequent need to press the far-away
> Control key creates the Emacs Pinky syndrome. (Many emacs-using
> programer celebrities have injured their hands with emacs. (e.g.
> Richard Stallman↗, Jamie Zawinski↗), and emacs's Ctrl and Meta
> combinations are most cited as the major turn-off to potential users
> among programers)

There is some truth to these observations but the solution probably lies 
in decommissioning the rodent. Ein genialer Vergleich would be to chop 
key-size pieces off of the space bar and assign them to left and right 
control. What's left of the spacebar should be cut in half and given 
over to backspace and forward space. These latter two keys will probably 
be the only ones pressed by the thumbs, at least for ten-fingered 
typists. The far right key on the bottom row could toggle the keyboard 
into mouse mode, enabling it to be used even for Autocad and Photoshop.

> 
> (For more photos of Lisp Machine's keyboards (all have Control as
> primary), see: lisp_machine_symbolics_keyboard.jpg (photo by Rainer
> Joswig↗. Used with permission), Symbolics keyboard PN 364000↗,
> Symbolics keyboard PN 365407 Rev C↗ by Peter Paine )
> The Choice Of Keys
> 
> The shortcut's key choices are primarily based on first letter of the
> commands, not based on key position and finger strength or ease of
> pressing the key. For example, the single char cursor moving shortcuts
> (C-p previous-line ↑, C-n next-line ↓, C-b backward-char ←, C-f
> forward-char →) are scattered around the keyboard with positions that
> are most difficult to press. (these shortcuts all together accounts
> for 43% of all commands executed by a keyboard shortcut) Of these, the
> most frequently used is C-n (next-line), which accounts for 20% of all
> shortcut calls, but is assigned to the letter n, positioned in the
> middle of the keyboard, which is one of the most costly key to press.
> Similarly, the second most used among these is the C-p (previous-
> line), accounting for 16% of all shortcut command calls, is located in
> a position above the right hand's pinky, also one of the most costly
> key to press.
> 
> (Here we assumes the QWERTY keyboard layout. On the Dvorak layout, it
> is about as bad.)
> emacs cursor qwerty emacs cursor dvorak
> 
> above: Emacs's ursor moving keys on qwerty and dvorak.
> 
> See also, a newsgroup post on “comp.emacs”. “Re: effective
> emacs” (2008-06-01) by Daniel Weinreb↗.
> http://groups.google.com/group/comp.emacs/msg/0342e0bc1aa05c0d.
> 
>     «Emacs's default cursor moving shortcuts are “Ctrl+f”, “Ctrl+b”,
> “Ctrl
>     +n”, “Ctrl+p”. The keys f, b, n, p are scattered around the
> keyboard
>     and are not under the home row.»
> 
>     That's true.  At the time Guy Steele put together the Emacs
> default
>     key mappings, many people in the target user community (about 20
>     people at MIT!) were already using these key bindings.  It would
>     have been hard to get the new Emacs bindings accepted by the
>     community if they differed for such basic commands.  As you point
>     out, anyone using Emacs can very easily change this based on
>     their own ergonomic preferences.
> 
> Outdated Commands
> 
> A significant portion of emacs's major shortcuts (those with M-‹key›
> or C-‹key›) are mapped to commands that are almost never used today.

Never used by whom? By you?

> Some of these occupies the most precious space (Home row with thumb:
> For example: M-s (center-line), M-j (indent-new-comment-line), M-k
> (kill-sentence)). Most programer who have used emacs for years never
> use these commands. For example:

Depends on the programer, the language, the mode, the year.

> 
> digit-argument, M-1 to M-9
> negative-argument, M--
> 
> move-to-window-line, M-r
> center-line, M-s
> transpose-words, M-t
> tab-to-tab-stop, M-i
> 
> M-g prefix, M-g
> indent-new-comment-line, M-j
> tmm-menubar, M-'
> 
> zap-to-char, M-z
> back-to-indentation, M-m
> tags-loop-continue, M-,
> find-tag, M-.
> 
> Difficult Keystrokes for Frequently Used Commands
> 
> Some commands that are used by every emacs user many times every hour,
> such as Open (find-file; C-x C-f), Save (save-buffer; C-x C-s), Close
> (kill-buffer; C-x k), Next Window/Tab (next-buffer C-x →) all require
> multiple keystrokes with the difficult Control key.
> Standard Name	Emacs Command Name	Keystroke
> Open	find-file	C-x C-f
> Save	save-buffer	C-x C-s
> Close	kill-buffer	C-x k
> Next Tab	next-buffer	C-x →
> Previous Tab	previous-buffer	C-x ←
> No Employment of the Shift Key
> 
> For historical reasons, emacs does not use any keybindings involving
> the Shift with a letter. (e.g. there's no “Meta Shift a”, or “Control
> Shift a”) This is so because in early computing environment, Ctrl+Shift
> +‹letter› cannot be distinguished from the non-Shift version, due to a
> practical combination of ASCII↗, Computer terminal↗, telnet↗.

This limitation has been transcended.

> 
> Today, however, employing the Shift key as part of a shortcut with
> other modifiers is common and convenient. For example, on Mac OS X,
> Undo and Redo are Cmd+Z and Cmd+Shift+Z, Save and Save As are Cmd+S
> and Cmd+Shift+S. On Mac and Windows, moving to next/previous field/
> window/application often use the Shift key for reversing direction. In
> text editing on both Mac and Windows, a modifier key with a arrow key
> will move cursor by word/paragraph, and with Shift down will select
> them while moving.

As Emacs continues to evolve some of your concerns will be addressed but 
most will be ignored. You are free to resolve them to your own 
satisfaction for your own private use.

> 
> Using the Shift key as a reverse operation is very easy to remember,
> and doesn't take another precious shortcut letter. By not using the
> Shift key, commands with a logical reverse operation necessarily have
> to find other key space, and overall making the shortcut set more
> difficult to remember, or scattered, or more difficult to press.
> A Flaw in Keybinding Policy
> 
> Any major software, maintains a guide for the developers about the
> choices of keyboard shortcuts, so that the shortcuts will be
> consistent. Emacs has this in its Emacs Lisp manual: Elisp Manual: Key-
> Binding-Conventions.
> 
> This guide, indicates that the only key space reserved for users to
> define, are the function keys F5 to F9, and key stroke sequence
> starting with Ctrl+c followed by a single letter key.
> 
> This is a severe restraint to the utility of customized shortcuts. F5
> to F9 are only 6 keys. The key sequence starting with C-c followed by
> a letter, is a difficult sequence to execute, and there are only 26
> spaces there.
> 
> The function keys, F1 to F12, are very good candidates for user
> defined shortcut space, similarly for the digit key shortcuts, 0 to 9.
> These keys can be used with any combination of Control, Meta, Shift.
> For example, a user might define them to insert various templates,
> headers/footers, a system of customized HTML/XML tags. Or, she might
> assign them to various special emacs modes such as dired, shell, ftp,
> email, calendar, calc, *scratch*, make-frame-command (Open a new
> window), insert signature.
> 
> It seems too drastic a policy, to limit user defined keys to only F5
> to F9, and key sequence of Control+c followed by a single letter key.

The function keys, like the mouse, are too far away to be generally 
useful. They might be used for bindings that are rare and/or constructed 
on the fly.

> Epilogue: Failure to Change
> 
> Today, most commonly used keyboard shortcuts have been somewhat
> informally standardized. For example, C/X/V is for Copy/Cut/Paste. O
> is for Open. S is for Save, Shift-S is for Save As. P is for Print. F
> is for Find/Search. Tab is for next, Shift tab for previous. These are
> common conventions today in every application across Microsoft Windows
> and Macintosh (and in Linux too in general).

Irrelevant. It's more important to make Dvorak the default layout and to 
start teaching it to seven year olds.

> 
> These shortcut conventions are primarily brought about by Apple
> Computer Inc's Human interface guidelines↗ and IBM's Common User
> Access↗ in the 1990s.
> 
> In the early 1990s, DOS era software, each application has its own
> scheme of shortcuts. The following is a excerpt from the Wikipedia
> article on Common User Access↗:
> 
>     CUA was a detailed specification and set strict rules about how
> applications should look and function. Its aim was in part to bring
> about harmony between MS-DOS applications, which until then had
> implemented totally different user interfaces.
> 
>     Examples:
> 
>         * In WordPerfect, the command to open a file was [F7], [3].
>         * In Lotus 1-2-3, a file was opened with [/] (to open the
> menus), [W] (for Workspace), [R] (for Retrieve).
>         * In Microsoft Word, a file was opened with [Esc] (to open the
> menus), [T] (for Transfer), [L] (for Load).
>         * In WordStar, it was [Ctrl]+[K]+[O].
>         * In Emacs, a file was opened with [Ctrl]+[x] followed by
> [Ctrl]+[f] (for find-file).
> 
>     Some programs used [Esc] to cancel an action, some used it to
> complete one; WordPerfect used it to repeat a character. Some programs
> used [End] to go to the end of a line, some used it to complete
> filling in a form. [F1] was often help but in WordPerfect that was
> [F3]. [Ins] sometimes toggled between overtype and inserting
> characters, but some programs used it for “paste”.
> 
>     Thus, every program had to be learned individually and its
> complete user interface memorized. It was a sign of expertise to have
> learned the UIs of dozens of applications, since a novice user facing
> a new program would find their existing knowledge of a similar
> application absolutely no use whatsoever.
> 
> Commercial software have updated themselves with time (or went
> extinct), but emacs has not.

With good reason. Emacs developers are committed (as far as I can tell) 
to let usefulness and usability be their only guides.

> 
> If we take a survey of the market share of text editors (including
> IDEs) among professional programers (as defined by those who make a
> living by computer programing), then, it is my guess, that emacs from
> mid 1980s to early 1990s, has more than 50% of market share, but
> gradually declined. Today, perhaps less that 5% of professional
> programers use emacs (possibly even below 1%). I think, part of the
> reason being that emacs has not modernized (not in the sense of being
> fashionable, but in the sense of keeping with hardware and software
> changes in the IT industry). The other major reason, is because emacs
> itself is not a IDE in a modern sense, and most programing development
> using compiled languages such as Pascal, C, C++, Java, C#, have moved
> on with IDE platforms integrated with these languages's compiler
> application.

As the internet, due to the orgulous exercitations of people like you, 
slowly goes out of fashion, Emacs will remain a very useful tool even 
after its umbilical cord has been cut.

> 
> See also: The Modernization of Emacs.
> 
> 2008-07-15 Addendum: Thanks to Rainer Joswig↗ for some correction
> about the history of the lisp machine's keyboards.
> http://groups.google.com/group/comp.lang.lisp/msg/3b3dcdc52f507b02 .
> 
>   Xah
> ∑ http://xahlee.org/
> 
> ☄

Btw, I notice that you haven't been gracious enough to thank Chetan for 
providing a general solution to your difficulties. Why is that?

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

[Chetan]

"B. T. Raven" <nihil@nihilo.net> writes:

... Initial comments deleted.

I wanted to respond to my own message, but I cannot see my message now.
I would like to clarify my earlier post, where I might have appeared
rigid in my choice of keys.

Personally, I havn't had to work with dumb terminal for quite some time,
so I have not had to use the C-n C-p etc. keys for movement. I generally
use the arrow keys instead. I don't use CUA mode, either. Nor do I use
the menubar or toolbar. However, I felt that for users new to Emacs,
being able to use the familiar keys will be a good thing to break the
inertia. I remember I fumbled with emacs years ago, until I decided to
invest the time in taking the tutorial, which did help. Once the
fingers got used to the keystrokes, it wasn't an issue. One of the
things I have found is that people, especially the power users, get very
upset if changes are made that affect their own setup that they have
spent time optimizing, even if the changes may be appreciated by them in
the long run.

I don't claim to be a UI expert. What matters to me is whether it will
help me or someone else work better. Until I see that, I am reluctant to
change the way I do things. I am sure the same situation exists with
respect to the alternatives to the qwerty keyboard layout. Many people
claim that there are better layouts and yet the majority of keyboards
shipped today use that layout. Familiarity seems to have a value. If
somebody manages to convince me, I might change, but that hasn't
happened so far. There may also be situation beyond my control which
forces me to change (my keyboard or my key choices).

> Btw, I notice that you haven't been gracious enough to thank Chetan for
> providing a general solution to your difficulties. Why is that?

Thank you. I couldn't locate my message now and was wondering if it did
go out. Now I know. Honestly, though, it wasn't all my work.

Chetan

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

[Xah]

On Sep 27, 11:12 am, "B. T. Raven" <ni...@nihilo.net> wrote:
> Your attempts at polishing your prose have not yet yielded any
> improvement that I can see.

my posts here are not polished. On average, they are written at the
rate perhaps 50 wpm. There are too many to reply to.

Most articles that went to my website are polished versions. e.g.

The Modernization of Emacs
http://xahlee.org/emacs/modernization.html

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

Emacs's M-‹key› Notation vs Alt+‹key› Notation.
http://xahlee.org/emacs/modernization_meta_key.html

much content in these articles are orginially newsgroup posts.

> Remember that RMS wasn't and maybe still isn't a touch typist.

I don't know about that. I knew at one period of time he had serious
RSI that he resorted to or was using voice input systems. (this would
be somewhere in early to mid 1990s, or possibly earlier)

In fact, many emacs celebrity has serious RSI.

Richard Stallman, Jamie Zawinski (xemacs, netscape fame), Ben Wing
(quite ex-xemacs leader).

Richard's got pages talking about it i read somewhere i think in late
1990s, not sure if they are still around. Jamie has written a fairly
popular page about RSI on his website. Info on Ben is hard to find,
but you can see Jamie mentions the fact. I think he is the most
serious case to some permanent degree he no longer program in any
professional capacity.

of course, in this thread Lennart (author of emacsW32) mentioned about
Alex (starter of emacswiki.org)'s RSI ...

if fact, there are lots webpages talking about emacs induced RSI.

all these should really be blamed on emacs keybinding, being the most
shit design possible.

See:
http://xahlee.org/emacs/emacs_kb_shortcuts_pain.html


> Most of these don't matter with the exception of c, h, t, n, for cursor
> movement in the dvorak layout. I am not nearly as cavalier as you are
> about abandoning the mnemonic connotations of the keybindings as they
> have evolved under wise and prudent aegis of the developers.

Thinking that emacs ways or emacs keybinding must have designed by
some wise group of people for some good reasons, is a misconception.

The origin of emacs basic keybindings, can be seen from Daniel
Weinreb, who reasonably claims that “nobody has been using Emacs
blonger than i have”. For detail and source, see my article above.

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

at this point, i got tired and too lazy to read further of your post.
Maybe i'll pickup later. Thanks for the effort though.

  Xah
∑ http://xahlee.org/

☄

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

[Xah]

On Sep 27, 10:28 am, Sean Sieger <sean.sie...@gmail.com> wrote:
> Xah<xah...@gmail.com> writes:
>
>     ... gab of knowledge ...
>
> Earlier, Andreas pointed out a freudian slip---parapraxes, Freud called
> them---but this one takes the cake.
>
> By some poetic maneuver, lacuna is the word that comes to my mind, as
> in: gab of lacunae.
>
>     So, what can i do with you or you with me? For sincerity and persuit
>     of truth, i am willing to pay $50 to have this argument about
>     *scratch* fully resolved. I propose, that each of us put $50 into this
>     argument. For nothing else, it is a reasonable proof of sincerity and
>     effort to get a real quality argument going. How do we carry it out?
>     that's always been problematic... but we can start, by , i send you
>     $50 thru paypal, and you send me $50 thru paypal. I trust you, and you
>     trust me. Then we start to argue really seriously. If in the end, you
>     find that my argument is stronger, you pay me $50 back. Same me to
>     you. What do you say?

I don't know what you getting at, man.

Maybe ur trying to be poetic or allude to something, but sorry i don't
have time to dig, and consider the quality of most posts, its not
worthwhile to dig.

> I say, you can't even be expected or trusted to supply the expert
> testimony on UI standards and design you've offered in the past---and
> been taken up on!  And I ask, why ... WHY would anyone take you up on
> this bet?  I was looking forward to that very testimony ... quotes and
> so on.

Huh? Sorry but i didn't understand your English.

I started to collect user testimonial on my ergonomic keybindings
about few months ago. Here's the page:
 http://xahlee.org/emacs/ergonomic_emacs_keybinding_good.html

> After you lose the bet you'll say, ``Ah!  Moron!  Had my fingers crossed
> behind my back, didn't I?''
>
> Thanks, Xah, I'm going to start studying Elisp again.

Sure thing.

PS To some of you who posted in this thread, possibly i have replied
and you found my reply to be rude or terse. Sorry about that. There
are so many drivels in this thread, intentional or not. Since about 4
or 5 months ago i decided to take a conversational styled newsgroup
mannerism (see “How Shall I Respond”
http://xahlee.org/Netiquette_dir/how_shall_i_respond.html
). In part, reply to most messages if not all. (see “What I've Learned
By Conversational Styled Posts”
http://xahlee.org/Netiquette_dir/chat_style_posts.html )
So, i end up like having a lot low quality or intentional insulting
messages to reply to. In the process, perhaps some sincere ones got
misunderstood.

  Xah
∑ http://xahlee.org/

☄

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

[stan]

Xah wrote:
> Kevin Rodgers wrote:
>
>> > «
>> >     * There is no easy, intuitive way to create multiple scratch
>> > buffers. (it is done by using the switch-to-buffer command (C-x b) and
>> > give name that is not one of existing buffers.)
>>
>> We'll have to disagree: I think that is both easy and intuitive.
>
> What seems to you intuitive is not intuitive to the general text
> editing audience. The text editing audience is broad, including all IT
> professionals, those in academics.

You don't have authority to speak for the general text editing audience.
You certainly never got my permission. 

My point is that you use a form of bandwagon propaganda - everyone else
is having problems - to justify many of your claims. It is not
persuasive. You might try sticking to specific facts of why something is
a problem. If you don't convince people that there is actually a
problem, few will be moved to action. 

The truth is that most people don't use editors, they prefer word
processors. Most "editor" users expect to face a trade off between power
and learning curve. The ones who don't will always be disappointed. That
fact doesn't justify unnecessary complexity, but it does mean the bar is
high for justifying changes to well known editors. 

> clude if you ask them to define variable or algorithm or byte. Perhaps
> you are thinking these people are stupid. Perhaps when compared to you
> as a tech geeker, they are quite ignorant about computers. But the
> world is big, there are all walks of life. Many of them are in fact
> scientists, engineers, mathematicians, lawers. You wouldn't know shit
> if i ask you some elementary math concepts (trust me). Similarly, you
> don't know the most elementary thing about laws, engineering, ... all
> all sort of fields. One element of User Interface design is that the
> user don't have to learn anything in order to use it, as much as
> possible.

That's one possible goal of user interface design. The other side of the
coin is to balance power with ease of use. 

> Emacs has too many unusual ways... (btw, i'm damn repeating myself
> again and again and again here... in this thread i've already wrote
> paragraph(s) that details this).

As you noted, the world includes people of all types. To some Emacs will
seem unusual, to others it's clear. Same can be said for vi and
descendants. I'm sure some consider notepad strange. 

<snip>

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

[Richard Riley]

stan <smoore@exis.net> writes:

> Xah wrote:
>> Kevin Rodgers wrote:
>>
>>> > «
>>> >     * There is no easy, intuitive way to create multiple scratch
>>> > buffers. (it is done by using the switch-to-buffer command (C-x b) and
>>> > give name that is not one of existing buffers.)
>>>
>>> We'll have to disagree: I think that is both easy and intuitive.
>>
>> What seems to you intuitive is not intuitive to the general text
>> editing audience. The text editing audience is broad, including all IT
>> professionals, those in academics.
>
> You don't have authority to speak for the general text editing audience.
> You certainly never got my permission. 

Well, thats not really fair. Emacs is certainly not intuitive to the
general text editing audience since its pretty much a minority editor. I
dont know anyone who didnt have trouble adapting to Emacs personally
(including myself) - but its only after a while you realise the genius
behind a lot of the UI. Things you do not see or appreciate when you
first tackle it. 

Can the general text editing population adapt and use it? Of course. But
initial feedback is usually "what the hell!" :-)

I mean, have you seen peoples faces when they read the manual and realise
they have to control/meta key sequences to move the cursor left and
right, up and down?

Please dont take these comments as support for what Xah is saying but
there does tend to be a certain reluctance to make "common things" the
standard in emacs which might, just might, promote adoption.

Things are getting better - e.g I think using the x clipboard finally
became the default in 22. Stuff like that.

>
> My point is that you use a form of bandwagon propaganda - everyone else
> is having problems - to justify many of your claims. It is not
> persuasive. You might try sticking to specific facts of why something is
> a problem. If you don't convince people that there is actually a
> problem, few will be moved to action. 
>
> The truth is that most people don't use editors, they prefer word
> processors. Most "editor" users expect to face a trade off between power
> and learning curve. The ones who don't will always be disappointed. That
> fact doesn't justify unnecessary complexity, but it does mean the bar is
> high for justifying changes to well known editors. 
>
>> clude if you ask them to define variable or algorithm or byte. Perhaps
>> you are thinking these people are stupid. Perhaps when compared to you
>> as a tech geeker, they are quite ignorant about computers. But the
>> world is big, there are all walks of life. Many of them are in fact
>> scientists, engineers, mathematicians, lawers. You wouldn't know shit
>> if i ask you some elementary math concepts (trust me). Similarly, you
>> don't know the most elementary thing about laws, engineering, ... all
>> all sort of fields. One element of User Interface design is that the
>> user don't have to learn anything in order to use it, as much as
>> possible.
>
> That's one possible goal of user interface design. The other side of the
> coin is to balance power with ease of use. 
>
>> Emacs has too many unusual ways... (btw, i'm damn repeating myself
>> again and again and again here... in this thread i've already wrote
>> paragraph(s) that details this).
>
> As you noted, the world includes people of all types. To some Emacs will
> seem unusual, to others it's clear. Same can be said for vi and
> descendants. I'm sure some consider notepad strange. 
>
> <snip>

-- 

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

[stan]

Richard Riley wrote:
> stan <smoore@exis.net> writes:
>
>> Xah wrote:
>>> Kevin Rodgers wrote:
>>>
>>>> > «
>>>> >     * There is no easy, intuitive way to create multiple scratch
>>>> > buffers. (it is done by using the switch-to-buffer command (C-x b) and
>>>> > give name that is not one of existing buffers.)
>>>>
>>>> We'll have to disagree: I think that is both easy and intuitive.
>>>
>>> What seems to you intuitive is not intuitive to the general text
>>> editing audience. The text editing audience is broad, including all IT
>>> professionals, those in academics.
>>
>> You don't have authority to speak for the general text editing audience.
>> You certainly never got my permission. 
>
> Well, thats not really fair. Emacs is certainly not intuitive to the
> general text editing audience since its pretty much a minority editor. I
> dont know anyone who didnt have trouble adapting to Emacs personally
> (including myself) - but its only after a while you realise the genius
> behind a lot of the UI. Things you do not see or appreciate when you
> first tackle it. 

The point wasn't really about intuitiveness, that of course in the eye
of the beholder. I certainly didn't wake up one day thinking in terms of
emacs chords; I had to learn them. I don't really think emacs is worse
than vim, wordstar, ed, edlin, or any of a dozen proprietary things I've
been forced to endure. I expect to have some learning, and I don't
expect it to match windows.

My point was that generalizing about editor users is at best difficult
and most often impossible. Arguments like "people are confused" are
silly and not persuasive. Some are confused and others are happy as
clams. 

I also meant to take issue with the idea that many if not most people
confuse the number of editor users with the number of word processor
users. "Editor users" is a relatively small subset of people who write.
The difference between the users and needs is large and confusion
doesn't help.

> Can the general text editing population adapt and use it? Of course. But
> initial feedback is usually "what the hell!" :-)

Again, this sounds like comparing emacs to word processors or windows
programs. What do you imagine the initial response is for people
foolish enough to open vi on a whim? For that matter Wordperfect wasn't
exactly a model of intuitiveness and it did really well and continues as
a significant part of the legal world. I realize I just mixed word
processors with editors but my point was about the need to learn any
powerful tool.


> I mean, have you seen peoples faces when they read the manual and realise
> they have to control/meta key sequences to move the cursor left and
> right, up and down?

Actually no, I don't know any young people who use emacs and most older
folks were more interested in getting their hands dirty so to speak. 


> Please dont take these comments as support for what Xah is saying but
> there does tend to be a certain reluctance to make "common things" the
> standard in emacs which might, just might, promote adoption.

I understand. I do wonder where this idea that emacs needs to be
competitive in the market comes from. I don't see that it really matters
much to current users. People who use it will continue and developers
will continue to maintain. Why does the number of users matter? Like my
grandmother was fond of asking "If every one else sets themselves on
fire are you going too follow them"? I don't really care if everyone
move to editor X. Emacs works for me and I think it's a useful tool.
Other who want to use it are free to choose. 

I'd also add that much of this seems like a much ado about nothing.
Anyone who wants to change emacs or even fork the code is free to do so.
This seems like an attempt to convince current programmers that there is
a need to "fix" emacs or market share will shrink.  Even if that's true,
why does it matter? It's not like some company will get tired of
maintaining it and stop work.
>
> Things are getting better - e.g I think using the x clipboard finally
> became the default in 22. Stuff like that.

Clipboards are a good example of something that maintainers decided was a
useful change. I haven't seen anything that convinces me there is a
burning need to rearrange the default keyboard. For those who do feel
the need why not just distribute a .emacs file for dummies? The whole
thing seems to miss the point that emacs is nothing if not configurable.

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

[Richard Riley]

stan <smoore@exis.net> writes:

> Richard Riley wrote:
>> stan <smoore@exis.net> writes:
>>
>>> Xah wrote:
>>>> Kevin Rodgers wrote:
>>>>
>>>>> > «
>>>>> >     * There is no easy, intuitive way to create multiple scratch
>>>>> > buffers. (it is done by using the switch-to-buffer command (C-x b) and
>>>>> > give name that is not one of existing buffers.)
>>>>>
>>>>> We'll have to disagree: I think that is both easy and intuitive.
>>>>
>>>> What seems to you intuitive is not intuitive to the general text
>>>> editing audience. The text editing audience is broad, including all IT
>>>> professionals, those in academics.
>>>
>>> You don't have authority to speak for the general text editing audience.
>>> You certainly never got my permission. 
>>
>> Well, thats not really fair. Emacs is certainly not intuitive to the
>> general text editing audience since its pretty much a minority editor. I
>> dont know anyone who didnt have trouble adapting to Emacs personally
>> (including myself) - but its only after a while you realise the genius
>> behind a lot of the UI. Things you do not see or appreciate when you
>> first tackle it. 
>
> The point wasn't really about intuitiveness, that of course in the eye
> of the beholder. I certainly didn't wake up one day thinking in terms of
> emacs chords; I had to learn them. I don't really think emacs is worse
> than vim, wordstar, ed, edlin, or any of a dozen proprietary things I've
> been forced to endure. I expect to have some learning, and I don't
> expect it to match windows.
>
> My point was that generalizing about editor users is at best difficult
> and most often impossible. Arguments like "people are confused" are
> silly and not persuasive. Some are confused and others are happy as
> clams. 

Only if one thinks in B&W. I think it was fairly obvious that Xah was
not suggesting for one minute that 100% of people were confused.

>
> I also meant to take issue with the idea that many if not most people
> confuse the number of editor users with the number of word processor
> users. "Editor users" is a relatively small subset of people who
> write.

I'm not sure I noticed that issue but of course you are right.

> The difference between the users and needs is large and confusion
> doesn't help.

I'm not sure of the relevance. We are talking about the "generally
perceived" or noticed reaction to emacs by people who try it. My own
experience is that most people go "yuck" - until they dig further and
find what it can really do with a bit of work. Often it takes some hand
holding. I know I had to gird my loins once or twice and dive back in
when I had got frustrated with it.

>
>> Can the general text editing population adapt and use it? Of course. But
>> initial feedback is usually "what the hell!" :-)
>
> Again, this sounds like comparing emacs to word processors or windows
> programs. What do you imagine the initial response is for people
> foolish enough to open vi on a whim? For that matter Wordperfect
> wasn't

vi would be there too as something not particularly suited to new
"general" users. But we were discussing emacs.

> exactly a model of intuitiveness and it did really well and continues as
> a significant part of the legal world. I realize I just mixed word
> processors with editors but my point was about the need to learn any
> powerful tool.

I agree. But as an editor some of the defaults are quite a hurdle to new
users. There are not many seasoned users who would disagree with that I
would think. The task is to convince new users that the effort and
learning curve is worth it.

>
>
>> I mean, have you seen peoples faces when they read the manual and realise
>> they have to control/meta key sequences to move the cursor left and
>> right, up and down?
>
> Actually no, I don't know any young people who use emacs and most older
> folks were more interested in getting their hands dirty so to speak. 

So you are arguing from a point of view with little practical experience
of new users? 

>
>> Please dont take these comments as support for what Xah is saying but
>> there does tend to be a certain reluctance to make "common things" the
>> standard in emacs which might, just might, promote adoption.
>
> I understand. I do wonder where this idea that emacs needs to be
> competitive in the market comes from. I don't see that it really
> matters
> much to current users. People who use it will continue and developers

It does to me. The more people who use it the better it will be
maintained and the more utilities will be developed to a point of
usefulness.

> will continue to maintain. Why does the number of users matter? Like
> my

I like to advocate good OSS apps. Emacs is one such. I am surprised that
you are not interested in furthering its use. Yet at the same time you
have strong views on how it should or should not be tweaked to ease the
learning curve for new users.

> grandmother was fond of asking "If every one else sets themselves on
> fire are you going too follow them"? I don't really care if everyone
> move to editor X. Emacs works for me and I think it's a useful tool.
> Other who want to use it are free to choose. 

But it is rather naive to think that more users does not safeguard and
enhance an application especially one which so much relies on users
contributions and maintenance.

>
> I'd also add that much of this seems like a much ado about nothing.
> Anyone who wants to change emacs or even fork the code is free to do
> so.

Don't be silly. We are talking NEW users. New users do not pile in and
write elisp :-;

> This seems like an attempt to convince current programmers that there is
> a need to "fix" emacs or market share will shrink.  Even if that's true,
> why does it matter? It's not like some company will get tired of
> maintaining it and stop work.

You seem almost as if you would not care if emacs lost users. This
surprises me. I would like it to attract more and more. 

>>
>> Things are getting better - e.g I think using the x clipboard finally
>> became the default in 22. Stuff like that.
>
> Clipboards are a good example of something that maintainers decided was a
> useful change. I haven't seen anything that convinces me there is a

It took a long time....

> burning need to rearrange the default keyboard. For those who do feel
> the need why not just distribute a .emacs file for dummies? The whole
> thing seems to miss the point that emacs is nothing if not
> configurable.

I dont think anyone is suggesting any thing other than that. 

Anyway, thats my tuppence worth. I do not offer a perfect solution only
the reflection that anything that can be done to make Emacs easier for
the new adopter which does not contribute it for the emacs power user
can only be a good thing.

Emacs is a wonderfully customisable work horse and well worth the effort
needed to familiarise oneself with it.

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

[Cor Gest]

Some entity, AKA Richard Riley <rileyrgdev@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)


> Anyway, thats my tuppence worth. I do not offer a perfect solution only
> the reflection that anything that can be done to make Emacs easier for
> the new adopter which does not contribute it for the emacs power user
> can only be a good thing.
>
> Emacs is a wonderfully customisable work horse and well worth the effort
> needed to familiarise oneself with it.

All in all one can say that if one needs Emacs one has at least
knowledge of ones needs.

But then again, manure can be transported with an Rolls-Royce, wich
would not be my transportcontraption of choice to do an adequate job.

So, one does need to learn to drive a tractor before one can fertilise
the fields in a more practicle way.

Needless to say that that contraption comes with a boatload of
appendages to do more specialised jobs, wich all need to be learned how
to use for any particular task at hand.

Cor

PS: Having a nice sleek looking spoiler on the tractors' roof does look sexy
but is utterly useless.

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

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

[Richard Riley]

Cor Gest <cor@clsnet.nl> writes:

> Some entity, AKA Richard Riley <rileyrgdev@gmail.com>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
>
>> Anyway, thats my tuppence worth. I do not offer a perfect solution only
>> the reflection that anything that can be done to make Emacs easier for
>> the new adopter which does not contribute it for the emacs power user
>> can only be a good thing.
>>
>> Emacs is a wonderfully customisable work horse and well worth the effort
>> needed to familiarise oneself with it.
>
> All in all one can say that if one needs Emacs one has at least
> knowledge of ones needs.

One always has knowledge of ones needs. Then its a question of shopping
around to see what meets those needs and can meet them in an efficient
manner.

> But then again, manure can be transported with an Rolls-Royce, wich
> would not be my transportcontraption of choice to do an adequate job.

Erm, ok.

>
> So, one does need to learn to drive a tractor before one can fertilise
> the fields in a more practicle way.

Sure. Er? Why are you saying this? it is not more than "one must learn
to use the tool". The points being made are about whether there are
better defaults which will not break emacs but will help it appeal more
to the newer generation.

> Needless to say that that contraption comes with a boatload of
> appendages to do more specialised jobs, wich all need to be learned how
> to use for any particular task at hand.

Are you saying that there is loads of functionality which one learns
and becomes familiar with the more you learn? Which is quit clear I
think and not in contention.

>
> Cor
>
> PS: Having a nice sleek looking spoiler on the tractors' roof does look sexy
> but is utterly useless.

Well, you've lost me. If you think removing a default elisp buffer as
the front of emacs, for example, is adding a "spoiler" or "go faster
stripe" then I am a tad surprised to say the least.

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

[Cor Gest]

Some entity, AKA Richard Riley <rileyrgdev@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)

>> Needless to say that that contraption comes with a boatload of
>> appendages to do more specialised jobs, wich all need to be learned how
>> to use for any particular task at hand.
>
> Are you saying that there is loads of functionality which one learns
> and becomes familiar with the more you learn? Which is quit clear I
> think and not in contention.

Well there are are boat-load of 'modes' in emacs one can bolt-on, 
aren't there ..  ;-)
Each and every one specialised to do tasks easier than in,
 say, eh ...  notepad.exe ? ;-)

>> PS: Having a nice sleek looking spoiler on the tractors' roof does look sexy
>> but is utterly useless.

> Well, you've lost me. If you think removing a default elisp buffer as
> the front of emacs, for example, is adding a "spoiler" or "go faster
> stripe" then I am a tad surprised to say the least.

merely a try for humor, in this whole somewhat silly
discussion about renaming a scratch-buffer, it surely would be
useless. (the renaming of course).

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 

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

[Richard Riley]

Cor Gest <cor@clsnet.nl> writes:

> Some entity, AKA Richard Riley <rileyrgdev@gmail.com>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
>>> Needless to say that that contraption comes with a boatload of
>>> appendages to do more specialised jobs, wich all need to be learned how
>>> to use for any particular task at hand.
>>
>> Are you saying that there is loads of functionality which one learns
>> and becomes familiar with the more you learn? Which is quit clear I
>> think and not in contention.
>
> Well there are are boat-load of 'modes' in emacs one can bolt-on, 
> aren't there ..  ;-)

Yes.

> Each and every one specialised to do tasks easier than in,
>  say, eh ...  notepad.exe ? ;-)

Yes.

>
>>> PS: Having a nice sleek looking spoiler on the tractors' roof does look sexy
>>> but is utterly useless.
>
>> Well, you've lost me. If you think removing a default elisp buffer as
>> the front of emacs, for example, is adding a "spoiler" or "go faster
>> stripe" then I am a tad surprised to say the least.
>
> merely a try for humor, in this whole somewhat silly
> discussion about renaming a scratch-buffer, it surely would be
> useless. (the renaming of course).

You think its silly? Well, we know where your vote would go then :-;

buffers and files and plus ca la change and all that

[OtherMichael]

some discussion over at StackOverflow:
http://stackoverflow.com/questions/195485/why-do-old-editors-like-vim-and-emacs-expose-the-difference-between-a-file-and#195668

Q: Why do old editors like Vim and Emacs expose the difference between
a File and a Buffer in the interface?

A: [.... B]because late binding between the buffer in the editor and
the actual concrete thing you're working on, gives the editing
environment more flexibility and power.

Think this is out of date? One place where the idea is back with a
vengeance is in the browser, where you don't have 1-1 correspondence
between tabs and web-pages. Instead, inside each tab you can navigate
forwards and backwards between multiple pages. No-one would try to
make an MDI type interface to the web, where each page had it's own
inner window. It would be impossibly fiddly to use. It just wouldn't
scale.


--the Other michael

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

[stan]

Richard Riley wrote:
> stan <smoore@exis.net> writes:
>
>> Richard Riley wrote:
>>> stan <smoore@exis.net> writes:
>>>
>>>> Xah wrote:
>>>>> Kevin Rodgers wrote:
>>>>>
<snip>
>> The point wasn't really about intuitiveness, that of course in the eye
>> of the beholder. I certainly didn't wake up one day thinking in terms of
>> emacs chords; I had to learn them. I don't really think emacs is worse
>> than vim, wordstar, ed, edlin, or any of a dozen proprietary things I've
>> been forced to endure. I expect to have some learning, and I don't
>> expect it to match windows.
>>
>> My point was that generalizing about editor users is at best difficult
>> and most often impossible. Arguments like "people are confused" are
>> silly and not persuasive. Some are confused and others are happy as
>> clams. 
>
> Only if one thinks in B&W. I think it was fairly obvious that Xah was
> not suggesting for one minute that 100% of people were confused.

I think you missed the point here. It's not B&W it's also the grey. The
NUMBER doesn't matter. It could be all, none, or something in between.

>> I also meant to take issue with the idea that many if not most people
>> confuse the number of editor users with the number of word processor
>> users. "Editor users" is a relatively small subset of people who
>> write.
>
> I'm not sure I noticed that issue but of course you are right.
>
>> The difference between the users and needs is large and confusion
>> doesn't help.
>
> I'm not sure of the relevance. We are talking about the "generally
> perceived" or noticed reaction to emacs by people who try it. My own
> experience is that most people go "yuck" - until they dig further and
> find what it can really do with a bit of work. Often it takes some hand
> holding. I know I had to gird my loins once or twice and dive back in
> when I had got frustrated with it.

Which is my point. Generalizing is impossible and unhelpful here.

>>> Can the general text editing population adapt and use it? Of course. But
>>> initial feedback is usually "what the hell!" :-)
>>
>> Again, this sounds like comparing emacs to word processors or windows
>> programs. What do you imagine the initial response is for people
>> foolish enough to open vi on a whim? For that matter Wordperfect
>> wasn't
>
> vi would be there too as something not particularly suited to new
> "general" users. But we were discussing emacs.

The point was about intuitiveness of emacs. I'm pointing out that the
emacs isn't unique or even different; the playing filed is basically
level. Powerful or simple for newbies; pick one.

>> exactly a model of intuitiveness and it did really well and continues as
>> a significant part of the legal world. I realize I just mixed word
>> processors with editors but my point was about the need to learn any
>> powerful tool.
>
> I agree. But as an editor some of the defaults are quite a hurdle to new
> users. There are not many seasoned users who would disagree with that I
> would think. The task is to convince new users that the effort and
> learning curve is worth it.

This sounds like more confusion about the users. Many if not most users
of text editors are programmers, agreed? You can't include word
processor users who want WYSIWYG stuff, we're talking pure text here. Of
the programming users, most will try an IDE and stick with it until they
find a need for something more powerful. At that point it is
unreasonable to expect high power and no learning. 

>>> I mean, have you seen peoples faces when they read the manual and realise
>>> they have to control/meta key sequences to move the cursor left and
>>> right, up and down?
>>
>> Actually no, I don't know any young people who use emacs and most older
>> folks were more interested in getting their hands dirty so to speak. 
>
> So you are arguing from a point of view with little practical experience
> of new users? 

I don't know any recent programmers who have jumped ship from their
favorite IDE's. On windows it's almost painful to not use Visual Studio.
In other worlds, Java has their own pretty popular stuff. The people I
know using standalone editors are experienced enough to not have real
problems. I know several who can't make up their minds about which
editor to use and in a sense they are new users. They simply don't
respond like you describe. 

>>> Please dont take these comments as support for what Xah is saying but
>>> there does tend to be a certain reluctance to make "common things" the
>>> standard in emacs which might, just might, promote adoption.
>>
>> I understand. I do wonder where this idea that emacs needs to be
>> competitive in the market comes from. I don't see that it really
>> matters
>> much to current users. People who use it will continue and developers
>
> It does to me. The more people who use it the better it will be
> maintained and the more utilities will be developed to a point of
> usefulness.

On what do you base that claim. How many emacs hackers do you know?

>> will continue to maintain. Why does the number of users matter? Like
>> my
>
> I like to advocate good OSS apps. Emacs is one such. I am surprised that
> you are not interested in furthering its use. Yet at the same time you
> have strong views on how it should or should not be tweaked to ease the
> learning curve for new users.

I'm interested in emacs, I'm not interested in evangelism. 

As for tweaking, I'm opposed to changes that will prevent users from
taking advantage of the large body of existing knowledge. There's a lot
of help available for the standard configuration, but there's relatively
little for people using the cua stuff, for example. To me it's simply
easier to get your feet wet and then figure out what you want to change
and how to make the changes. 

>> grandmother was fond of asking "If every one else sets themselves on
>> fire are you going too follow them"? I don't really care if everyone
>> move to editor X. Emacs works for me and I think it's a useful tool.
>> Other who want to use it are free to choose. 

> But it is rather naive to think that more users does not safeguard and
> enhance an application especially one which so much relies on users
> contributions and maintenance.

For commercial software you are probably correct. For much open or free
stuff I really don't think it makes all that much difference. The number
of maintainers isn't likely to change much if the number of users
increases by a factor of 10. It's pretty likely that a decrease of the
same magnitude probably wouldn't make much difference either. Most of
the maintainers are actually using emacs and maintain it for that
reason. Of course some features and "enhancements" might take longer or
never happen. 

>> I'd also add that much of this seems like a much ado about nothing.
>> Anyone who wants to change emacs or even fork the code is free to do
>> so.
>
> Don't be silly. We are talking NEW users. New users do not pile in and
> write elisp :-;

How come it's not new users complaining? It's existing users who think
it will help make emacs cool.

>> This seems like an attempt to convince current programmers that there is
>> a need to "fix" emacs or market share will shrink.  Even if that's true,
>> why does it matter? It's not like some company will get tired of
>> maintaining it and stop work.
>
> You seem almost as if you would not care if emacs lost users. This
> surprises me. I would like it to attract more and more. 

I would sleep just fine whether emacs was the most popular app on the
planet or if I was the last user. I have many more important things in
my life to worry about.

>>> Things are getting better - e.g I think using the x clipboard finally
>>> became the default in 22. Stuff like that.
>>
>> Clipboards are a good example of something that maintainers decided was a
>> useful change. I haven't seen anything that convinces me there is a
>
> It took a long time....
>
>> burning need to rearrange the default keyboard. For those who do feel
>> the need why not just distribute a .emacs file for dummies? The whole
>> thing seems to miss the point that emacs is nothing if not
>> configurable.
>
> I dont think anyone is suggesting any thing other than that. 
>
> Anyway, thats my tuppence worth. I do not offer a perfect solution only
> the reflection that anything that can be done to make Emacs easier for
> the new adopter which does not contribute it for the emacs power user
> can only be a good thing.

Keep in mind that these "improvements" will show up on every user who
updates, even the experienced users. Making available a special .emacs
to accommodate new people might be an acceptable option. That way the
people you seem to think exist will have fewer problems and the existing
user base will never have to waste time working around "improvements".

> Emacs is a wonderfully customisable work horse and well worth the effort
> needed to familiarise oneself with it.

Agreed.

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

[rustom]

On Oct 1, 6:37 am, stan <smo...@exis.net> wrote:
>
> I'm interested in emacs, I'm not interested in evangelism.

> I would sleep just fine whether emacs was the most popular app on the
> planet or if I was the last user. I have many more important things in
> my life to worry about.

This is a perfectly consistent view for one who is all-in-one: emacs
developer+user+creator.

But not for us more ordinary user-folk. When emacs dies I will be one
of the non-users -- maybe with grumbles or sadness or whatever.  But
ultimately those emotions will be irrelevant then.

> Making available a special .emacs to accommodate new people might be an acceptable option.
An XL-mode? -- emaX for Learners or alternatively the initials of the
most lovable member of this forum (wink)

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

[Sean Sieger]

    > I would sleep just fine whether emacs was the most popular app on the
    > planet or if I was the last user. I have many more important things in
    > my life to worry about.

    But not for us more ordinary user-folk. When emacs dies I will be one
    of the non-users -- maybe with grumbles or sadness or whatever.  But
    ultimately those emotions will be irrelevant then.

Why is eschatology creeping in here?

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

[Richard Riley]

stan <smoore@exis.net> writes:

> Richard Riley wrote:
>> stan <smoore@exis.net> writes:
>>
>>> Richard Riley wrote:
>>>> stan <smoore@exis.net> writes:
>>>>
>>>>> Xah wrote:
>>>>>> Kevin Rodgers wrote:
>>>>>>
> <snip>
>>> The point wasn't really about intuitiveness, that of course in the eye
>>> of the beholder. I certainly didn't wake up one day thinking in terms of
>>> emacs chords; I had to learn them. I don't really think emacs is worse
>>> than vim, wordstar, ed, edlin, or any of a dozen proprietary things I've
>>> been forced to endure. I expect to have some learning, and I don't
>>> expect it to match windows.
>>>
>>> My point was that generalizing about editor users is at best difficult
>>> and most often impossible. Arguments like "people are confused" are
>>> silly and not persuasive. Some are confused and others are happy as
>>> clams. 
>>
>> Only if one thinks in B&W. I think it was fairly obvious that Xah was
>> not suggesting for one minute that 100% of people were confused.
>
> I think you missed the point here. It's not B&W it's also the grey. The
> NUMBER doesn't matter. It could be all, none, or something in between.

Uhm, that was my point :-;

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

[rustom]

On Sep 29, 7:34 am, stan <smo...@exis.net> wrote:
>
> Actually no, I don't know any young people who use emacs and most older
> folks were more interested in getting their hands dirty so to speak.
>
> I understand. I do wonder where this idea that emacs needs to be
> competitive in the market comes from. I don't see that it really matters
> much to current users. People who use it will continue and developers
> will continue to maintain. Why does the number of users matter?

I studied computer science in '84 -- and I am an addicted user of
emacs. In '94 I even tried to write a mode like comint before there
was (or I knew of) comint.

I mention these things upfront so that you know my vintage and where I
am coming from.

You say that emacs does not need new users and does not need to be
competitive in the market-place.
From 84 to now Ive seen a lot of things come and go. Many of the
things that went were probably replaced by 'better' things..... But
not always. Consider for example:

-- APL is dead.  Those who say Java (or whatever) is superior to APL,
have never used it. APL and Scheme were some of my most epiphanic
experiences.
-- Lisp is not dead but is not doing too well. emacs is responsible
both for its liveness and its ill-health. emacs-lisp was obsolete in
the mid-80s when common lisp and scheme replaced lisp. Anyhow this is
not my main point...
-- Norton/midnight commander etc are gone. Now we have windows
explorer and clones. Anyone whose used both will know what a drop in
productivity that is.

Well thats just a few things off the top of my head.  Others as old/
older than me can make similar lists... thats not my main point.

The emacs devs who make and maintain emacs are doing a great service.
I am personally beholden to them. But let me just ask -- What is their
average age?  More importantly, is this average age static or
increasing?
I dont know the answer to these questions but from my guestimates,
emacs will be dead in 10 years. (rms already cannot type).

So...

I agree with Xah though he unfortunately loses his punch by punching
too hard.

So let me restate his argument (in civilised language):

-- When emacs starts up it shows a buffer in Lisp interaction mode.
To what percentage of actual/wannabe emacs users is this mode
meaningful?

-- Even if buffer-offer-save is on C-xC-k asks but menu-close does
not. Is this not a bug?

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

[Richard Riley]

rustom <rustompmody@gmail.com> writes:

> On Sep 29, 7:34 am, stan <smo...@exis.net> wrote:
>>
>> Actually no, I don't know any young people who use emacs and most older
>> folks were more interested in getting their hands dirty so to speak.
>>
>> I understand. I do wonder where this idea that emacs needs to be
>> competitive in the market comes from. I don't see that it really matters
>> much to current users. People who use it will continue and developers
>> will continue to maintain. Why does the number of users matter?
>
> I studied computer science in '84 -- and I am an addicted user of
> emacs. In '94 I even tried to write a mode like comint before there
> was (or I knew of) comint.
>
> I mention these things upfront so that you know my vintage and where I
> am coming from.
>
> You say that emacs does not need new users and does not need to be
> competitive in the market-place.
> From 84 to now Ive seen a lot of things come and go. Many of the
> things that went were probably replaced by 'better' things..... But
> not always. Consider for example:
>
> -- APL is dead.  Those who say Java (or whatever) is superior to APL,
> have never used it. APL and Scheme were some of my most epiphanic
> experiences.
> -- Lisp is not dead but is not doing too well. emacs is responsible
> both for its liveness and its ill-health. emacs-lisp was obsolete in
> the mid-80s when common lisp and scheme replaced lisp. Anyhow this is
> not my main point...
> -- Norton/midnight commander etc are gone. Now we have windows
> explorer and clones. Anyone whose used both will know what a drop in
> productivity that is.
>
> Well thats just a few things off the top of my head.  Others as old/
> older than me can make similar lists... thats not my main point.
>
> The emacs devs who make and maintain emacs are doing a great service.
> I am personally beholden to them. But let me just ask -- What is their
> average age?  More importantly, is this average age static or
> increasing?
> I dont know the answer to these questions but from my guestimates,
> emacs will be dead in 10 years. (rms already cannot type).

I dont think that will happen. It will not "die" but it certainly needs
an injection of new users to motivate the troops once more. There are
wonderful things being done by a new breed but more are necessary
IMO. Look at the work by Sacha Chua, Lennart Borgman, Tassilo Horn,
Carsten Dominic, Bastien Guerry to name a few of the more prominent and
talented Emacs hackers and evangelists. Emacs is being used in fewer and
fewer development houses as far as my observations go. And this has led
to pretty much a freeze in improvements to ecb and cedet for
example. And this leaves emacs way behind in the functionality stakes
when it comes to things like context API help, auto completion and
similar. I might be mistaken and missed something there but it just
seems that way. One tool which I love from these developers is nxhtml
and the other is the wonderul org-mode.

>
> So...
>
> I agree with Xah though he unfortunately loses his punch by punching
> too hard.
>
> So let me restate his argument (in civilised language):
>
> -- When emacs starts up it shows a buffer in Lisp interaction mode.
> To what percentage of actual/wannabe emacs users is this mode
> meaningful?

Guess? 1% if that. People who need a scratch can write some elisp to
bring it up themselves :-;

>
> -- Even if buffer-offer-save is on C-xC-k asks but menu-close does
> not. Is this not a bug?

I would agree with your post 100%.

The "I'm alright Jack" posts do nothing to help and would horrify the
originators of such code who invested their time and effort with the
intent of getting the message out to a bigger public and create a self
momentum which would lead to bigger and better things.

Lack of interest has already seen quite a few projects go stale.

regards

r.

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

[Chetan]

It looks like it is difficult to get everyone to agree on what is
needed. Isn't it better to create addons that people can install if
they so desire? That way there is no immediate change forced onto the
users. The addons that are popular can later be incorporated into
main. 

Just a thought.

-Chetan

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

[Paul R]

On Mon, 29 Sep 2008 09:56:22 -0700, Chetan <Chetan.xspam@xspam.sbcglobal.net> said:
Chetan> It looks like it is difficult to get everyone to agree on what
Chetan> is needed. Isn't it better to create addons that people can
Chetan> install if they so desire? That way there is no immediate
Chetan> change forced onto the users. The addons that are popular can
Chetan> later be incorporated into main.

Emacs is the most extensible and the most community-extended software
created ever. This thread is about *defaults*, because defaults drive
user habits, because defaults are why most people stick to a software
or give up in the first few days, because defaults are the reflect of
an evolving mindset amongst core developers.

There is absolutly no problem to extend emacs and to customize it for
your needs. It is great for that already.


-- 
  Paul

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

[Alexey Pustyntsev]

Hi!

Paul R <paul.r.ml@gmail.com> writes:

> On Mon, 29 Sep 2008 09:56:22 -0700, Chetan <Chetan.xspam@xspam.sbcglobal.net> said:
> Chetan> It looks like it is difficult to get everyone to agree on what
> Chetan> is needed. Isn't it better to create addons that people can
> Chetan> install if they so desire? That way there is no immediate
> Chetan> change forced onto the users. The addons that are popular can
> Chetan> later be incorporated into main.
>
> Emacs is the most extensible and the most community-extended software
> created ever. This thread is about *defaults*, because defaults drive
> user habits, because defaults are why most people stick to a
> software

I seriously doubt that sticking to highly customizable software is
necessarily based on its defaults. 

> or give up in the first few days, because defaults are the reflect of
> an evolving mindset amongst core developers.

Considering the people that use Emacs, I think the defaults should be
as neutral as possible. Honestly, my first impression of Emacs was
rather unfavourable, but I must admit that was exactly due to my
habits spoiled by MS mainstream software. However, that didn't bar me
from the Emacs users club. Once I started trying to find answers to my
questions in the Emacs documentation, it became more and more evident
how erroneous my conclusion was. So, I think the best approach to
resolve the 'new blood' problem is to focus  on **how and what Emacs
can do for you** (EmacsWiki is doing good job) than on what its
current defaults are. There is no need to worry about the defaults
very much. They may be changed, of course, but, actually, there is no 
problem with them since they are easily customizable. Some people are
just making a storm in a teacup. After all, Emacs is not just an
editor, it's a whole lisp environment.  

-- 
Rgds
Alexey

Today is Prickle-Prickle, the 55th day of Bureaucracy in the YOLD 3174

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

[Paul R]

Hello Alexey,

Alexey> Considering the people that use Emacs, I think the defaults
Alexey> should be as neutral as possible.

I agree and I define "neutral" as "what most newcomers expect".

Alexey> There is no need to worry about the defaults very much. They
Alexey> may be changed, of course, but, actually, there is no problem
Alexey> with them since they are easily customizable. Some people are
Alexey> just making a storm in a teacup.

Default behaviour of the surface of any software, including emacs, can
frustrate newcomers to a point at wich they drop it.

In this field, my 5+ years experience with observing newcomers to
emacs is exactly the opposite of your conclusion. Namely, people
droping emacs because of the default keybindings.

Alexey>  After all, Emacs is not just an editor, it's a whole lisp
Alexey> environment.

How long did it take you to realize and fully understand the meaning
of this statement ? Users giving up before this period of time will
never understand it.

-- 
  Paul

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

[xraysmalevich]

On Sep 30, 9:37 am, nos...@dev.null (Alexey Pustyntsev) wrote:

> Considering the people that use Emacs, I think the defaults should be
> as neutral as possible.

Can you imagine how "fun" Emacs would be if it -- by default --
started out adding wrinkly-lines under all of our mis-spellings, or a
little cartoon Gnu popped-up in the corner saying "It looks like
you're trying to open a new temporary buffer! Would you like to open a
file, instead?"

::shudder::

-the Other michael

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

[Nikolaj Schumacher]

Xah Lee <xah@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

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

[xraysmalevich]

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!


On Sep 19, 7:34 am, Xah Lee <x...@xahlee.org> wrote:
> 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/
>
> ☄

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

[Xah Lee]

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/

☄

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

[xraysmalevich]

On Sep 19, 10:13 am, Xah Lee <x...@xahlee.org> wrote:
> 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/
>
> ☄

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

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

[Xah Lee]

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/

☄

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

[Eli Zaretskii]

> From: Xah Lee <xah@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.

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

[Xah Lee]

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/

☄

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

[Eli Zaretskii]

> From: Xah Lee <xah@xahlee.org>
> Date: Fri, 19 Sep 2008 07:32:11 -0700 (PDT)
> 
> Hi Eli moron,
> [...]
> Fuck you.

Out of arguments again, eh?

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

[Alan Mackenzie]

Xah Lee <xah@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).

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

[Xah Lee]

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/

☄

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

[Cor Gest]

Some entity, AKA Xah Lee <xah@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.

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 

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

[Xah Lee]

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/

☄

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

[Lowell Gilbert]

Eli Zaretskii <eliz@gnu.org> writes:

> Out of arguments again, eh?

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

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

[Alan Mackenzie]

Xah Lee <xah@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-devel@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?

[ .... ]

>  Xah

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Xah Lee]

On Sep 19, 1:36 pm, Alan Mackenzie <a...@colin2.muc.de> wrote:
> It is necessary to have _some_ buffer when starting Emacs.

Not really. If you look at most apps, they provide either untitle or
empty page, and has user pref to set whether to do that or just have
nothing.

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

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

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

To answer your question or help you think more specifically, you can
actually try to spend 1 hour thinking about this specific issue. Start
with, for example, how many people in the world actually code elisp.
What's the percentage with respect to programers. What's the
percentage with respect to all IT professionals. (look up definition
or ask a professor in social science department on what is meant by
“IT professional”) Also, think about what emacs is supposed to be, and
think about its relation to writers. Think about how many writers are
there in the world, what's their percentage with respect to, say,
programers.

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

> Even when it is not used, it's
> not that big a nuisance.

To you, a emacs tech geeker, doesn't seems a nuisance. To your
grandma, or even most professional, or another tech geeker of the vi
faction, it stops them using emacs.

> >    * The ?*scratch*? ?buffer? is primarily designed for elisp
> > programers. (it defaults to lisp mode) Majority of people who use
> > emacs are not lisp coders. For lisp coders, they can easily customize
> > their emacs to have a ?*scratch*? ?buffer?.
>
> It's designed for any rough notes, including bits of Lisp.  The only
> thing here I found bothersome was having C-j bound to
> `eval-print-last-sexp', but I just rebound it to `newline-and-indent'.
>
> >    * The ?*scratch*? ?buffer? is a intrusive idiosyncrasy. It is
> > persistent, cannot be closed (it regenerates). It is foreign to all
> > programers. This idiosyncrasy is the first thing presented to users,
> > and it persists.
>
> Have you considered coding an option so that this buffer would only be
> created when, at startup time, there was no other buffer?  And coding
> another option so that when you killed it, it would stay killed?  Write
> a patch, and submit it to emacs-de...@gnu.org.  It might well be
> accepted for Emacs 23.

Please understand, the issue is not:

(1) whether i should write a patch,
(2) nor is it about writing a patch that do something you think is
better.

To illustrate (1), for example, suppose you say that fucking in the
ass is not moral and government should ban it. Then someone says why
don't you stop fucking in the ass yourself.

To illustrate (2), suppose you say that fucking in the ass should be
better done with lubes first. Then someone says why don't you try to
fuck in the ass with butter.

> [ .... ]
>
> > Proposed Fix
> > I propose that emacs should also add a menu command ?New buffer?, with
> > the keyboard shortcut ?Ctrl+n?. Once called, it should create a
> > scratch buffer titled ?untitled?. If one already exists, append
> > numbers such ?untitled 2?. Here are the reasons:
>
> As you know very well, there's already an important binding for C-n.

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

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

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

For keybinding issues on this, see the above paragraph.

> >    * The Ctrl+n shortcut for New is standard and familiar to all
> > software users.
>
> That's not true.  It's not familiar to me.

You are not a typical software user. You are a tech geek.

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

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

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

See above.

> >    * By adopting the New Buffer and Ctrl+n, users can intuitively
> > create multiple scratch buffers for any purpose.
>
> Being able to create several *scratch*'es might well be useful.

Yes. Thank you.

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

it's not umimportant trifle. Familiarity is important aspect of
software usability.

> >    * For those who uses scratch buffer for elisp coding, she can set
> > the default mode for untitled buffer to emacs lisp mode.
>
> Or, more precisely, Lisp Interaction Mode.

you are right. Thanks for correction.

> But this option exists
> already: `initial-major-mode'.

Yes, but what's your point?

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

Thanks for your feedback.

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

You suggested few times about how i should code elisp in some way and
submit the patch. Perhaps, let me suggest to you, that you should try
to take what code i have, polish it, and start a discussion in emacs
dev lisp, and send the patch into GNU emacs.

  Xah
∑ http://xahlee.org/

☄

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

[Alan Mackenzie]

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

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Xah Lee]

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/

☄

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

[Nikolaj Schumacher]

Xah Lee <xah@xahlee.org> wrote:

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

Correct.  That's how apps are supposed to behave on Macs according to
the human interface guidelines.  It's more document than app based.

However this mechanism can't simply be adapted for other operating
systems.  On Windows and most X systems, closing the last window is
expected to terminate the application and there's no way to access a
window-less application (other than notification area hacks).  So this
is not a viable solution.


regards,
Nikolaj Schumacher

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

[Sean Sieger]

Xah Lee <xah@xahlee.org> writes:

    Execuse my French

Is that what language you write in?  It looks like poorly written and
proofed English.  Or, do you mean French is another programming language
that you're not proficient in?

    Ok, quickly typed out n no time to edit.

You're starting to see what I see.  You mentioned your typing speed---as
a secretary, I think you said---was `80 wpm'.  Usually, Xah, erroneous
typing doesn't count, it diminishes your score.  The way you type leads
me to believe that you don't touch-type well on Qwerty or Dvorak
keyboards.  I don't mean to insult you, but rather point out the
incongruity with your seemingly immense interest in ergonomic typing
configurations.  My experience has been that good typists, well, type
well ... in some language.

I hope you find a text editor and a mail list that you are happy with
some day.

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

[Xah Lee]

On Sep 22, 9:58 am, Sean Sieger <sean.sie...@gmail.com> wrote:
> XahLee<x...@xahlee.org> writes:
>
>     Execuse my French
>
> Is that what language you write in?  It looks like poorly written and
> proofed English.  Or, do you mean French is another programming language
> that you're not proficient in?
>
>     Ok, quickly typed out n no time to edit.
>
> You're starting to see what I see.  You mentioned your typing speed---as
> a secretary, I think you said---was `80 wpm'.  Usually,Xah, erroneous
> typing doesn't count, it diminishes your score.  The way you type leads
> me to believe that you don't touch-type well on Qwerty or Dvorak
> keyboards.  I don't mean to insult you, but rather point out the
> incongruity with your seemingly immense interest in ergonomic typing
> configurations.  My experience has been that good typists, well, type
> well ... in some language.
>
> I hope you find a text editor and a mail list that you are happy with
> some day.

Huh?

You want to compare typing speed? This we can actually carry out
online. One way, is to go to a public irc such as freenode's, then
there are a lot public websites that score your typing speed. So, we
meet in irc, agree before hand what nick name to use for the typing
websites, then in real time each of us go type and get the score, then
we can compare the score.

Sure, it's not a complete fool proof way to compete typing speed, but
it's fairly practical.

You want to see my typing speed (counting accuracy) beat the hell of
ya ass? Let's meet in irc. Let me offer you the address:
irc.freenode.net, channel #elisp or channel #xahlee. You can arrange a
time n i'll be there.

One time, i challenged a lisp coder aka campbell(sp?) on irc. (the
author of emacs's parenedit mode, real name Taylor something i think
(too lazy to check)) He's score actually beat me by some margin and i
was shocked ... kinda hard to believe. I'll have to sit face to face
to believe for sure, but for now i'll say he beat me. (and he
purportedly is using qwerty on a labtop. (while i'm on a full
Microsoft ergo ekeyboard and dvorak))

Similarly, lots of tech geeking fuckheads brag all day and night about
command line, ratpoison, and shit. I tell you, my computer operating
efficiency beats all of you. Seriously. All we need to test this is to
device some way to score computer operation... switching between apps,
browsers, carried out some tasks like saving images, write notes, ...
though a good standard test would be hard to come by ...

which lead me to another point: emacs operating efficiency. In many of
my emacs discussions on modernization and ways of operation induced by
UI, all tech geekers brag about how emacs way is efficient. I openly
challenge anyone, that:

1. Emacs default ways of operation is not necessary more efficient
(with regards to speed of carrying it out) when compared to modern UI
such as AquaMacs.

2. If you are accustomed with my ergonomic keybinding, i bet that
using it is far more faster than emacs default keybindings.

It is actually not very difficult to verify the above. All we need is
a standard set of text manipulation tasks. Such a task set is not too
difficult to design. For exmalpe, just off the top of my brain now....
you can start with 2 text files, and these two files should become 5
more files, with instructions on which text must go where... etc. The
task set, ideally, will involve most things you do in emacs daily,
such as searching source code, refactoring, getting info from the web
and put them back in somewhere, etc. If one is serious, you could
spend a week and come up with this task set.

In this way, we could actually have a emacs operating tournament with
prize money.  Competitors may require to pay say $10 for registration.
FSF could conceivably host it.

In such a tournament... we can see who can really operate emacs faster
or with better knowledge of using emacs. But this would be boring. It
would be more fun, to see if a team of emacsers using the default
emacs UI vs a team using modern UI such as AquaMacs or emacsW32, or a
team using traditional emacs UI but with my ergonomic keybindings.

... in the past year i've had thought of writing a game in elisp. You
know how you have typing games, where letters or words falls from sky
and you have to type them fast before they hit the ground. In a
similar way, my Emacs Operation game, a window might be split into 2
panes (emacs speak: frames in 2 windows), where one is user area and
the other is the example area, where the example area contains a
example text with instruction on what final result should be like, and
the user types in his pane to create identical text in the example
area, using all emacs commands to carry out the task. This game will
be timped and keep score, based on correctness and speed, and can have
levels, from tasks requiring basic operation such as cut, copy, paste,
paste previous, kill-line, undo, kill-word, kill-word-backward,
isearch, to more advance that are done with say using keyboard macros,
using narrow-to-region, regex replace, isearch, rectangle, registers,
switching mode, switching or listing buffers, deleting buffers, using
dired, nav info, and perhaps at the boss level will require to write
simple elisp command on the spot for the best score.

in the above, the game is a real time based game. That is, the clock
is ticking and your score depends on speed. In another twist, the game
can be made into a flash-card quize or knowledge testing based, where
each question asks you to do something and you have to carried it out
in order to pass, without a time limit. You might be able to ask hint.

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

... besides my daydreaming, in reality i dont think i'll ever write
such a game in elisp consider that the task is rather daunting and the
result is comparatively not worthwhile for me. The time spend in elisp
for this i'd rather spend say, to learn coding games with a 3D engine.

  Xah
∑ http://xahlee.org/

☄

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

[Ted Zlatanov]

On Mon, 22 Sep 2008 10:56:01 -0700 (PDT) Xah Lee <xah@xahlee.org> wrote: 

XL> You want to see my typing speed (counting accuracy) beat the hell of
XL> ya ass? Let's meet in irc. Let me offer you the address:
XL> irc.freenode.net, channel #elisp or channel #xahlee. You can arrange a
XL> time n i'll be there.

I can beat your typing speed any time.  I can paste text at about 1800
WPM, give or take a few.  Perfect accuracy.

Ted

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

[Xah Lee]

On Sep 22, 12:15 pm, Ted Zlatanov <t...@lifelogs.com> wrote:
> On Mon, 22 Sep 2008 10:56:01 -0700 (PDT)XahLee<x...@xahlee.org> wrote:
>
> XL> You want to see my typing speed (counting accuracy) beat the hell of
> XL> ya ass? Let's meet in irc. Let me offer you the address:
> XL> irc.freenode.net, channel #elisp or channel #xahlee. You can arrange a
> XL> time n i'll be there.
>
> I can beat your typing speed any time.  I can paste text at about 1800
> WPM, give or take a few.  Perfect accuracy.

in most typing websites, copy & paste won't work. Typically they show
only a small section of sentence to type. Websearch “typing tutorial”
or “typing program” or “typing applet”... you'll find them. Some are
javascript based, some are java applets.

  Xah
∑ http://xahlee.org/

☄

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

[Alan Mackenzie]

Hallo again, Xah!

On Mon, Sep 22, 2008 at 06:07:34AM -0700, Xah Lee wrote:
> On Sep 20, 1:17 am, Alan Mackenzie <a...@muc.de> wrote:

[ .... ]

> > > > I don't know where you get your figure of 99% [of people for whom
> > > > *scratch* is supposedly not useful] 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.

You're really not in touch, are you?  Many of the Emacs developers,
probably most, possibly even all are professional programmers.  I
certainly am.  Developing Emacs would be well beyond the capabilities of
all but a tiny number of hobbiests.

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

I'm sorry about that (the day job).  Do you want one?  A danger of
learning Lisp is becoming aware of the shortcomings of lesser languages
(nearly all others).

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

Er, this morning.

[ .... ]

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

You mean you haven't understood it?  I'll try and explain it more
clearly.

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

That's not the sense in which the comment is made.

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

Yes.  When Emacs was written, back in the mists of time, it was written
purely as a programmers' editor.  Like many other great programs, it was
later found to be useful for other tasks than its intended one, one of
these being editing normal text.  This contrasts with, for example, word
processing programs.

[ .... ]

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

Really?  Funnily enough, you list Emacs in joint second place (along with
vim).  The most popular (Microsoft Visual Studio) is an IDE, with a
severely restricted range of application, so it's not really comparable.

[ .... ]

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

That's far from clear.  Often the winner in the market is not the
(technically) best product.

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

Indeed.  And that code was so amazingly good that it was grabbed by
masses of good programmers.  It was and is so good that it's still
thriving after 25 years.

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

I see a lot of your points.  I just disagree with most of them.

[ .... ]

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

That's a entirely different thing from there being no user level
function.  What you've written on this page is not true.  I'm suggesting
you replace it with a sentence saying "C-x b is not very good for ....".

> To begin, the name is switch-to-buffer.

This richness of functionality is pretty much essential to Emacs.  The
alternative would be to have many more different commands.  If you put
the question "what happens when you do C-x b, giving it a name which
isn't an existing buffer?" there are two sensible answers: signal an
error, or create that buffer.  Which do you think is more useful?  (That
isn't a rhetorical question.)

> Also, emacs doesnt offer to save a buffer not associated with file, so
> you have potential data lose...

Yes, you do.  This is closely related to personal working style, and it
would be good for there to be an option to prompt when killing such
buffers.  I've already suggested you write this.

> I also give reason why C-x C-f is unfit, because it prompt for a file
> name...

You've said this, but I can't see what you're getting at.  Why is
prompting for a file name when you open the buffer worse than prompting
for it when you save it?

[ .... ]

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

I am indeed familiar with C-n, as the key binding for `next-line'.  I'm
not familiar with it as "open a new file", because I don't use that sort
of software very much.

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

So the criterion for being bizarre and silly is not knowing Ctrl+n??? ?
Come on, old man, you can do better than that!  ;-)

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

No, I'm ambivalent about it.  It works, but it's rather obscure.  It took
me longer to find than it should have done.  But then, taking a new
buffer's characteristics from an existing one is less hassle than having
to type them in explicitly.  It would be nice if there was a more obvious
command to do this, but I can't fomulate this new command myself.

[ .... ]

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

Yep, you sound very rude indeed here.

But extracting the substance from that paragraph, what exactly do you
find so outrageous in what I wrote?  It's almost like we're talking at
cross purposes, using the same words to mean different things.

When I say "ease of use", I usually contrast it with "ease of learning".
Emacs is very easy to use, but very hard to learn.  By easy to use, I
mean that (i) typical actions need few key presses to activate them; (ii)
Emacs doesn't get in your way: it doesn't obscure your text with annoying
dialogue boxes, it doesn't pester you with silly "are you sure?" prompts,
and, in the main, doesn't have precarious state which you could destroy
by an accidental keypress.

I think you mean something different by "usability", and I'd be
interested in hearing you say what you mean.

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

Maybe you could suggest a few URLs for me.  But one thing's clear:
different people work best with different tools, sometimes radically
different.

[ .... ]

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

No.  The project's maintainers (Stefan Monnier and Chong Yidong) have the
final say.  I've not suggested you fork Emacs.  Merely that you
contribute some code.

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

Neither does most commercial software, for that matter.  For several
types of software (software development, networking, servers, ....), free
software is prominent or dominates, whereas in others (games ...) it's
hardly there at all.

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

Just to clarify, Lucid Emacs was always free software.  It had a
commercial sponsor for some time, like (e.g.) Apache does today.

> you want emacs to improve? think more, and get away from tech geeker
> mindset.

How so?  Emacs is intended for the "tech geeker mindset".  How will
getting away from this help emacs improve?

> Go to college and study more about humanities. Your thoughts on
> software will improve far more than decades of tech geeking and
> slashdot.

No thanks!  I graduated from university some considerable time ago, and
I'm not going back for another stint.

[ .... ]

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

I wasn't trying to start a philosophical discussion here.  I was telling
you that if you swear and curse on this sort of newsgroup/mailing list,
you will offend people (who will thus ignore you) and others won't take
you seriously.  I am trying to help you communicate better.

[ .... ]

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> I'm sorry about that (the day job).  Do you want one?  A danger of
> learning Lisp is becoming aware of the shortcomings of lesser
> languages (nearly all others).

Strike "lesser", "all" and "others".  You become aware of the
shortcomings of greater languages as well, and of Lisp itself.

If I take a look at the Allegro Assai in Sonata III for violin solo from
J.S.Bach, it is completely unnecessary to put fingerings in the score.
There is just one sane way to play it.

The score is, in a way, an instrument-neutral way of describing music.
And you can play this particular score on the piano, for example.  And
it will be perfectly recognizable.  You can't play most piano scores on
the violin, in contrast.  The violin is a lesser instrument with fewer
possibilities.  It takes a good craftsman to create music where the
violin appears like a perfect instrument, unrestricted.  It takes Bach
to turn the restriction into a benefit and create music where the
various counterpoints sit on different strings and thus get a different
color.

This is one of the reasons why the famous organ "Toccata and Fugue in D
minor" which does not exercise quite a few of the possibilities of an
organ is nowadays believed to be an adaption from a lost piece for solo
violin.  When transposed into A minor (hm, on a viola you would not even
need to transpose), you get something where even all the "dazzling"
passages and styles have a playable rendition on the violin, something
which is far from likely.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Alan Mackenzie]

Hi, David!

On Tue, Sep 23, 2008 at 12:36:38AM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > A danger of learning Lisp is becoming aware of the shortcomings of
> > lesser languages (nearly all others).

> Strike "lesser", "all" and "others".  You become aware of the
> shortcomings of greater languages as well, and of Lisp itself.

"Greater" than Lisp?  Assuming we're talking generically about Lisp, not
just Emacs Lisp, please give me an example of a greter language.  (This
isn't a rhetorical request; I'm genuinely interested.)

> If I take a look at the Allegro Assai in Sonata III for violin solo
> from J.S.Bach, it is completely unnecessary to put fingerings in the
> score.  There is just one sane way to play it.

Do you play the violin?  If, additionally, you can play a Bach solo
sonata on it, massive respect!

> The score is, in a way, an instrument-neutral way of describing music.
> And you can play this particular score on the piano, for example.  And
> it will be perfectly recognizable.

Well....  Up to a point.  The percussive nature of a piano, and its
richer harmonics will pretty much kill what JS wrote.  Also, a piano
can't play in tune as well as a violin.  (Of course, it can't play as
badly out of tune either ;-)  A skilled violinist can play nearly exact
intervals, where a perfect fifth is indeed perfect, a ratio of 1.5.  The
nearest a piano can get is 2^(7/12) = 1.4983.  A major third is even
worse, at 1.26 rather than 1.25.

> You can't play most piano scores on the violin, in contrast.  The
> violin is a lesser instrument with fewer possibilities.  It takes a
> good craftsman to create music where the violin appears like a perfect
> instrument, unrestricted.  It takes Bach to turn the restriction into a
> benefit and create music where the various counterpoints sit on
> different strings and thus get a different color.

> This is one of the reasons why the famous organ "Toccata and Fugue in D
> minor" which does not exercise quite a few of the possibilities of an
> organ is nowadays believed to be an adaption from a lost piece for solo
> violin.  When transposed into A minor (hm, on a viola you would not even
> need to transpose), you get something where even all the "dazzling"
> passages and styles have a playable rendition on the violin, something
> which is far from likely.

JSB was one of the last composers where you could play most of his
(instrumental) works on just about anything.  The 48 is good music
regardless of whether it's played on a harpsichord, an organ or a piano,
or even a brass band (but I'd draw the line at the Swingle Singers).

Anyhow, we're now as much off topic as the rest of this thread.  ;-)

> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Xah]

Alan Mackenzie wrote:
> "Greater" than Lisp?  Assuming we're talking generically about Lisp, not
> just Emacs Lisp, please give me an example of a greter language.  (This
> isn't a rhetorical request; I'm genuinely interested.)

From my experince, the one language that is a ORDER OF MAGNITUDE
greater than lisp is Mathematica.

I haven't had a essay that is focused on “which language is better
than lisp”, but have written maybe 3, two thousand words essays on
issues very similar to this. If you read them, you can see why:

See:

Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html

My First Encounter And Impression Of Lisp
http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html

The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested
Notations
http://xahlee.org/UnixResource_dir/writ/notations.html

Each of the above article also links to several others, that either
support specific detail or to related issues. So, the totaly number of
essays on lisp as a language might be 15 or 20. e.g.

    * Lisp's List Problem
    * Is Lisp's Objects Concept Necessary? (thoughts on the model of
Lisp language)
    * The Importance of Terminology's Quality In A Computer Language
    * The Jargon “Lisp1” vs “Lisp2” (why should we avoid these
jargons)
    * What Is Closure In A Programing Language
    * The Term Currying In Computer Science
    * The Jargon “Tail Recursion”
    * Jargons And High Level Languages (unpolished essay)

... now, my opinion that Mathematica the lang being better than lisp
is based on me being actually the world's top expert on the language,
and a expert on emacs lisp. However, it is my opinion, Haskell, OCaml,
etc languages are easy candidates as better than lisp, albeit i do not
know these languages. On this note, see also this essay:

Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html

Just so you have a background context on my above opinions on
languages, besides being a world's top expert of Mathematica, i'm a
master at Perl and PHP, expert at Python, Java, Javascript, elisp. For
example, you can see my book length tutorials on these languages from
my website.


For your reading convenience, here's the plain text version of one of
the essay:
-------------------------

Xah Lee's Computing Experience Bio
(My First Encounter And Impression Of Lisp)

Xah Lee, 2008-01-28

[The following gives a brief outline of one aspect of my computing
experience. In particular, it outlines my first encounter and
impression of the lisp language. This was originally written as a
reply tangential to a thread in the online forum comp.lang.lisp]

Here's some personal story about how i ventured into lisp and my first
impression.

The path of my computing experience is kinda unusual like most other
things about me. In 1991, i was 23, and was attending a 2-year
community college in California. (DeAnza College and Foothill college)
(i have never had highschool (more or less never had a _chance_ to,
actually.))

During these college years (which is about 1991-1994, rather unusually
long for a 2-year community college), i've took all math courses they
offered (roughly equivalent to math classes of first 2 years in a 4
years university; culminating in multi-var calculus and a intro course
on Differential Equations and Linear Algebra, but no Abstract Algebra
nor Analysis proper), but i've never took any computer science
courses. (i think i might have taken a Pascal course)

It is also during the early 1990s, i started to learn programing on my
own. My first “language” is the one in HP-28s programable scientific
calculator. I remember having wrote a program to solve the 8-queens
problem all on my own. (without knowing or heard of the term back-
tracking) (see HP-28S Advanced Scientific Calculator )

And, during these years i bought Mathematica (because i heard it's the
best math tool and i love math and wanted to have the best tool). I
taught myself Mathematica and wrote some programs for visualizing
plane curves, which later got me hired at Wolfram Research in 1995 as
a intern. (see Visual Dictionary of Special Plane Curves)

By 1997, i'm one of the world's top Mathematica-programing expert. But
the curious thing is that, i have absolutely no idea what is a
compiler, parser, lexer, and absolutely have no faintest idea how
Operating System worked or its basic structure or purpose in technical
terms, and have absolutely no idea how networking worked. Do not even
have a practical concept of what's a computing protocol (such as TCP/
IP, HTTP/FTP, NFS ...etc.). Absolutely do not know anything about
“unix”, and vividly remember that i don't know what is “tar” and
“gzip” (just knew that these are in some exotic “unix workstations”
and some mysterious org or movement called “GNU”). (during all these
years up to 1997, i was using Mac, being what a Mac fan might call a
“power user” (as a computer user (as opposed to a programer); and
using the mouse; in the days when Macs are just Finder and Multi-
Finder, and used by Desktop publishing, with MacUser and MacWorld
magazines publishing tricks and software application reviews etc.
(e.g. Microsoft Word, Word Perfect, Nesus Writer,
Spreadsheets...etc)))

I must stress, i have absolutely no concrete idea about anything that
a normal computer science student would know in his first or second
year. I do not have any concrete idea what IS a language specification
(such as Java lang spec or Common Lisp “Hyperspec” or Emacs Lisp
Reference Manual, etc) I have close to absolutely no knowledge to how
ANY other computing languages. Put in another way, i wouldn't know how
to write a Hello Word in any other language. I do not know, what
exactly is compiling and linking, just knew they are something “real”
programing languages have to do before a program can run. I have no
notion of what's a “white paper”, “functional programing”, and DO NOT
understand (or even heard of) the meaning of “side effect” (in the
context of functional programing). (i vividly recall, the first time i
heard the term “side effect”, is in 1995 when i was trying to
describe, in some verbose manner, a nature of the code i wrote, to
Methamtica creator Stephen Wolfram (in the sense a student is trying
to present his idea), and he said “[you mean] side effect ...”, and i
was like “Yeah, exactly, ‘side effect’!” (and feeling enlightened how
the phrase described the situation well).)

The gist of this is that, from my programing experience from 1991 to
about 1997, i learned programing only in HP-28s and Mathematica, by
mostly the shear reading of their manuals from cover to cover
(practically several times), while having just about no concept of any
basic computer science ideas. (However, I am familiar of many
computing related mathematical concepts, such as algorithm, algorithm
efficiency order (typically expressed as “computation complexity” or
“O(n)”), because i love math and have studied some discrete/finite
math on my own. (But, for example, i do not at the time know
Algorithms that are typically taught to CS students, such as sorting
algorithms. I have tried to read Knuth's Art Of Programing but it was
pretty incomprehensible (To understand Knuth's books, one has to be
familiar with assembly languages, since he uses MMX, which is a
artificial assembly language).))

From about 1997 onwards, i started to study most of these things,
starting with unix and perl, by sheer reading of the manuals and
documentations and industrial books (e.g. O'Reilly) and hands on
coding in them. (by 2000, i'm a fair expert of unix admin and perl,
with knowledges in SQL/database, working knowledge of IP protocols...
etc, actually working in start-ups in Silicon Valley's tech boom since
late 1998, to write web-based applications (e-store).)

Ok, the main point i started to write this personal history, is my
first encounter with Lisp. (the previous paragraphs are just intro.)

Although lacking a formal or conventional education, i'm by birth
highly intelligent and by nature very curious. This means i have read
a lot of books or texts or literatures i have in contact with and in
library (was a avid library visitor), such as the massive number of
programing FAQs and FAQs of other subjects (such as BDSM) etc. (FAQs
were widely popular in the 1990s, somewhat analogous to today's
Wikipedia) So, it is very present in my awareness, that there is a
language called Lisp, associated with the phrase Artificial
Intelligence (the very phrase, at face value, excites me greatly), and
is supposed to be extremely powerful and beautiful. And, at the time,
i have heard, that Scheme, is the most beautiful and elegant language
that exists. (this is my reading impression, anyway) And, i heard that
the book “The Structure and Interpretation of Computer Programs” by
Harold Abelson et al, is the best computer science book. So, i started
to read it and learn Scheme.

Remember, at the time i'm a master of Mathematica _the language_
itself, yet do not know much about the typical concepts and knowledge
taught to college students as “computer science”. When i started to
learn Scheme, the first thing that hit me is the cons business. To me,
who are accustomed to Mathematica, finding the cons business weird and
unwieldy. It puzzled me. I was thinking, how can a elegant language
have this? Certainly in Mathematica i can create, extract, manipulate
nested lists (tree structure) far more easily. At the time, since i
barely have basic knowledge of any computer science subjects, i was
greatly puzzled about the situation. (in fact made a newsgroup post in
comp.lang.scheme, tentatively trying to find the answer (and was
flamed by one Erik Naggum) (this is 1998 or 1999, i think))

Of course, today, with various levels of expertise in several
languages ( Mathematica, Emacs Lisp, unix shell, perl, php, python,
javascript, sql, java, Linden Scripting Lang (Second Life virtual
world), inert langs (HTML/CSS, LaTeX, POV-Ray ...)) and have read
countless tech papers and worked in complex software, data centers,
and wallowed in all kinds of industrial spaghetti code with non-
existent documentations, i know for a certainly, that Mathematica,
which perchance to be my first language, is in fact the world's _most_
advanced and high-level language, bar none.

(this short personal account is not supposed to be a pitch for
Mathematica. It just came out that way. There are, of course other
langs, depending on context and area of application, are equal quality
as Mathematica. For example, i would think Haskell, erlang, OCaml,
dylan etc would qualify, but i just have not actually learned these)

(gee, i just typed as quickly as possible and it came out to be over 1
thousand words of a brief personal bio of my computing experiences.
Good for me! The original intention was just to describe my first
impression of Scheme)
A Mathematica Programer's View of Lisp

The Mathematica language↗ is very similar to lisp. In fact, one could
say it's a lisp too. It shares the essential quality of lisp, namely:
uniformly nested syntax, programs are largely based on manipulating
lists, entities are symbolic, program is data and data is program.
From a Mathematica expert's point of view (me), the first thing that
seems odd of lisp is the low-level-ness. Perhaps in order of the low
level impression:

1. The cons business. (lists are made up of cons cells and it is
necessary for the programer to understand this to write any non-
trivial lisp program) (Elisp Manual: Cons-Cells)

2. No universal high level treatment of lists. (In Mathematica, there
are a system of functions to extract or manipulate (nested) lists
considered as trees. e.g. getting all elements at a level, or
arbitrary set of nodes of a tree. All these based on a tree index
concept. (i.e. first branch's second branch's third's branch will be
1,2,3. See Mathematica reference: Elements Of Lists↗. Such coherent
manipulation of generic list is sometimes called Array programming
languages↗ that began with APL↗.) In lisp, programers uses cons, car,
cdr, caadr, etc. That is bizarre and downright stupid.) (lisps do have
higher lever list manipulation functions to various degree and
consistency, such as “nth” and few others. But in general, due to the
fact that lists are made of cons cells, and consequently necessates
the concept of “proper list” and “improper list”, and also the
frequent use of car, cdr, etc, its not possible to use high-level list
functions without knowing the structure of the list.)

3. The syntax is a bit quirky. In particular, a Mathematica programer
sees that sometimes list is written as “(list a b c)”, but sometimes
there's this oddity “'(a b c)” (which is syntactically equivalent to
“(quote (a b c))”). And, when mapping a function, sometimes the
programer also needs to put the apostrophe in front. (A Mathematica
programer would think, if a function (e.g. “map”) that takes another
function as argument, why would the function require the programer to
put the apostrophe, whereas the function itself could be designed to
not evaluate that argument.)

4. A behind-the-scenes model of computation. Namely, lisp the language
deals with the concept of “lisp objects”, and there's a “print syntax”
that represent these objects. (and a “read syntax” that reads a code
into these objects) (see Elisp Manual: Printed-Representation.)

I think these are probably most odd things in lisp for a Mathematica
programer on the first exposure.

  Xah
∑ http://xahlee.org/

☄

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

[Xah Lee]

On Sep 22, 9:29 am, Nikolaj Schumacher <m...@nschum.de> wrote:
> XahLee<x...@xahlee.org> wrote:
> > 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.
>
> Correct.  That's how apps are supposed to behave on Macs according to
> the human interface guidelines.  It's more document than app based.
>
> However this mechanism can't simply be adapted for other operating
> systems.  On Windows and most X systems, closing the last window is
> expected to terminate the application and there's no way to access a
> window-less application (other than notification area hacks).  So this
> is not a viable solution.

Yes. Though that doesn't constitute a good argument against Untitled
for replacement of *scratch*.

In Windows, emacs can simply start with a Untitled document. Same with
X.

To be a bit complete... let me give a rough describtion about this in
various OS. On Mac (both Find thru the 1990s as well as OS X since
about 2001), as you know, each app has a menu bar at the top of the
screen. In the past, some apps will always have a window. Once you
close the last Window, it is equivalent to quitting the program. That
is, you won't be able to have a menu bar of the app without any
windows. In the history of mac apps, however most apps does not adopt
this approach. That is, you could close all windows and just leave the
app running with nothing but a menu bar. However, as far as my
experience goes, apps that require you to have a window present is
pretty much gone these days. Off hand i cant think of a app now in Mac
that requires you having at least one window present.

In Windows, as most of you know, each app runs inside a window, with
the app's menu in the Window. On Windows, however, there are also 2
different styles though. One is that each window represent a instance
of a running program. The other is that all instance of a app runs
inside one frame of a window. More specifically, each file, document,
etc is represented as a window inside the app's window. This window
within window style is pretty much disppeared as far as i know. (for
those tech geekers who likes to nickpick without regard to the whole,
they will retort that it is not true each instance runs a window...
but i'm just giving a brief, simplified description of the UI style)

In X, used by unixes and linuxes... before about 2000, they are pretty
much chaotic. Only with the inception of KDE and Gnome, where they
basically copied Windows wholesale, then you have a situation pretty
much like Windows where each file or document of a app appears in a
window with the app's menu bar at top of the window.

the above is just some rough description of styles of windows and apps
in Mac, Windows, X. Alan was saying that there must be something
running, possibly as a reason against getting rid of the *scratch*
buffer. I was saying, that it is not necessarily true, and it doesnt
constitute a reason against ridding *scratch* because you can just
have a Untitled doc as in most apps in Mac, Windows, as well as X.

  Xah
∑ http://xahlee.org/

☄

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

[Nikolaj Schumacher]

Xah Lee <xah@xahlee.org> wrote:

> Yes. Though that doesn't constitute a good argument against Untitled
> for replacement of *scratch*.

Of course not.  I never mentioned scratch.  I just said that this can't
be the solution.  (Why did you bring it up?)

> However, as far as my experience goes, apps that require you to have a
> window present is pretty much gone these days. Off hand i cant think
> of a app now in Mac that requires you having at least one window
> present.

From the top of my head, System Preferences, Software Update, iPhoto or
Photo Booth.  I think it's generally a reasonable behavior for all apps
that don't display (multiple) documents.  I think some 3rd party apps
are inappropriately overusing this behavior.

regards,
Nikolaj Schumacher

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

[Xah Lee]

On Sep 23, 12:05 pm, Nikolaj Schumacher <m...@nschum.de> wrote:
> XahLee<x...@xahlee.org> wrote:
> > Yes. Though that doesn't constitute a good argument against Untitled
> > for replacement of *scratch*.
>
> Of course not.  I never mentioned scratch.  I just said that this can't
> be the solution.  (Why did you bring it up?)

I brought it up because in this sub thread, it is one of Alan's point
against my criticism about scratch, that emacs must have something
open. I said no, then you added more comments (quote: “Correct. ...
However ...”), then i gave more detail about the whole situation. I
mentioned that this does not constitute a reason against my comments
of *scratch* because that's Alan's original point, and your addition
can be construed to support his point.

As you know, newsgroup is a pretty much a free-for-all ground for
pissing fight among tech geekers. I'm trying to defend my turf!

If everyone is reasonable here, i might be too. If pissing fight and
aggressive argumentation is what i see, i try to be compatible.

> > However, as far as my experience goes, apps that require you to have a
> > window present is pretty much gone these days. Off hand i cant think
> > of a app now in Mac that requires you having at least one window
> > present.
>
> From the top of my head, System Preferences, Software Update, iPhoto or
> Photo Booth. I think it's generally a reasonable behavior for all apps
> that don't display (multiple) documents.  I think some 3rd party apps
> are inappropriately overusing this behavior.

good points.

  Xah
∑ http://xahlee.org/

☄

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

[Ross A. Laird]

I have been following this thread with amusement and (a little bit of)
chagrin. Online modes of communication make it easy to say things that
one would not say in a face-to-face conversation. But that's just an
observation. My main point is that I am not a programmer (I am a
professional writer) and I would like to vote for continuation of the
scratch buffer as a basic feature. I used the scratch buffer the other
day to show some students in a creative writing class the schedule of
their presentations, which I had copied from my org-mode agenda (which
has all kinds of other stuff that is not relevant to the class). I don't
use the scratch buffer all that much, but I like to know that it's
there. I copy snippets of text to it, and I sometimes use it to create
odd little literary vignettes that I may not wish to save. It's useful.

Just my two bits.

Cheers.

Ross


-- 
Ross A. Laird, PhD
www.rosslaird.info

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

[Giorgos Keramidas]

On Tue, 23 Sep 2008 21:32:24 -0700, ross@rosslaird.info (Ross A. Laird) wrote:
> I don't use the scratch buffer all that much, but I like to know that
> it's there. I copy snippets of text to it, and I sometimes use it to
> create odd little literary vignettes that I may not wish to save. It's
> useful.

+1

I very often use the *scratch* buffer as, uhm, a "scratch pad" when I
chat online with friends using ERC.  It is very useful as a temporary
scratch pad when I am preparing something to paste.  I get the full
editing capabilities of Emacs: I can untabify, indent, wrap and do
anything else that is `normal' for the target channel or query buffer;
it is easy to pull text off other windows or the kill ring; and when I'm
done preparing the text I can copy it with M-w and paste it to the final
target buffer in its well-formatted finished form.

Then the *scratch* buffer can go away.  I don't need it anymore and it
gets buried in the buffer list, until I need it again.

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

[Xah]

On Sep 23, 9:32 pm, r...@rosslaird.info (Ross A. Laird) wrote:
> I have been following this thread with amusement and (a little bit of)
> chagrin. Online modes of communication make it easy to say things that
> one would not say in a face-to-face conversation. But that's just an
> observation. My main point is that I am not a programmer (I am a
> professional writer) and I would like to vote for continuation of the
> scratch buffer as a basic feature. I used the scratch buffer the other
> day to show some students in a creative writing class the schedule of
> their presentations, which I had copied from my org-mode agenda (which
> has all kinds of other stuff that is not relevant to the class). I don't
> use the scratch buffer all that much, but I like to know that it's
> there. I copy snippets of text to it, and I sometimes use it to create
> odd little literary vignettes that I may not wish to save. It's useful.
>
> Just my two bits.

Here's a tip you might love.

(global-set-key (kbd "<f6>") 'new-empty-buffer)

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

Put the above in your “.emacs”. Then, you can get a new scratch by
simply pressing a key. And, when you need to, press again you get a
second scratch.

  Xah
∑ http://xahlee.org/

☄

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

[Alan Mackenzie]

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

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Xah Lee]

On Sep 20, 1:50 am, Alan Mackenzie <a...@muc.de> wrote:
> 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))

Thanks! I've taken your suggestion here.

  Xah
∑ http://xahlee.org/

☄

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

[Kevin Rodgers]

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

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

[Xah]

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/

☄

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

[Christian Herenz]

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

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

[Joost Kremers]

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                                      joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

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

[William Case]

Hi David;

On Mon, 2008-09-15 at 22:28 -0700, 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.

This may be too late to be of much help, but ...

a command line in a terminal or launcher of "emacs --no-splash /" gets
me what you appear to want.  Change the "/" to the directory path you
would like e.g. "~/" or "/home/user/to/where/ever".  It works for me.

I haven't tried it but I would think "/home/user/new" could be used to
open a new buffer each time as long as you remember to 'save as'
myfilename.

I have a separate emacs launcher I use with zenity (Gnome) and sudo for
quick root access when I want to view/make quick configuration file etc.
changes.

-- 
Regards Bill
Fedora 9, Gnome 2.22.3
Evo.2.22.3.1, Emacs 22.2.1

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

[Tim X]

William Case <billlinux@rogers.com> writes:

> Hi David;
>
> On Mon, 2008-09-15 at 22:28 -0700, 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.
>
> This may be too late to be of much help, but ...
>
> a command line in a terminal or launcher of "emacs --no-splash /" gets
> me what you appear to want.  Change the "/" to the directory path you
> would like e.g. "~/" or "/home/user/to/where/ever".  It works for me.
>
> I haven't tried it but I would think "/home/user/new" could be used to
> open a new buffer each time as long as you remember to 'save as'
> myfilename.
>

I was trying very hard to avoid getting dragged into yet another thread
which has been pointlessley hijacked by Xah so that he can grind his own
personal axe. However, it seems nobody has decided to point out that the
sort of things the OP and others have asked for are in fact now part of
CVS emacs and have been for some time now. From the Emacs 23 News file

,----
| ** The option `inhibit-startup-screen' (with aliases to old names
| `inhibit-splash-screen' and `inhibit-startup-message') doesn't inhibit
| display of the initial message in the *scratch* buffer.  If you don't
| want to display the initial message in the *scratch* buffer at startup,
| you can set the option `initial-scratch-message' to nil.
| 
| ** New user option `initial-buffer-choice' specifies what to display
| after starting Emacs: startup screen, *scratch* buffer, visiting a
| file or directory.
`----

So if the OP is not satisfied with any of the (relevant) suggestions
already made, they can either wait for emacs 23 (could be a while before
it is released) or start running the CVS version, which I've found to be
very stable and usable, but not garanteed to be without bugs. How
difficult it is to run from CVS depends a bit on the platform. I know
there are 'snapshots' for Debian, Ubuntu and I believe windows. I
personally prefer building directly from CVS myself, which is very easy
under Debian as long as you make some very minor modifications (so that
you can take advantage of debian elisp packages) and are prepared to
also have the emacs-snapshot installed (i have some fairly specialised
requirements that for some reason don't work with the packaged snapshot,
but work fine with my CVS build.) You don't ahve to keep the snapshot
installed, but if you do, it means you dn't have problems installing
other elisp packages and you have sources that are built with emacs
23. There are some diffeences in the coding systems of compiled files
under emacs 23 and earlier verisons. While emacs 23 will still work with
them, it has to do some conversions when loading the elc files, which
can slow things down. Having the emacs-snapshot installed is a simple
way to ensure you have elc files built with 23 that are also managed by
apt, so you get the best of both worlds.

HTH

Tim


-- 
tcross (at) rapttech dot com dot au

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

[Xah]

Tim scumbag,

Tim X wrote:
> I was trying very hard to avoid getting dragged into yet another thread
> which has been pointlessley hijacked by Xah so that he can grind his own
> personal axe.

If you want to help the original poster, you can help without having
to insult people. For example, you don't need the first paragraph
above.

If your goal is to incite me to do a piss fight with u, let's begin.

  Xah
∑ http://xahlee.org/

☄

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

[Jonathan Groll]

On Wed, Sep 24, 2008 at 11:35:27PM -0700, Xah wrote:
>Tim scumbag,
>
>Tim X wrote:
>> I was trying very hard to avoid getting dragged into yet another thread
>> which has been pointlessley hijacked by Xah so that he can grind his own
>> personal axe.
>
>If you want to help the original poster, you can help without having
>to insult people. For example, you don't need the first paragraph
>above.
>
>If your goal is to incite me to do a piss fight with u, let's begin.

Xah - do we ALL have to read another one of these rude and
intimidating mails? Did Tim really call you a scumbag? Looking back at
the original thread, it does seem that the OP's thread had indeed been
forgotten, so he did have a point, don't you think?

The above mail on the other hand had nothing to do with Emacs, and I
am seriously thinking of quitting this mailing list as a result of
such unpleasant hate-filled emails. I don't want to read this sort of
email and get worked up as a consequence, it is just not worth
it. Yes, you are a good contributor to the list and are generally very
helpful to most posters, but this sort of correspondence we can do
without. There do need to be moderators on this list.

Jonathan.

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

[Andreas Politz]

Jonathan Groll wrote:
> On Wed, Sep 24, 2008 at 11:35:27PM -0700, Xah wrote:
>> Tim scumbag,
>>
>> Tim X wrote:
>>> I was trying very hard to avoid getting dragged into yet another thread
>>> which has been pointlessley hijacked by Xah so that he can grind his own
>>> personal axe.
>>
>> If you want to help the original poster, you can help without having
>> to insult people. For example, you don't need the first paragraph
>> above.
>>
>> If your goal is to incite me to do a piss fight with u, let's begin.
> 
> Xah - do we ALL have to read another one of these rude and
> intimidating mails? Did Tim really call you a scumbag? Looking back at
> the original thread, it does seem that the OP's thread had indeed been
> forgotten, so he did have a point, don't you think?
> 
> The above mail on the other hand had nothing to do with Emacs, and I
> am seriously thinking of quitting this mailing list as a result of
> such unpleasant hate-filled emails. I don't want to read this sort of
> email and get worked up as a consequence, it is just not worth
> it. Yes, you are a good contributor to the list and are generally very
> helpful to most posters, but this sort of correspondence we can do
> without. There do need to be moderators on this list.
> 
> Jonathan.
> 
> 

You have to admit that some people do like to argue with Xah.

OP:How do I do X ?
XAH: Well, actually if emacs weren't so backwards, you could do Y.
SOMEONE: Wait a minute, actually X isn't such a bad thing.


Next time I check the thread has 200 posts, half of them from xah.

-ap

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

[Juanma Barranquero]

On Thu, Sep 25, 2008 at 11:09, Andreas Politz <politza@fh-trier.de> wrote:

> OP:How do I do X ?
> XAH: Well, actually if emacs weren't so backwards, you could do Y.
> SOMEONE: Wait a minute, actually X isn't such a bad thing.
XAH: You stupid fucking moron!
SOMEONE: ???

etc.

             Juanma

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

[Xah]

On Sep 25, 2:09 am, Andreas Politz <poli...@fh-trier.de> wrote:
> You have to admit that some people do like to argue withXah.
>
> OP:How do I do X ?XAH: Well, actually if emacs weren't so backwards, you could do Y.
> SOMEONE: Wait a minute, actually X isn't such a bad thing.
>
> Next time I check the thread has 200 posts, half of them fromxah.

I don't think it's like that. It's more like this:

A emacs user: How do I do X ?

Tech geeker: [answer] but you should learn the emacs way, such as
*scratch*, and don't use HTML for email, and you shouldn't use GUI,
and you shouldn't use the mouse.

XAH: I disagree. Because xyz. [1 thousand words of detailed
explanations, reasons, patches]

Tech geeker 2: You shit.

Tech geeker 3: Why do you hijack the thread for your personal issue.

Tech geeker 4: You are wrong, period.

Tech geeker 5: No! 'nuff said.

Tech geeker 6: You are a moron.

Tech geeker 7: Do you know the basics of emacs?

Tech geeker 8: Emacs is not Microsoft!

Tech geeker 9: Why are you using curly quote in newsgroup post? Please
use ascii.

Tech geeker 10: Are you still trolling eh?

...

You can check back how this thread started. e.g.
http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/bf2fae706a7424f0

The first message that mentions *scratch*, is this:

http://groups.google.com/group/gnu.emacs.help/msg/2c92e27286777f41

I quote:

On 2008 Sep 16, 1:44 am, Charles Sebold 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.

Note the phrase GOOD OLD.

And my first response:
http://groups.google.com/group/gnu.emacs.help/msg/9b1ce96b9e39e47d

I quote in full:
---------------------------------------------------

On Sep 16, 1:44 am, Charles Sebold <cseb...@gmail.com> wrote:

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

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/

☄

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

  Xah
∑ http://xahlee.org/

☄

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

[Xah]

On Sep 25, 3:01 am, "Juanma Barranquero" <lek...@gmail.com> wrote:
> On Thu, Sep 25, 2008 at 11:09, Andreas Politz <poli...@fh-trier.de> wrote:
> > OP:How do I do X ?
> > XAH: Well, actually if emacs weren't so backwards, you could do Y.
> > SOMEONE: Wait a minute, actually X isn't such a bad thing.
>
> XAH: You stupid fucking moron!
> SOMEONE: ???

You seems to imply that i started to insult people first. No, i almost
never did that in my over 17 years of using online forums. In fact,
for several years maybe 2002 to 2007, i don't respond to insults. (not
responding to drivels or personal attacks has been taken as a reason
that accuses me of “hit and run”) If i appear rude, or swearing,
that's because they insulted me, defamed me, infringed my right, or
harassed me first.

I have been to a lot arguments in newsgroups, and have written a lot
of these phenomenon. See:

http://xahlee.org/Netiquette_dir/troll.html

In newsgroups, since i started using it maybe in 1993, i've never
posted anonymous, and never have requested my message be not archived.
For everything i wrote about the quarrels in newsgroups, can be
verified thru google's archive (though i've heard their archive is not
perfectly complete).

As i've indicated in another post in this thead... you can for
example, now go do research on how the quarrel or insult started in
this thread. (the url is here: http://groups.google.com/group/gnu.emacs.help/browse_frm/thread/bf2fae706a7424f0
) You can check, for example, how the discussion about *scratch*
buffer got started. Who started to be rude. What are my responses to
each. If you are serious about this, then you might to spend a few
hours to check the thread, all its rplies, who said what, how the
conversation turned, write down notes and names as you read.

Similarly, for any newsgroup flame involving me in gnu.emacs.help that
has happend several times in the past few monhts, you can spend a few
hours each and do a detailed research. I'm not the most perfect being,
but i claim here that my posts are in general reasonable, without any
insult, detailed. It is other people, who started insulting or
slighting me that got the thread bad. They did that because they
cannot tolerate or understand a different point of view. In my
opinion, these people, collectively i called tech geekers, are
ignorant of social knowledge in a very damaging degree... The other
part of reason is than newsgroups consists of males, and males do
pissing fights among themselves all their lives, in every social
structure or organization, from newsgroups to intra-corp to political
organizations. It's their nature. Wild flames wars in newsgroups is
not just me. It is a common phenomenon, and happens just about every
day, in every of the thousands of newsgroups.

  Xah
∑ http://xahlee.org/

☄

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

[Lennart Borgman]

On 9/25/08, Xah <xahlee@gmail.com> wrote:
> On Sep 25, 3:01 am, "Juanma Barranquero" <lek...@gmail.com> wrote:
> > On Thu, Sep 25, 2008 at 11:09, Andreas Politz <poli...@fh-trier.de> wrote:
> > > OP:How do I do X ?
> > > XAH: Well, actually if emacs weren't so backwards, you could do Y.
> > > SOMEONE: Wait a minute, actually X isn't such a bad thing.
> >
> > XAH: You stupid fucking moron!
> > SOMEONE: ???
>
> You seems to imply that i started to insult people first.

You have no rights whatsoever to insult people even if they have insulted you!

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

[Xah]

On Sep 25, 5:53 am, "Lennart Borgman" <lennart.borg...@gmail.com>
wrote:
> On 9/25/08, Xah <xah...@gmail.com> wrote:
>
> > On Sep 25, 3:01 am, "Juanma Barranquero" <lek...@gmail.com> wrote:
> > > On Thu, Sep 25, 2008 at 11:09, Andreas Politz <poli...@fh-trier.de> wrote:
> > > > OP:How do I do X ?
> > > > XAH: Well, actually if emacs weren't so backwards, you could do Y.
> > > > SOMEONE: Wait a minute, actually X isn't such a bad thing.
>
> > > XAH: You stupid fucking moron!
> > > SOMEONE: ???
>
> > You seems to imply that i started to insult people first.
>
> You have no rights whatsoever to insult people even if they have insulted you!

That's silly. In highschool, you do it all the time. In fact, it's
rather natural. That's how you learn to deal with conflicts and
troubles in real world when teens grow up. With politicians, you do it
all the time.

In some theoretical sense, sure, you don't have the “right” to return
insults, and you can be some saint. In real world, it doesn't work
like that. Nobody's gonna fight for you for some justice. Even the
most perfect justice system that exists in practice in this world, it
doesn't activetly go do justice for you or each individual. It only
provide support when you defend yourself.

  Xah
∑ http://xahlee.org/

☄

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

[Lennart Borgman]

On 9/25/08, Xah <xahlee@gmail.com> wrote:
> On Sep 25, 5:53 am, "Lennart Borgman" <lennart.borg...@gmail.com>
> > You have no rights whatsoever to insult people even if they have insulted you!
>
> In some theoretical sense, sure, you don't have the "right" to return
> insults, and you can be some saint. In real world, it doesn't work
> like that.

It is perfectly possible to fight without insulting other people. In
fact that is what many great personalities have done.

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

[Xah]

On Sep 25, 6:48 am, "Lennart Borgman" <lennart.borg...@gmail.com>
wrote:
> On 9/25/08, Xah <xah...@gmail.com> wrote:
>
> > On Sep 25, 5:53 am, "Lennart Borgman" <lennart.borg...@gmail.com>
> > > You have no rights whatsoever to insult people even if they have insulted you!
>
> > In some theoretical sense, sure, you don't have the "right" to return
> > insults, and you can be some saint. In real world, it doesn't work
> > like that.
>
> It is perfectly possible to fight without insulting other people. In
> fact that is what many great personalities have done.

Lennart, are you trying to accuse me for something? or are you trying
to give me a lecture about great personalities?? or are you trying to
have some humourous exchange?

sure, we can start a friendly digression about saints, personalities,
famous insults, and so on. I'm not sure the ambiance is right.

  Xah
∑ http://xahlee.org/

☄

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

[Lennart Borgman (gmail)]

Xah wrote:
> On Sep 25, 6:48 am, "Lennart Borgman" <lennart.borg...@gmail.com>
> wrote:
>> On 9/25/08, Xah <xah...@gmail.com> wrote:
>>
>>> On Sep 25, 5:53 am, "Lennart Borgman" <lennart.borg...@gmail.com>
>>>> You have no rights whatsoever to insult people even if they have insulted you!
>>> In some theoretical sense, sure, you don't have the "right" to return
>>> insults, and you can be some saint. In real world, it doesn't work
>>> like that.
>> It is perfectly possible to fight without insulting other people. In
>> fact that is what many great personalities have done.
> 
> Lennart, are you trying to accuse me for something?

I know you know I am saying that you do (in a way) insult people. And
that I find this unnecessary.

It is my impression that you feel you (somehow) have the right to insult
when you feel insulted. I can't and I don't want to deny you that
feeling. I think most of us get that feeling.

However that feeling is no real reason to insult anyone. In my opinion
it is rather a reason to think about what is important in your
(everyones) life.

In that way the feeling can help build cooperation (instead of
destroying it).

But all this in a way depends on what audience you have. In a fascist
(or narcissistic) environment you may gain many points by insulting. I
hope that is not the case here.

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

[Xah]

On Sep 25, 8:39 am, "Lennart Borgman (gmail)"
<lennart.borg...@gmail.com> wrote:
> Xah wrote:
> > On Sep 25, 6:48 am, "Lennart Borgman" <lennart.borg...@gmail.com>
> > wrote:
> >> On 9/25/08, Xah <xah...@gmail.com> wrote:
>
> >>> On Sep 25, 5:53 am, "Lennart Borgman" <lennart.borg...@gmail.com>
> >>>> You have no rights whatsoever to insult people even if they have insulted you!
> >>> In some theoretical sense, sure, you don't have the "right" to return
> >>> insults, and you can be some saint. In real world, it doesn't work
> >>> like that.
> >> It is perfectly possible to fight without insulting other people. In
> >> fact that is what many great personalities have done.
>
> > Lennart, are you trying to accuse me for something?
>
> I know you know I am saying that you do (in a way) insult people. And
> that I find this unnecessary.
>
> It is my impression that you feel you (somehow) have the right to insult
> when you feel insulted. I can't and I don't want to deny you that
> feeling. I think most of us get that feeling.
>
> However that feeling is no real reason to insult anyone. In my opinion
> it is rather a reason to think about what is important in your
> (everyones) life.
>
> In that way the feeling can help build cooperation (instead of
> destroying it).
>
> But all this in a way depends on what audience you have. In a fascist
> (or narcissistic) environment you may gain many points by insulting. I
> hope that is not the case here.

LOL.

Lennart, i recommend this article to you:

What Desires Are Politically Important?
http://xahlee.org/Periodic_dosage_dir/_p2/russell-lecture.html

  Xah
∑ http://xahlee.org/

☄

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

[Xah]

On Sep 25, 1:13 am, Jonathan Groll <li...@groll.co.za> wrote:
> On Wed, Sep 24, 2008 at 11:35:27PM -0700,Xahwrote:
> >Tim scumbag,
>
> >Tim X wrote:
> >> I was trying very hard to avoid getting dragged into yet another thread
> >> which has been pointlessley hijacked by Xahs o that he can grind his own
> >> personal axe.
>
> >If you want to help the original poster, you can help without having
> >to insult people. For example, you don't need the first paragraph
> >above.
>
> >If your goal is to incite me to do a piss fight with u, let's begin.
>
> Xah- do we ALL have to read another one of these rude and
> intimidating mails? Did Tim really call you a scumbag?

rude and intimadating? Do you mean he started it?

So, if someone rapes your wife and daughter, but he didn't swear, and
you swore, you are the scumbag then?

> Looking back at
> the original thread, it does seem that the OP's thread had indeed been
> forgotten, so he did have a point, don't you think?

Did you pay attention here? Let me repeat what i wrote in previous
message:

Xah wrote:
«If you want to help the original poster, you can help without having
to insult people. For example, you don't need the first paragraph
above.»

Tim X's first sentence goes thus:

«I was trying very hard to avoid getting dragged into yet another
thread which has been pointlessley hijacked by Xah so that he can
grind his own personal axe.»

Would you be interested in defending for him on this? If so, do, then
i'll answer.

> The above mail on the other hand had nothing to do with Emacs, and I
> am seriously thinking of quitting this mailing list as a result of
> such unpleasant hate-filled emails.

Your post, don't have nothing to do with emacs too. Did you not
realize it??

> I don't want to read this sort of
> email and get worked up as a consequence, it is just not worth
> it. Yes, you are a good contributor to the list and are generally very
> helpful to most posters, but this sort of correspondence we can do
> without. There do need to be moderators on this list.

Perhaps, you should read one of my article on netiquette.

Why Can't You Be Normal?
http://xahlee.org/Netiquette_dir/why_cant_you_be_normal.html

For your convenient, i pasted the plain text version below.
---------------------------

Why Can't You Be Normal?

Xah Lee, 2008-07

Over the past ~5 years there are some negative remarks on me or my
posts. I have almost never responded to any of them. Here i want to
clarify a few things.

• I seldomly write off-topic posts. For example, any argument about
netiquette, i consider off-topic, including defense such as what i'm
doing now. But in recent years i gradually relaxed my stringent self-
imposed rules in my posting habit. (See Aloofness vs Approachable.)

• Many say i'm posting off topic posts. In recent years they start to
say i'm posting borderline relevant posts. That's not correct. In
fact, there are huge number of blatantly off-topic posts by regulars
that spawn off from threads, regularly. The topics vary anywhere from
discussing politics, law, licenses, free speech, relevance of math,
english usage, yapping on happenings of celebrity programers, and
including rampant flamewars and accusations among themselves. (see Old
School Netiquette.)

• Some people says that i don't participate in discussion, and this is
part of the reason they think i'm a so-called “troll”. Actually i do,
and read every reply to my post, as well have replied to technical
questions other posted. Most replies to my posts are attacks or
trivial (of few sentences) i don't consider worthy to reply.

A few, maybe 10% replies to my unconventional posts, i consider having
some value. But if i don't have sufficiently remarkable opinion on
what they remarked, i don't reply. Also, if all i wanted to say is
“thanks”, i tend to avoid posting such trivial posts too. (i used to
reply by personal email in such cases, I still do sometimes now, but
today that can be considered intrusive.)

(see Philosophies of Netiquette)

In newsgroups which i feel i'm more part of the community, i do reply
more often. (e.g. in the dot com years (~1999) i'm much more active in
comp.lang.perl.misc including asking technical questions; during
2005-2006 while i was learning python, did somewhat frequent posts to
comp.lang.python; in this year in comp.lang.lisp, i frequently replied
and argued more freely. But in this year, am also very active in
gnu.emacs.help, most of my posts there just answered tech questions.)

• Most newsgroup tech geekers consider cross-posting wrong. I consider
such taboo in this convention being a major contribution to the
redundant creation of new languages, flaws, and foster the hostile
faction nature of programing language groups we see. (see Cross-
posting & Language Factions.)

• There's some rumor that says i post prodigiously. Actually, when i'm
active, i post only about 1 or 2 posts per week or month, in the past
10 years, with rare exceptions. (See Aloofness vs Approachable article
for reason why. (Note that, about last year (2007) i checked, the stat
given by poster's profile at groups.google.com is erroneous. For
example, it shows the number of posts per month. I recall, seeing it
says tens of messages for particular months where i know i've only
posted maybe no more than 10 each month. This can be verified by using
groups.google.com to search the group and count the number of actual
messages and compare to the number reported in the posting profile.))

• Many say i repeatedly post old essays i wrote that are published on
my website. The total number of times i've done that is perhaps 4 or
absoletly less than than 10, since the 12 years of using newsgroup
started in 1996. The first of such “repeat” must be sometimes after
2004. The interval of a “repeat” happens is at least half a year, more
likely 1 or 2 years. Also, the repeat does not happen more than once.
(to be absolutely correct, possibly there is 1 essay that are posted
at a max of 3 times) I “repeat” a essay i've written because i think
the issue is important, the situation has not changed, and i consider
it worth to be said again. When appropriate, i incorporate information
from the discussion into my essay, with proper credits. (this esp has
happened in my Python tutorial, emacs lisp tutorial, Java Tutorial,
various classical literature on my site)

Actually, most accusations about me falls apart if one just take 10
min to check the facts.

• When i used my google email account to post, as opposed to my older
google account with xah@xahlee.org email address, often people accuse
me of “changing identity to avoid killfile”. This is just one of their
ways these people drivel. I don't really give a fuck i'm kill filed or
not kill filed. Many of these people publically proclaimed that i've
been kill filed, yet respond to my messages again. (See Killfile
Considered Harmful.)

People change emails all the time. In the past 8 years of using
newsgroups, i've only used xah@xahlee.org and xahlee@gmail.com . And
before 2000, i had few other emails before i registered the domain
xahlee.org. I rather stick with xah@xahlee.org, but the re-login to
different google accounts with several of their services is becoming a
pain. See, for example, this post from me last month about how to
merge google accounts: groups.google.com Google Accounts merge post↗.

Also, whenever i had a new webhosting provider, people dig it up and
accuse me of changing IP to troll. (this happens more frequently in
the past, say before 2003, i think that the know-how of domain info
lookup is now considered lame even among these stupid tech geekers)

My site xahlee.org has changed web hosting about every 2 or 3 years
for variety of reasons. For a few years it was hosted free on the math
educational site that used to be mathforum.org by Swathmore edu. (For
some detail of my website hosting and history, see: Web Hosting
Compared: 2006-01. A little trivia: before i had xahlee.org in 2000,
my site was hosted at “best.com/xah/” starting in 1996. Some very very
old sites still link to that. )

The only time that my change of web hoster has anything to do with my
posting, is in 2006 someone harrassed me to have my web hosting kick
me off due to my controversial postings in “comp.lang.*” groups. I
have written a detailed account about it on my website. See
DreamHost.com and A Incidence of Harassment.

(for the record, any ban, or harrasment on me, i keep a record as
truthful as possile. These bans, kicks, or fights happen in just about
every online forum, inworld game groups, irc chat groups, ...etc where
the members are almost exclusive males. Typically, they are not unlike
highschool boys brawling things out. If the issue effected me or
pissed me in some serious way, i publish it on my website. The keeping
record is very tedious. For example, in newsgroups you might want to
save all the messages in a thread this happened. In online forums,
blogs, social networking sites, where posts can be deleted or modified
easily, it's more tedious to keep a history of the site (e.g.
screenshots of the page at multiple times), and to keep a manually
written log of what happened when. Similarly, in irc, you have to save
the chat, manage the chat logs, adding comment on what happened where
with what chat log, finding out people's real identities if proper,
etc. (as a example, i've been ban'd in freenode.net's “#emacs” irc
channel since 2006. See Emacs Irc Channel Ban On Xah Lee. I have a
bunch of irc chat logs when i'm banned. I always save the chat log
when someone ban me that i consider unjust. But it's quite time
consuming to organize them and write about them.))

(as another example of ban, in about 2 months ago i was ban'd in
Wikipedia. I was editing 3 article related to Tibet, of which i
consider my edit very proper. But, in my opinion, it's too much againt
Westerner's popular beliefs. I wrote detailed argument about my edit
in my Wikipedia's personal talk page. The Wikipedia fuckheads not only
ban'd me, but subsequently ban'd me in editing my pesonal Wikipedia
talk page too, and blatantly deleted the detailed reason that i
defended my edit. The incident is here, bottom: User talk:P0lyglut↗.
the writing where i defended my edit, is here: Wikipedia User
talk:P0lyglut ...↗ 2008-07.

Wikipedia these days is a huge organization (ranked top 10 of all
sites since about 2005), and part of the good thing in large orgs is
that they have developed, with public scrutiny, some regulations that
prevents fuckheads doing power struggle too much. e.g. they have
locks, bans, votes, must be done by agreement of admins (as opposed to
a single person), and the ban is in general limited in duration, and
they have a record of edit history, and in general has ways to further
one's case if he believes being ban'd wrongly. However, it's still
subject to a lot tech geekers or other cartel of vested interest in
keeping some article to the way they liked. (basically, if you have
nothing to do and hog Wikipedia all day for a couple of years
(typically students), and if you are in general not offensive, then
you'll become a admin, and establish a bunch of admin friends of the
same ilk. This class of people, basically control Wikipedia's
disputes. Also, by the way how Wikipedia developed, they don't
appreciate identity nor credentials. So, many of these “admins” are
anonymous.)

I do consider Wikipedia one of the most important site and in fact
part of my life, but these days i avoid “contributing”.

(e.g. i have now over 4000 links to Wikipedia articles from my site. I
estimate, that for each link i've made, there are maybe 10 more
article i've read. See for example:

    * Links To Wikipedia from XahLee.org
    * Generate a Web Links Report with Emacs Lisp
    * Encyclopedia, My Experiences
    * Lispers and Wikipedia

) )

* * *

I've been actively using online forums since 1991 in CompuServe and
AppleLink days. I've seen my share of flames, netiquette arguments,
etc. (the medium include: newsgroup, mailing list, web forum, irc,
communities inside massive multi-player online games (a niche but
typically with literally millions of users world wide)) I've been
banned now and then in places. (in one case, legally definable
harrassment, which happened and perhapss well-known at the time in
comp.lang.* groups few years ago) From what i see, the banning, heated
accusations and quarrels, are mostly exhibition of male nature and
political struggle, not unlike political struggles that happens in
society at large, such as in academia, corporations, goverment orgs,
between corporations, between nations.

Some say “why can't you be normal”?

It is true i tend to discuss controversial topics and with non-
conformal attitude. I have my reasons and you could say it's just a
personality. However, “being not normal” is not a reason to accuse.
There are philosophers, unorthodox, dissenters, free thinkers, flag
bunners, protesters, traitor/founder, prostitutes, homosexuals ...
many are persecuted, considered a crime, in the past, and some are now
considered national or international heros.

Btw, this post is not some kinda formal defense to some formal
accusations. Usenet has always been a mecca of rowdy contention and
cluesless argument among tech geekers, and the medium is perhaps far
more wortheless with relatively little readership and impact on
society than newsgroup dwellers like to think. Newsgroups users in
fact like this free-for-all aspect. I don't feel necessary to respond
to morons. This post is just one of my post i feel like writing. You
guys to whatever it is that you do.

PS as i have detailed, i have my own moral ethics in posting. Most
posts and opinions are just too stupid, igonrant, for me to consider
replying. If you really believed that some of my opinion or posts are
wrong, contain bad advice, or incorrect fact, then do post, as i do
read every reply it shows up in groups.google.com. And, whatever is
your opinion, i would recommend you spend 30 minutes to write your
reply. (i spend 1 to even 6 hours in most of my opinion-oriented
newsgroup posts as explained in detail in one of the above cited
article) Also, if you see my post of a unconventional opinion, and i
was forceful in my writing style, then it is likely i have serious
knowledge and or did serious research and or i consider it a widely
misunderstood issue. I suggest you take 30 minutes, to think, do
research, about it before you reply. Also, i prefer to reply to those
who post with real identities. Again, i don't consider this is some
serious issue, or that my opinions and beliefs and behaviors are
always good. It's just another newsgroup day. Do whatever it is that
you do.

  Xah
∑ http://xahlee.org/

☄

language (was: How to get rid of *GNU Emacs* buffer on start-up?)

[Ted Zlatanov]

On Thu, 25 Sep 2008 04:00:56 -0700 (PDT) Xah <xahlee@gmail.com> wrote: 

X> rude and intimadating? Do you mean he started it?

X> So, if someone rapes your wife and daughter, but he didn't swear, and
X> you swore, you are the scumbag then?

Do you really have to resort to swearing (in other posts) and allusions
to rape to make your point?  Repeatedly you've used words and tone
inappropriate for a technical discussion, not just in this thread,
insulting people personally and stereotyping them.

People of all ages and backgrounds read this; you are simply
broadcasting your inability to express yourself in a civilized way to
tens of thousands of readers every time you resort to base language and
topics.  I expect this from children who are only too happy to use
"dirty" words to get attention, but among adults... it's not welcome.

I am not interested in arguing about who started what, my issue is with
you specifically.  Please control your language.

Ted

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

[Xah]

On Sep 25, 6:34 am, Ted Zlatanov <t...@lifelogs.com> wrote:
> On Thu, 25 Sep 2008 04:00:56 -0700 (PDT) Xah <xah...@gmail.com> wrote:
>
> X> rude and intimadating? Do you mean he started it?
>
> X> So, if someone rapes your wife and daughter, but he didn't swear, and
> X> you swore, you are the scumbag then?
>
> Do you really have to resort to swearing (in other posts) and allusions
> to rape to make your point?

Well, do you, really have to keep harrass me?

If your intention is for this thread to stop being a wild flame war,
start, with thyself.

> Repeatedly you've used words and tone
> inappropriate for a technical discussion, not just in this thread,
> insulting people personally and stereotyping them.

Repeatedly, you've tried to harrass me, slander me.

Why don't you stop it?

> People of all ages and backgrounds read this; you are simply
> broadcasting your inability to express yourself in a civilized way to
> tens of thousands of readers every time you resort to base language and
> topics.  I expect this from children who are only too happy to use
> "dirty" words to get attention, but among adults... it's not welcome.

Has it occured to you, that you are devious asd scheming? I don't
think that sets a good example for the kids out there.

> I am not interested in arguing about who started what, my issue is with
> you specifically.  Please control your language.

I'm not interested in you donning on sainty rope and slander me. Fuck
you motherfucker.

  Xah
∑ http://xahlee.org/

☄

Re: language

[Ted Zlatanov]

On Thu, 25 Sep 2008 06:49:06 -0700 (PDT) Xah <xahlee@gmail.com> wrote: 

X> I'm not interested in you donning on sainty rope and slander me. Fuck
X> you motherfucker.

Heh, "sainty rope."  At least you can spell the curse words.  What,
specifically, have I said that's slander?  Make sure to look up the word
and write up a web page, then quote it in full for completeness.

My score file says -500 for you.  Come on, you can make it to -1000.

Ted

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

[Sean Sieger]

Xah, you are continuing to see what I see:

``Most replies to my posts are attacks or trivial''

Not only does no one else on this list utter these words, NO ONE else is
ever admonished as you are.

``(of few sentences)''

Your inability to express yourself succinctly is an inability most on
this list don't share with you.

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

[Xah]

On Sep 25, 10:58 am, Sean Sieger <sean.sie...@gmail.com> wrote:
> Xah, you are continuing to see what I see:
>
> ``Most replies to my posts are attacks or trivial''
>
> Not only does no one else on this list utter these words, NO ONE else is
> ever admonished as you are.

Let's say you do not support Iraq War, and let's say you lead a
movement to impeach George Bush.
(see http://en.wikipedia.org/wiki/Movement_to_impeach_George_W._Bush
http://www.impeachbush.org/site/PageServer
)

Now, there are probably few thousands people in the US who wants you
to be locked up or dead.

Do u now understand why numbers “against” you is not a criterion in
justice?

Suppose you burned a American Flag, and when in court, the judge says,
you are guilty because “NO ONE else is ever admonished as you are.”.
Can you see your stupidity?

> ``(of few sentences)''
>
> Your inability to express yourself succinctly is an inability most on
> this list don't share with you.

dear moron, are we supposed now to exchange opinions about each
other's abilities in expression in gnu.emacs.help?

  Xah
∑ http://xahlee.org/

☄