How to get rid of *GNU Emacs* buffer on start-up?
Davin Pearson
is a little bit annoying having to do this. If I can't kill this
buffer, then I would at least prefer the default-directory of that
buffer to be "~/" so that I can easily load a file that I want to
edit. The following code is what I have written to accomplish that
task but sadly it doesn't appear to work.
(defun d-emacs-startup-hook
()
(if (get-buffer "*GNU
Emacs*")
(save-
excursion
(set-buffer "*GNU
Emacs*")
(setq default-directory
"~/")))
(defun d-emacs-startup-hook
()
(if (get-buffer "*GNU
Emacs*")
(kill-buffer "*GNU
Emacs*")))
)
Giorgos Keramidas
> Every time I start Emacs I have to bury to *GNU Emacs" buffer. This
> is a little bit annoying having to do this.
Try setting:
inhibit-startup-screen => t
inhibit-splash-screen => t
For more details, look at the documentation of these variables with:
C-h v inhibit-startup-screen RET
C-h v inhibit-splash-screen RET
Adam Rooke
(setq inhibit-start-screen 1)
Documentation:
Non-nil inhibits the startup screen.
This is for use in your personal init file (but NOT site-start.el), once
you are familiar with the contents of the startup screen.
Nikolaj Schumacher
> I would at least prefer the default-directory of that buffer to be
> "~/" so that I can easily load a file that I want to edit.
Did you know that you can just type ~/ when opening a file and the
default input will disappear?
regards,
Nikolaj Schumacher
Charles Sebold
> Every time I start Emacs I have to bury to *GNU Emacs" buffer. This
> is a little bit annoying having to do this. If I can't kill this
> buffer, then I would at least prefer the default-directory of that
> buffer to be "~/" so that I can easily load a file that I want to
> edit. The following code is what I have written to accomplish that
> task but sadly it doesn't appear to work.
In addition to everything else that's been said, I've noticed that
hitting "q" deletes the buffer and sends me to the good old *scratch*
buffer, too. I just got used to doing that.
--
Charles Sebold 16th of September, 2008
Davin Pearson
wrote:
> Try setting:
>
> inhibit-startup-screen => t
> inhibit-splash-screen => t
>
It Works! Thank you for your help!
Xah
I think the existance of the lisp scratch buffer is one of the major
usability problem of emacs that prevents emacs from being widely
adopted by most text editing audience.
I wrote some detail about it here:
http://xahlee.org/emacs/modernization.html
I think emacs should get rid of the lisp scratch buffer completely.
Instead, have Ctrl+n for New File, that creates a new buffer named
“untitled” and default to text mode. The default mode can be
customized to set to lisp mode for those who wishes of course.
following is a excerpt
--------------------------
Q: I find the “*scratch*” buffer useful...
A: Just about anything, once it is exposed to human animals, a
significant number will find it useful. This is a matter of habit and
conditioning and applies to all aspects of human habit or behavior, as
you'll find people in cultures into things you couldn't dream of.
(such as body modification as flattening their breasts, widening a
hole in lower lips... to lesser degree tattoo, muscle bulking... or
sexual preferences and fetishes such as shit-eating... , or food
intake habits (eating/drinking/diet habits) ...)
Suppose you have random features in a software, and give this software
to a large number of people to use for few decades. Chances are, every
feature will be useful to a good sized number of people. People, in a
sense, adapt their work habits to the features.
The issue about emacs's “*scratch*” “buffer” is that:
* It is not useful by 99% of letter writers. If they wanted a
scratch pad, they can open a new document and not save it. This way is
familiar to all software users.
* The “*scratch*” “buffer” is primarily designed for elisp
programers. (it defaults to lisp mode) Majority of people who use
emacs are not lisp coders. For lisp coders, they can easily customize
their emacs to have a “*scratch*” “buffer”.
* The “*scratch*” “buffer” is a intrusive idiosyncrasy. It is
persistent, cannot be closed (it regenerates). It is foreign to all
programers. This idiosyncrasy is the first thing presented to users,
and it persists.
---------------------------------------------
I have made a implementation of my suggestion solution. It will be
incorporated into my ergonomic keybinding in the next version.
Here's the basics:
(global-set-key (kbd "C-n") 'new-empty-buffer) ; Open New File
(defun new-empty-buffer ()
"Opens a new empty buffer."
(interactive)
(let ((buf (generate-new-buffer "untitled")))
(switch-to-buffer buf)
(funcall (and initial-major-mode))
(setq buffer-offer-save t)))
;; note: emacs won't offer to save a buffer that's
;; not associated with a file,
;; even if buffer-modified-p is true.
;; One work around is to define your own my-kill-buffer function
;; that wraps around kill-buffer, and check on the buffer modification
;; status to offer save
;; This custome kill buffer is close-current-buffer.
For the command close-current-buffer, see:
http://xahlee.org/emacs/modern_operations.el
Xah
∑ http://xahlee.org/
☄
Giorgos Keramidas
> On Sep 16, 1:44 am, Charles Sebold <cseb...@gmail.com> wrote:
>> In addition to everything else that's been said, I've noticed that
>> hitting "q" deletes the buffer and sends me to the good old *scratch*
>> buffer, too. I just got used to doing that.
>
> I think the existance of the lisp scratch buffer is one of the major
> usability problem of emacs that prevents emacs from being widely
> adopted by most text editing audience.
Hi Xah,
For what it's worth, I think I would appreciate an option that makes the
current behavior of the *scratch* buffer tunable, i.e. by an option like:
(defvar scratch-buffer-uses-fundamental-mode nil
"Non-nil makes the *scratch* buffer use `fundamental-mode'.
Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
If you are not really interested to use `lisp-interaction-mode',
but you would prefer to start all scratch buffers in
`fundamental-mode', to start editing text instead of typing Lisp
expressions, set the `scratch-buffer-uses-fundamental-mode'
variable to a non-nil value.")
> I wrote some detail about it here:
> http://xahlee.org/emacs/modernization.html
But I don't like the `personal attack' style that this text uses, and I
don't really agree with *all* the proposed `modernization' features.
If you were to split that document into smaller `features' and one of
them was a proposal to add an option for the default mode of *scratch*
buffers, and a good description of how you would suggest that we add a
prompt for *scratch* buffers that are modified, I would be more than
willing to help you with the testing and integration of any patches to
the main Emacs source tree.
My own idea about *scratch* buffers that do not fire up only in the
current `lisp-interaction-mode' state is something like:
* Add an option that may be set to a non-nil value to make *scratch*
buffers use `fundamental-mode', or even better, an option that
defines _which_ mode a *startup* buffer should use.
Two possible variations of this option would be:
;;; Boolean option
;; A boolean option that makes *scratch* buffers fire up in
;; `fundamental-mode' by default. The option would be set to `nil'
;; by default, but it should be easy to tweak the option once and
;; keep it set forever.
(defcustom scratch-buffer-uses-fundamental-mode nil
"Non-nil makes the *scratch* buffer use `fundamental-mode'.
Emacs recreates the *scratch* buffer in `lisp-interaction-mode'.
If you are not really interested to use `lisp-interaction-mode',
but you would prefer to start all scratch buffers in
`fundamental-mode', to start editing text instead of typing Lisp
expressions, set the `scratch-buffer-uses-fundamental-mode'
variable to a non-nil value."
:type 'boolean
:group 'editing-basics
:group 'convenience)
;;; A list of choices.
;; Still set to the default `lisp-interaction-mode'
(defcustom scratch-buffer-startup-mode 'lisp-interaction-mode
"The default mode to use for *scratch* buffers.
If the value is `lisp' start in lisp-interaction-mode.
If the value is `text' start in text-mode.
If the value is `fundamental' start in whatever mode has been
configured as the default `fundamental-mode'.
If the value is a function, use that function to set-up the
startup mode of *scratch* buffers."
:type '(choice (const :tag "Lisp interaction mode" 'lisp)
(const :tag "Text mode" 'text)
(const :tag "Fundamental mode" 'fundamental)
(function :tag "Custom mode"))
:group 'editing-basics
:group 'convenience)
* Add the scratch buffer to the list of buffers that trigger a prompt
if they are modified and the user types `C-x C-c' to leave Emacs.
Right now one can open _one_ scratch buffer only. Emacs uses
`buffer-modified-p' as the only criterion, but this doesn't work for
scratch buffers now. It should probably be an option too, or even a
function that checks `scratch-buffer-startup-mode' and decides. I
haven't thought too much about this yet, so I am not sure if it
sounds like a sensible thing to do.
Kevin Rodgers
> I think the existance of the lisp scratch buffer is one of the major
> usability problem of emacs that prevents emacs from being widely
> adopted by most text editing audience.
I think you should customize Emacs to behave as you want and not presume
to speak for most text editing audience:
,----[ C-h v initial-major-mode RET ]
| initial-major-mode is a variable defined in `startup.el'.
| Its value is
| lisp-interaction-mode
|
|
| Documentation:
| Major mode command symbol to use for the initial `*scratch*' buffer.
|
| You can customize this variable.
|
| [back]
`----
--
Kevin Rodgers
Denver, Colorado, USA
Xah
> Xahwrote:
> > I think the existance of the lisp scratch buffer is one of the major
> > usability problem of emacs that prevents emacs from being widely
> > adopted by most text editing audience.
>
> I think you should customize Emacs to behave as you want and not presume
> to speak for most text editing audience:
i was making a suggestion. As such, its premise is that the suggested
idea is good for general audience.
perhaps you thought that my suggestion actually is not reasonable and
is more like a one person's preference. If so, please give reasons.
Xah
∑ http://xahlee.org/
☄
Xah Lee
«V guvax gur rkvfgnapr bs gur yvfc fpengpu ohssre vf bar bs gur znwbe
hfnovyvgl ceboyrz bs rznpf gung ceriragf rznpf sebz orvat jvqryl
nqbcgrq ol zbfg grkg rqvgvat nhqvrapr.»
Tvbetbf Xrenzvqnf jebgr:
> Uv Knu ,
>
> Sbe jung vg'f jbegu, V guvax V jbhyq nccerpvngr na bcgvba gung znxrf gur
> pheerag orunivbe bs gur *fpengpu* ohssre ghanoyr, v.r. ol na bcgvba yvxr:
>
> (qrsine fpengpu-ohssre-hfrf-shaqnzragny-zbqr avy
> "Aba-avy znxrf gur *fpengpu* ohssre hfr `shaqnzragny-zbqr'.
>
> Rznpf erperngrf gur *fpengpu* ohssre va `yvfc-vagrenpgvba-zbqr'.
> Vs lbh ner abg ernyyl vagrerfgrq gb hfr `yvfc-vagrenpgvba-zbqr',
> ohg lbh jbhyq cersre gb fgneg nyy fpengpu ohssref va
> `shaqnzragny-zbqr', gb fgneg rqvgvat grkg vafgrnq bs glcvat Yvfc
> rkcerffvbaf, frg gur `fpengpu-ohssre-hfrf-shaqnzragny-zbqr'
> inevnoyr gb n aba-avy inyhr.")
ol univat n Arj pbzznaq jvgu Pgey+a xrl, vg fbyirf guvf ceboyrz jvgu
fpengpu cyhf jung lbh jnag.
• Gur Arj pbzznaq vf n fgnaqneq npebff Znp, Jvaqbjf, Havk (Yvahk). Vg
vf snzvyvne gb nyy fbsgjner hfref.
• Gur Pgey+a fubegphg sbe Arj vf fgnaqneq naq snzvyvne gb nyy fbsgjner
hfref.
• Gur Arj pbzzznaq (jurer gur pbeerfcbaqvat ryvfc pbzznaq anzr zvtug
jvyy or anzrq arj-rzcgl-ohssre), pna fhccynag pbzcyrgryl gur
shapgvbanyvgl bs *fpengpu* ohssre.
• Jura hfref jnag gb unir n fpengpu ohssre, ur pna perngr vg ol fvzcyl
cerffvat gur fubegphg, naq jura ur qbrfa'g jnag vg, ur pna fvzcyl
pybfr vg jvgu n fgnaqneq xrlfgebxr Pgey+j.
• Hfref pna unir zhygvcyr *fpengpu* ohssref rnfvyl jvgubhg gur arrq gb
ybbx vagb rznpf qbp.
• Gur “*fpengpu*” anzr vf abg va fbzr grpuavpny wnetba frafr gur orfg
bar. “*hagvgyrq*” be “hagvgyrq” vf n orggre bar, naq jvqryl hfrq
npebff fbzr 99% bs BFrf naq nccyvpngvbaf. Gur anzr “*fpengpu*” vf
haarprffnevyl aneebj, nf gb vaqvpngr gung gur ohssre'f pbagrag vf bayl
sbe grzc checbfrf, juvyr “hagvgyrq” pna vapyhqr gur checbfr bs
fpengpu, naq pna or qvfpneqrq whfg nf “*fpengpu*”.
• Gur erfcnjavat bs “*fpengpu*” ohssre orunivbe vf hahfhny, nyzbfg
havdhr gb rznpf nzbat gur gubhfnaqf bs nccyvpngvba gbqnl. Yrggvat hfre
unir pbageby gb perngr naq naq qvfpneq fhpu ohssre vf orggre.
• Gur “*fpengpu*” ohssre vf cevznevyl hfrq ol ryvfc cebtenzref. Srj
cebsrffvbany cebtenzref va gur VG vaqhfgel xabjf nobhg yvfc, naq bayl
zvabe crepragntr bs rznpf hfref npghnyyl pbqr rznpf yvfc.
> > V jebgr fbzr qrgnvy nobhg vg urer:
> > uggc://knuyrr.bet/rznpf/zbqreavmngvba.ugzy
>
> Ohg V qba'g yvxr gur `crefbany nggnpx' fglyr gung guvf grkg hfrf, naq V
> qba'g ernyyl nterr jvgu *nyy* gur cebcbfrq `zbqreavmngvba' srngherf.
Gur Zbqreavmngvba bs Rznpf negvpyr ng
uggc://knuyrr.bet/rznpf/zbqreavmngvba.ugzy
qbrf abg unir nal “crefbany nggnpx” jevgvat fglyr. Creuncf lbh jrer
guvaxvat zl bgure arjftebhc cbfgf ryfrjurer jurer guvf vffhr vf
qvfphffrq.
> V qba'g ernyyl nterr jvgu *nyy* gur cebcbfrq `zbqreavmngvba'
> srngherf.
Vs lbh nterr gb fbzr, cyrnfr svyr n oht ercbeg, be uryc fcernq gur
vqrn. Gunaxf sbe qvfphffvat guvf vffhr jvgu zr.
> Vs lbh jrer gb fcyvg gung qbphzrag vagb fznyyre `srngherf' naq bar bs
> gurz jnf n cebcbfny gb nqq na bcgvba sbe gur qrsnhyg zbqr bs *fpengpu*
> ohssref, naq n tbbq qrfpevcgvba bs ubj lbh jbhyq fhttrfg gung jr nqq n
> cebzcg sbe *fpengpu* ohssref gung ner zbqvsvrq, V jbhyq or zber guna
> jvyyvat gb uryc lbh jvgu gur grfgvat naq vagrtengvba bs nal cngpurf gb
> gur znva Rznpf fbhepr gerr.
>
> Zl bja vqrn nobhg *fpengpu* ohssref gung qb abg sver hc bayl va gur
> pheerag `yvfc-vagrenpgvba-zbqr' fgngr vf fbzrguvat yvxr:
>
> * Nqq na bcgvba gung znl or frg gb n aba-avy inyhr gb znxr *fpengpu*
> ohssref hfr `shaqnzragny-zbqr', be rira orggre, na bcgvba gung
> qrsvarf _juvpu_ zbqr n *fgneghc* ohssre fubhyq hfr.
>
> Gjb cbffvoyr inevngvbaf bs guvf bcgvba jbhyq or:
>
> ;;; Obbyrna bcgvba
> ;; N obbyrna bcgvba gung znxrf *fpengpu* ohssref sver hc va
> ;; `shaqnzragny-zbqr' ol qrsnhyg. Gur bcgvba jbhyq or frg gb `avy'
> ;; ol qrsnhyg, ohg vg fubhyq or rnfl gb gjrnx gur bcgvba bapr naq
> ;; xrrc vg frg sberire.
>
> (qrsphfgbz fpengpu-ohssre-hfrf-shaqnzragny-zbqr avy
> "Aba-avy znxrf gur *fpengpu* ohssre hfr `shaqnzragny-zbqr'.
>
> Rznpf erperngrf gur *fpengpu* ohssre va `yvfc-vagrenpgvba-zbqr'.
> Vs lbh ner abg ernyyl vagrerfgrq gb hfr `yvfc-vagrenpgvba-zbqr',
> ohg lbh jbhyq cersre gb fgneg nyy fpengpu ohssref va
> `shaqnzragny-zbqr', gb fgneg rqvgvat grkg vafgrnq bs glcvat Yvfc
> rkcerffvbaf, frg gur `fpengpu-ohssre-hfrf-shaqnzragny-zbqr'
> inevnoyr gb n aba-avy inyhr."
> :glcr 'obbyrna
> :tebhc 'rqvgvat-onfvpf
> :tebhc 'pbairavrapr)
>
> ;;; N yvfg bs pubvprf.
> ;; Fgvyy frg gb gur qrsnhyg `yvfc-vagrenpgvba-zbqr'
> (qrsphfgbz fpengpu-ohssre-fgneghc-zbqr 'yvfc-vagrenpgvba-zbqr
> "Gur qrsnhyg zbqr gb hfr sbe *fpengpu* ohssref.
>
> Vs gur inyhr vf `yvfc' fgneg va yvfc-vagrenpgvba-zbqr.
> Vs gur inyhr vf `grkg' fgneg va grkg-zbqr.
> Vs gur inyhr vf `shaqnzragny' fgneg va jungrire zbqr unf orra
> pbasvtherq nf gur qrsnhyg `shaqnzragny-zbqr'.
> Vs gur inyhr vf n shapgvba, hfr gung shapgvba gb frg-hc gur
> fgneghc zbqr bs *fpengpu* ohssref."
> :glcr '(pubvpr (pbafg :gnt "Yvfc vagrenpgvba zbqr" 'yvfc)
> (pbafg :gnt "Grkg zbqr" 'grkg)
> (pbafg :gnt "Shaqnzragny zbqr" 'shaqnzragny)
> (shapgvba :gnt "Phfgbz zbqr"))
> :tebhc 'rqvgvat-onfvpf
> :tebhc 'pbairavrapr)
>
> * Nqq gur fpengpu ohssre gb gur yvfg bs ohssref gung gevttre n cebzcg
> vs gurl ner zbqvsvrq naq gur hfre glcrf `P-k P-p' gb yrnir Rznpf.
>
> Evtug abj bar pna bcra _bar_ fpengpu ohssre bayl. Rznpf hfrf
> `ohssre-zbqvsvrq-c' nf gur bayl pevgrevba, ohg guvf qbrfa'g jbex sbe
> fpengpu ohssref abj. Vg fubhyq cebonoyl or na bcgvba gbb, be rira n
> shapgvba gung purpxf `fpengpu-ohssre-fgneghc-zbqr' naq qrpvqrf. V
> unira'g gubhtug gbb zhpu nobhg guvf lrg, fb V nz abg fher vs vg
> fbhaqf yvxr n frafvoyr guvat gb qb.
V guvax lbhe zbqry pna pbzcyvpngr gur hfre vagresnpr.
N fvzcyr Arj zrah pbzznaq (perngr-rzcgl-ohssre) gung perngrf n arj
ohssre va fbzr phfgbzvmnoyr qrsnhyg zbqr, fbyirf jung lbh jnagrq naq
vg tvirf lbh rkgen cbjre.
Rznpf qbrf abg cebivqr n hfre yriry shapgvba gb perngr n arj ohssre.
Vg unf whfg Arj, juvpu npghnyyl perngrf n rzcgl svyr. Zbfg nccf'f Arj
pbzznaq qbrf abg jbex yvxr gung. Gurl npghnyyl whfg perngr n arj
ohssre, naq bayl jura hfre fnir vg vg orpbzrf n svyr.
Perngvat n arj ohssre vf npghnyyl dhvgr hfrshy. Sbe rknzcyr, jryy
xabja cebtenzre Fgrirl Lrtt va uvf “Rssrpgvir Rznpf” oybt yvfg vg nf n
gbc 10 gvc va rznpf cebqhpgvivgl. Gur rznpf zrah fubhyq unir n Arj
pbzznaq jvgu Pgey+a gung pnyyf perngr-rzcgl-ohssre.
-------------------------
CF nf v zragvbarq va cerivbhf zrffntr, v qvq vzcyrzrag gur nobir. Va
zl qensg pbqr,
• perngr-arj-ohssre jvyy perngr n arj rzcgl ohssre anzrq “hagvgyrq”.
(guvf fubhyq or nqqrq gur zrah pbzznaq haqre “Svyr‣Arj” ohg v unira'g
qbar gung lrg.)
• perngr-arj-ohssre unf fgnaqneq xrlobneq fubegphg Pgey+a.
• ryvfc pbzznaq pybfr-pheerag-ohssre jvyy pybfr gur pheerag ohssre,
naq vs vg vf n ohssre abg nffbpvngrq jvgu n svyr (fhpu nf “hagvgyrq”),
vg'yy nfx hfre gb fnir (hayrff vg unf ab pbagrag)
• pybfr-pheerag-ohssre unf gur fgnaqneq xrlobneq fubegphg Pgey+j.
• pybfr-pheerag-ohssre fubhyq unir zrah haqre “Svyr‣Pybfr”, ohg vg vf
abg pheeragyl qbar. Gur rkvfgvat “Svyr‣Pybfr” zrah pbzznaq pnyyf xvyy-
guvf-ohssre, juvpu unf 2 ceboyrzf. (1) vg qbrfa'g unir n fubegphg. (2)
vg qbrfa'g nfx hfref gb fnir n aba-svyr-nffbpvngrq ohssre ng nyy.
(guvf vf znwbe ceboyrz gung yrnqf gb ybfvat qngn; vapyhqvat
“*fpengpu*” ohssre. Gur snpg gung rznpf hfref qbag frrz gb abgvpr guvf
ceboyrz vf orpnhfr vg qbrfa'g unir n xrlobneq fubegphg, fb gung
npghnyyl abobql hfrf guvf pbzznaq. Zbfg hfr xvyy-ohssre, juvpu vf
naablvat orpnhfr vg cebzcf rira vs gur svyr vf nyernql fnirq.)
Lbh pna svaq gur pbqr sbe gur nobir vzcyrzragngvba urer:
uggc://knuyrr.bet/rznpf/zbqrea_bcrengvbaf.ry
Gur pbqr vf cenpgvpnyyl hfnoyr, fvapr v hfr vg qnvyl sbe nobhg unys n
lrne abj jvgu vaperzragny vzcebirzrag naq oht svkrf, ohg v'z fher vg
pna hfr n ybg zber cbyvfuvat sbe choyvp hfr.
Vg vf TCY'q, fb srry serr gb teno cvrprf sbe lbhe bja hfr be fhozvg
vagb TAH.
bar guvat yrnqf gb nabgure... v'z tbvat gb svyr n oht ercbeg (n
fhttrfgvba) ba gur “*fpengpu*” abj.
(sbe fbzr ernfba, tbbtyr tebhcf jba'g yrg zr cbfg guvf zrffntr... fb
v'z ercylvat ol rznvy sbe abj)
Knu
∑ uggc://knuyrr.bet/
☄
Xah Lee
> Knu jebgr:
> «V guvax gur rkvfgnapr bs gur yvfc fpengpu ohssre vf bar bs gur znwbe
> hfnovyvgl ceboyrz bs rznpf gung ceriragf rznpf sebz orvat jvqryl
> nqbcgrq ol zbfg grkg rqvgvat nhqvrapr.»
>
...
i was quite pissed that google groups wont let me post my message.
Trying different google account, clearing cache & cookie, etc didn't
help. Even using the option Reply To Author (as private email) didn't
work. I suspect google is checking content and think it's a spam,
because there are hundreds of spams that uses my name Xah Lee or my
website XahLee.org's content.
after a day's frustration, the the above message is sent in rot13, and
indeed it went thru. Apparently google is checking message content.
Fuck google motherfucking incompetence.
Xah
∑ http://xahlee.org/
☄
Xah Lee
on my website, at:
Suggestions on Emacs's Scratch Buffer
http://xahlee.org/emacs/modernization_scratch_buffer.html
The following is a text version.
----------------------------------
Suggestions on Emacs's Scratch Buffer
Xah Lee, 2008-09
In the article The Modernization of Emacs, i suggested that emacs's
“*scratch*” buffer be removed. In this article, we give some detail
about it.
In the article, i gave the following as primary reasons that scratch
buffer should be removed:
* It is not useful by 99% of letter writers. If they wanted a
scratch pad, they can open a new document and not save it. This way is
familiar to all software users.
* The “*scratch*” “buffer” is primarily designed for elisp
programers. (it defaults to lisp mode) Majority of people who use
emacs are not lisp coders. For lisp coders, they can easily customize
their emacs to have a “*scratch*” “buffer”.
* The “*scratch*” “buffer” is a intrusive idiosyncrasy. It is
persistent, cannot be closed (it regenerates). It is foreign to all
programers. This idiosyncrasy is the first thing presented to users,
and it persists.
Here are few minor reasons:
* There is no easy, intuitive way to create multiple scratch
buffers. (it is done by using the switch-to-buffer command (C-x b) and
give name that is not one of existing buffers.)
* When the scratch buffer is closed, emacs does not prompt user to
save it. This easily causes data loss.
* A scratch pad can be very useful not just for temporary elisp
code but for any scratch notes or programing in other languages. (For
example, well known programer Stevey Yegg in his popular Effective
Emacs↗ blog list it as a top 10 tip in emacs productivity.) Emacs's
“*scratch*” buffer is narrowly geared for elisp editing only,
defaulting to emacs-lisp-mode.
* Emacs does not provide a user level function to create a new
buffer. It has “Open New file...”, which actually creates a empty file
and immediately prompt user for a file name. This is annoying. Most
apps's New File command actually just create a new buffer, and only
when user save it it becomes a file. When user closes it, it prompts
for saving.
Proposed Fix
I propose that emacs should also add a menu command “New buffer”, with
the keyboard shortcut “Ctrl+n”. Once called, it should create a
scratch buffer titled “untitled”. If one already exists, append
numbers such “untitled 2”. Here are the reasons:
* The New command is a standard across Mac, Windows, Unix (Linux).
It is familiar to all software users.
* The Ctrl+n shortcut for New is standard and familiar to all
software users.
* A New Buffer command (where the corresponding elisp command name
might will be named new-empty-buffer), can supplant completely the
functionality of *scratch* buffer.
* When users want to have a scratch buffer, he can create it by
simply pressing the shortcut, and when he doesn't want it, he can
simply close it with a standard keystroke Ctrl+w.
* By adopting the New Buffer and Ctrl+n, users can intuitively
create multiple scratch buffers for any purpose.
* The name “untitled” is conventional, far more widely understood,
and more general than “scratch”.
* For those who uses scratch buffer for elisp coding, she can set
the default mode for untitled buffer to emacs lisp mode.
* Adopting the suggestion would fix several problems for those who
actually use emacs's scratch buffer. (1) emacs no longer mysteriously
respawn the “*scratch*” buffer when user didn't want it. (2) user can
create multiple scratch buffers by just pressing a shortcut. (3) User
can close a scratch buffer and emacs will ask the user if she wants to
save it.
Draft Implementation
The above suggestion is experimentally implemented in my Ergonomic
Keyboard Shortcut Layout For Emacs. The following are the elisp files,
primarily the modern_operations.el:
* ergonomic_keybinding_dvorak.el.
* ergonomic_keybinding_qwerty.el.
* modern_operations.el.
Some detail about the implementation:
* create-new-buffer will create a new empty buffer named
“untitled”. (this should be added to the menu under “File‣New Buffer”
but i haven't done that yet.)
* create-new-buffer has standard keyboard shortcut Ctrl+n.
* elisp command close-current-buffer will close the current
buffer, and if it is a buffer not associated with a file (such as
“untitled”), it'll ask user to save (unless it has no content)
* close-current-buffer has the standard keyboard shortcut Ctrl+w.
* close-current-buffer should have menu under “File‣Close”, but it
is not currently done. The existing “File‣Close” menu command in emacs
22.2 calls kill-this-buffer, which has 2 problems. (1) it doesn't have
a shortcut. (2) it doesn't ask users to save a buffer that are not
associated with file (in effect, any text in the buffer is
irreversibly lost immediately). The standard emacs command used to
close a file is kill-buffer (Ctrl+x k). It has a major problem of
prompting user even if the file is already saved.
I have been using the above code daily since late 2007, with
incremental improvement and bug fixes. i'm sure it can use a lot more
polishing for public use. The code is GPL'd, so feel free to grab
pieces for your own use or submit into GNU.
Xah
∑ http://xahlee.org/
☄
tyler
> «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.
David Kastrup
> Xah Lee <x...@xahlee.org> writes:
>
>> «I think the existance of the lisp scratch buffer is one of the major
>> usability problem of emacs that prevents emacs from being widely
>> adopted by most text editing audience.»
>
> Ironically, I just used the scratch buffer as the repository for the
> text of your previous message. rot13-region doesn't work in the
> read-only gnus buffers, so I needed to transfer it to a different
> buffer.
C-c C-r works in gnus. Which does not mean that alternative ways are a
bad idea.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Xah Lee
find that the suggestion is technical superior in everyway. You just
need to keep a open mind.
On Sep 18, 5:39 pm, tyler <tyler.sm...@mail.mcgill.ca> wrote:
> XahLee<x...@xahlee.org> writes:
> > «I think the existance of the lisp scratch buffer is one of the major
> > usability problem of emacs that prevents emacs from being widely
> > adopted by most text editing audience.»
>
> Ironically, I just used the scratch buffer as the repository for the
> text of your previous message. rot13-region doesn't work in the
> read-only gnus buffers, so I needed to transfer it to a different
> buffer.
You don't particularly need emacs *scratch* for that.
Imagine in NewEmacs, you just press Ctrl+n, then bang, you do exactly
the same thing. It is operatively easier then switching to *scratch*,
it is also easier on the mind because user don't have to remember
about some special *scratch*. It is simply a new buffer.
> I didn't need the scratch buffer to do this, as I could have used a
> temporary file (see below). But I think the scratch buffer does serve a
> valid purpose that warrants it's inclusion by default. In my opinion the
> one design feature that underlies Emacs success is the complete
> rejection of the distinction between user and developer. The scratch
> buffer is an extension of this mindset. Emacs assumes that everyone who
> uses it has a vested interest in understanding, exploring, and tweaking
> the code, so it is natural to provide the scratch buffer to enable and
> encourage this.
Imagine in NewEmacs, it also extending user's mindset exactly like
emacs, except it's even more easier to use, faster to execute, simpler
to operate, while having no comparative disadvantage.
> > Emacs does not provide a user level function to create a new buffer.
> > It has just New, which actually creates a empty file. Most apps's New
> > command does not work like that. They actually just create a new
> > buffer, and only when user save it it becomes a file.
>
> You are mistaken. I don't know what 'New' is in Emacs,
It is a menu command. I should've written “New Buffer”, but now the
whole polished article is here:
See here:
http://xahlee.org/emacs/modernization_scratch_buffer.html
> but find-file,
> when asked to find a file which does not already exist, creates a new
> buffer that is not associated with a file _unless_ it is saved.
As i detailed in the above article, find-file command has a few
problems. It immediately prompt user for a file name in some existing
dir. This is annoying and basically makes the command unfit for the
purpose of creating a new buffer.
The other common way, is by switching to a new buffer and type a name
not used by existing buffers. This method is also unfit as i detailed,
because it is somewhat obsure, and emacs doesn't prompt user to save
the buffer when user closes it.
> I
> regularly use this feature to create temporary files, which I may decide
> to save or not as I require. One of the advantages of this approach is
> that you can choose the mode for the temporary file by giving it an
> appropriate extension. If I need a buffer to work out some throw-away R
> code, I can open asdf.R, run the code, and delete the buffer.
the advantage you discussed above is a side effect. If it is a good
idea, in NewEmacs it can also be made so that user can call a command
something like switch-to-mode-by-file-extension and simply type file
name extensions to switch to the right mode.
Xah
∑ http://xahlee.org/
☄
Eli Zaretskii
> Date: Thu, 18 Sep 2008 16:50:50 -0700 (PDT)
>
> * Emacs does not provide a user level function to create a new
> buffer. It has “Open New file...”, which actually creates a empty file
> and immediately prompt user for a file name. This is annoying.
This is incorrect. No file is created on disk until you actually save
the buffer. Until then, only a buffer is created.
> I propose that emacs should also add a menu command “New buffer”, with
> the keyboard shortcut “Ctrl+n”. Once called, it should create a
> scratch buffer titled “untitled”. If one already exists, append
> numbers such “untitled 2”.
If I ever want a Notepad, I'd just launch that. I don't need Emacs to
emulate it.
Xah Lee
> > From: Xah Lee <x...@xahlee.org>
> > Date: Thu, 18 Sep 2008 16:50:50 -0700 (PDT)
>
> > * Emacs does not provide a user level function to create a new
> > buffer. It has “Open New file...”, which actually creates a empty file
> > and immediately prompt user for a file name. This is annoying.
>
> This is incorrect. No file is created on disk until you actually save
> the buffer. Until then, only a buffer is created.
Ok, my original phrasing is a bit off. Please focus on the main ideas.
Here's a better phrasing:
• Emacs does not provide a user level function to create a new buffer.
It has “Open file...” (a wrapper to the find-file command), which
immediately prompt user for a full file path. This is annoying. Modern
apps's New File command actually just create a new untitled file
without prompting, and only when user save it it prompt a file name.
If user closes it, it prompts for saving.
In newsgroup discussion, people tend to nick pick details and often
give no acknowledgement even if they agree in general. So, if a
criticism or idea X is posted in the thread's original post, often
there will be several responses that nick pick details that are non-
critical to the main idea. So, often, the thread becomes large and
derailed and little critical discussion.
> > I propose that emacs should also add a menu command “New buffer”, with
> > the keyboard shortcut “Ctrl+n”. Once called, it should create a
> > scratch buffer titled “untitled”. If one already exists, append
> > numbers such “untitled 2”.
>
> If I ever want a Notepad, I'd just launch that. I don't need Emacs to
> emulate it.
The issue here is not about whether one Eli Zaretskii wants Microsoft
Notepad (assuming it is Microsoft Notepad you are talking about).
Perhaps you are using the term “Notepad” as a general concept. In that
case, emacs's *scratch* buffer is also a notepad. So, i don't know
what u mean except perhaps you are just fooling around.
Xah
∑ http://xahlee.org/
☄
tyler
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
xraysm...@gmail.com
and enter a name of a non-existing buffer. Not once is there a prompt
for a file-name. I find this useful as I create tens of buffers a day,
holding chunks of files I'm twiddling with, notes from phone calls,
lists of file names, etc. I don't want to save them to disk, but I
sure as heck need to give that buffer a name so I can find it back
amongst all the other things I have. And if I close it without saving,
Emacs prompts me gently -- it doesn't demand a filename, it asks if I
want to save it. And only then, if I say yes, does it prompt for a
filename. How polite.
I grew up with a "scratch-pad" next to the telephone (yeah, kids, it
had a dial), and sometimes we'd get home-made scratch-pads for
Christmas. What fun!
Cor Gest
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Here's a better phrasing:
>
> • Emacs does not provide a user level function to create a new buffer.
> It has “Open file...” (a wrapper to the find-file command), which
> immediately prompt user for a full file path. This is annoying. Modern
> apps's New File command actually just create a new untitled file
> without prompting, and only when user save it it prompt a file name.
> If user closes it, it prompts for saving.
Emacs _never_ 'opens' files, it merely visits them and copies its
content into a (named)-buffer.
After you are done messing with that buffer you order emacs to write the
content of the buffer to file-name to relace it and saving
the unaltered-visited-file. (you _do_ use versioning, don't you ?)
If you cannot understand this type of editing you really should
not use emacs at all and use something else.
Oh, BTW emacs really is ment for people who know what they want to do
and those people do not create untitled files nor do they not know
where they are messing around in any filesystem, otherwise they should
not be allowed access to the system in the first place.
Cor
--
Mijn Tools zijn zo modern dat ze allemaal eindigen op 'saurus'
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
SPAM DELENDA EST http://www.clsnet.nl/mail.php
1st Law of surviving a gunfight : Have a gun
Eli Zaretskii
> Date: Fri, 19 Sep 2008 04:34:12 -0700 (PDT)
>
> On Sep 19, 1:53 am, Eli Zaretskii <e...@gnu.org> wrote:
> > > From: Xah Lee <x...@xahlee.org>
> > > Date: Thu, 18 Sep 2008 16:50:50 -0700 (PDT)
> >
> > > * Emacs does not provide a user level function to create a new
> > > buffer. It has “Open New file...”, which actually creates a empty file
> > > and immediately prompt user for a file name. This is annoying.
> >
> > This is incorrect. No file is created on disk until you actually save
> > the buffer. Until then, only a buffer is created.
>
> Ok, my original phrasing is a bit off. Please focus on the main ideas.
If you want people to listen to your ideas seriously, you will wish to
make a point of expressing them accurately.
> So, i don't know what u mean except perhaps you are just fooling
> around.
I meant what I said: Emacs does not need to be like other (primitive)
semi-editors, which don't distinguish between files and buffers.
And I'm not ``fooling around'' more than you do.
Xah Lee
> Suggestions on Emacs's Scratch Buffer
> http://xahlee.org/emacs/modernization_scratch_buffer.html
On Sep 19, 6:08 am, xraysmalev...@gmail.com wrote:
> Emacs provides a user level function to create a new buffer. C-x b,
> and enter a name of a non-existing buffer.
>...
> And if I close it without saving,
> Emacs prompts me gently -- it doesn't demand a filename, it asks if I
> want to save it. And only then, if I say yes, does it prompt for a
> filename. How polite.
what you reported doesn't seems to be the emacs behavior for me.
For example:
Type C-x b xyz RET to create a new buffer named xyz.
Type something in it.
Now type M-x kill-buffer RET. The buffer will be killed with all
content lost.
Xah
∑ http://xahlee.org/
☄
Xah Lee
> Some entity, AKA Xah Lee <x...@xahlee.org>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
> > Here's a better phrasing:
>
> > • Emacs does not provide a user level function to create a new buffer.
> > It has “Open file...” (a wrapper to the find-file command), which
> > immediately prompt user for a full file path. This is annoying. Modern
> > apps's New File command actually just create a new untitled file
> > without prompting, and only when user save it it prompt a file name.
> > If user closes it, it prompts for saving.
>
> Emacs _never_ 'opens' files, it merely visits them and copies its
> content into a (named)-buffer.
> After you are done messing with that buffer you order emacs to write the
> content of the buffer to file-name to relace it and saving
> the unaltered-visited-file. (you _do_ use versioning, don't you ?)
> If you cannot understand this type of editing you really should
> not use emacs at all and use something else.
huh? What is your point??
> Oh, BTW emacs really is ment for people who know what they want to do
> and those people do not create untitled files nor do they not know
> where they are messing around in any filesystem, otherwise they should
> not be allowed access to the system in the first place.
huh? what does this has to do with anything?
r u now saying emacs should only be for elite programers?
r u trying to say emacs is not Microsoft? hum?? I no unstand.
Perhaps u r having a sentiment someting like the following Q:
Q: Why should emacs want to be popular and why should emacs change to
conform the majority?
Luckly i have answered your Q previously, here:
http://xahlee.org/emacs/modernization.html
Quote:
A: This attitude has plagued unix and computer geekers for decades. In
the early 1990s (DOS and unix), tech geekers would sneer at graphical
menus and mouse, with hordes of reasons how pure text interface, the
command line, and or keyboard operations are sufficient and superior
than graphical user interface or using a mouse. This seems ridiculous
today, but such voices are commonly seen all over newsgroups. (Since
about 1998, linuxes are in a frenzied race to copy whole-sale of
Microsoft Windows's user interface ( KDE↗, GNOME↗, Lindows↗ ) trying
to make itself easy-to-use.)
We like emacs, we want emacs to be used by more people, we like more
elisp programers. By improving emacs, as a side effect emacs will also
be more popular. It is not a popularity contest.
Thanks.
Xah
∑ http://xahlee.org/
☄
Xah Lee
U wrote:
> If you want people to listen to your ideas seriously, you will wish to
> make a point of expressing them accurately.
Please understand, that the level of precision and time spend in
writing needed depends on the context. You would be a fool, to spend
one year to compose a newsgroup post. And, you would be moron if you
nickpick on spellings and phrasings that are not critical to the main
ideas.
I'm not sure ur a moron, but i wondered, because in my previous
message i specifically pointed out that please focus on main ideas.
You seem to me don't have much general education to sufficiently
understand the situation, but gave a retort about precision that is
typical of sophomorons.
> > So, i don't know what u mean except perhaps you are just fooling
> > around.
>
> I meant what I said: Emacs does not need to be like other (primitive)
> semi-editors, which don't distinguish between files and buffers.
Huh? where did u get the idea that emacs should be like other
primitive semi-editors? what's a primitive semi-editor? Do you mean
vi?
> And I'm not ``fooling around'' more than you do.
Fuck you.
Xah
∑ http://xahlee.org/
☄
xraysm...@gmail.com
I stand corrected: it doesn't prompt to save, since it was never a
file to begin with. I guess I'm just in the habit of saving when I
want to. Nevertheless, the original point was that Emacs DOES provide
a user-level function to create a new buffer. And it also allows you
to save that buffer as a file -- if you wish.
--the Other michael
Eli Zaretskii
> Date: Fri, 19 Sep 2008 07:32:11 -0700 (PDT)
>
> Hi Eli moron,
> [...]
> Fuck you.
Out of arguments again, eh?
Xah Lee
> > > Emacs provides a user level function to create a new buffer. C-x b,
> > > and enter a name of a non-existing buffer.
> > >...
> > > And if I close it without saving,
> > > Emacs prompts me gently -- it doesn't demand a filename, it asks if I
> > > want to save it. And only then, if I say yes, does it prompt for a
> > > filename. How polite.
Xah wrote:
> > what you reported doesn't seems to be the emacs behavior for me.
>
> > For example:
>
> > Type C-x b xyz RET to create a new buffer named xyz.
>
> > Type something in it.
>
> > Now type M-x kill-buffer RET. The buffer will be killed with all
> > content lost.
xraysmalev...@gmail.com wrote:
> I stand corrected: it doesn't prompt to save, since it was never a
> file to begin with. I guess I'm just in the habit of saving when I
> want to.
Thanks for the correction.
> Nevertheless, the original point was that Emacs DOES provide
> a user-level function to create a new buffer. And it also allows you
> to save that buffer as a file -- if you wish.
I don't agree that emacs does provide a user-level function for
creating a new buffer. The 2 practical methods to create a new buffer,
by find-file or switch-to-buffer, are both not designed to create a
new buffer for temp use, and each has serious problems in my opinion.
• There is no easy, intuitive way to create multiple scratch buffers.
(it is done by using the switch-to-buffer command (C-x b) and give
name that is not one of existing buffers.)
• Emacs does not provide a user level function to create a new buffer.
It has “Open file...” (a wrapper to the find-file command), which
immediately prompt user for a full file path. This is annoying. Modern
apps's New File command actually just create a new untitled file
without prompting, and only when user save it it prompt a file name.
If user closes it, it prompts for saving.
In summary: the problem with find-file is that it promps user to enter
a file name upfront. The problem with switch-to-buffer is that it
doesn't promp to save when user closes it. In both, the functions are
simply not designed for creating a new temp buffer.
-------------------------
But now suppose for a moment that find-file and switch-to-buffer are
very good for creating temp buffers. Isn't that more reason to get rid
of “*scratch*”?
original article http://xahlee.org/emacs/modernization_scratch_buffer.html
Xah
∑ http://xahlee.org/
☄
Nikolaj Schumacher
> Emacs _never_ 'opens' files, it merely visits them and copies its
> content into a (named)-buffer.
"Visit" is really just another metaphor for "open". Of course,
technically, open implies "keep open till closed", and I think that's
why "visit" was invented. But the term "open" has evolved. For
example, you "open" a website in your browser, and are in fact
"visiting" it. There's really little merit in distinguishing between
those two names.
> Oh, BTW emacs really is ment for people who know what they want to do
> and those people do not create untitled files
Yes, we do. We just call them (scratch) buffers. They provide all the
same features Xah's "untitled files" do. Really, the only differences are
nomenclature, the way of creating them and the fact that one exists by
default.
regards,
Nikolaj Schumacher
Alan Mackenzie
> Hi Eli moron,
> U wrote:
>> If you want people to listen to your ideas seriously, you will wish to
>> make a point of expressing them accurately.
> Please understand, that the level of precision and time spend in
> writing needed depends on the context. You would be a fool, to spend
> one year to compose a newsgroup post. And, you would be moron if you
> nickpick on spellings and phrasings that are not critical to the main
> ideas.
Sometimes, Xah, your spellings and phrasings, to say nothing of your
wierd variable length quotes with dangling bits, make your message all
but indecipherable.
Eli has one up on you there. English isn't his native language either,
yet he manages to convey his ideas with style and panache.
> I'm not sure ur a moron, but i wondered, because in my previous
> message i specifically pointed out that please focus on main ideas.
> You seem to me don't have much general education to sufficiently
> understand the situation, but gave a retort about precision that is
> typical of sophomorons.
OK, back to the main point. It seems that `switch-to-buffer' (C-x b)
does pretty much what you want. Except you seem upset that when you do
M-x kill-buffer, Emacs kills the buffer. I'd be unhappy if it didn't.
Actually, you'd be better typing C-x k. All you want, I think, is that
Emacs should give you a warning when you're about to kill such a buffer.
Why don't you implement this and post it up? It's not rocket science,
and you do have a basic grasp of Emacs Lisp. You seem to expect that
somebody else should do the work of implementing your ideas - that's
just not the way things work. Implement it now - it should take more
than an hour or two to modify C-x b - then we can try it out to see how
good it actually is.
> Fuck you.
Xah, don't try to fuck - you're not very good at it. Write some Elisp
instead.
> Xah
--
Alan Mackenzie (Nuremberg, Germany).
Eric S Fraga
> A: This attitude has plagued unix and computer geekers for decades. In
> the early 1990s (DOS and unix), tech geekers would sneer at graphical
> menus and mouse, with hordes of reasons how pure text interface, the
> command line, and or keyboard operations are sufficient and superior
> than graphical user interface or using a mouse. This seems ridiculous
> today, but such voices are commonly seen all over newsgroups. (Since
the reasons still stand and they are not ridiculous.
give me (screen|ratpoison)+emacs and I have the perfect working environment.
and often the underlying OS doesn't even matter.
'nuff said.
^xb gives what you wanted in any case.
--
MC . -.. --- - ..-. .-. .- --. .- .- - ..- -.-. .-.. .- -.-. ..- -.-
NL Professor Eric S Fraga, Chemical Engineering, University College London
GP Key: FFFCF67D F'prnt: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
BF >++++++++++[>++++++++++>+++++++++++[<]>-]>++.>++++.<-----.++++++.------.
Lowell Gilbert
> Out of arguments again, eh?
Can't identify the arguments until you know which function you're calling.
Alan Mackenzie
> In the article The Modernization of Emacs, i suggested that emacs's
> ?*scratch*? buffer be removed. In this article, we give some detail
> about it.
> In the article, i gave the following as primary reasons that scratch
> buffer should be removed:
> * It is not useful by 99% of letter writers. If they wanted a
> scratch pad, they can open a new document and not save it. This way is
> familiar to all software users.
It is necessary to have _some_ buffer when starting Emacs. I don't know
where you get your figure of 99% from. Even when it is not used, it's
not that big a nuisance.
> * The ?*scratch*? ?buffer? is primarily designed for elisp
> programers. (it defaults to lisp mode) Majority of people who use
> emacs are not lisp coders. For lisp coders, they can easily customize
> their emacs to have a ?*scratch*? ?buffer?.
It's designed for any rough notes, including bits of Lisp. The only
thing here I found bothersome was having C-j bound to
`eval-print-last-sexp', but I just rebound it to `newline-and-indent'.
> * The ?*scratch*? ?buffer? is a intrusive idiosyncrasy. It is
> persistent, cannot be closed (it regenerates). It is foreign to all
> programers. This idiosyncrasy is the first thing presented to users,
> and it persists.
Have you considered coding an option so that this buffer would only be
created when, at startup time, there was no other buffer? And coding
another option so that when you killed it, it would stay killed? Write
a patch, and submit it to emacs...@gnu.org. It might well be
accepted for Emacs 23.
[ .... ]
> Proposed Fix
> I propose that emacs should also add a menu command ?New buffer?, with
> the keyboard shortcut ?Ctrl+n?. Once called, it should create a
> scratch buffer titled ?untitled?. If one already exists, append
> numbers such ?untitled 2?. Here are the reasons:
As you know very well, there's already an important binding for C-n.
> * The New command is a standard across Mac, Windows, Unix (Linux).
> It is familiar to all software users.
However, in Emacs, which uses many more key bindings than just about any
other program, such a prime binding can't be spared for a command used
only sporadically. Of course, anybody who wants to rebind it is welcome.
> * The Ctrl+n shortcut for New is standard and familiar to all
> software users.
That's not true. It's not familiar to me.
> * A New Buffer command (where the corresponding elisp command name
> might will be named new-empty-buffer), can supplant completely the
> functionality of *scratch* buffer.
This exists already: C-x b <new-name>. I suggest you hack
`switch-to-buffer', possibly using advice at first, so that a C-u prefix
would cause it to create this new buffer.
> * When users want to have a scratch buffer, he can create it by
> simply pressing the shortcut, and when he doesn't want it, he can
> simply close it with a standard keystroke Ctrl+w.
<sigh>. Yet again, a prime binding like C-w can't be spared for such a
minor command. As you know, C-w is bound to `kill-region'.
> * By adopting the New Buffer and Ctrl+n, users can intuitively
> create multiple scratch buffers for any purpose.
Being able to create several *scratch*'es might well be useful.
> * The name ?untitled? is conventional, far more widely understood,
> and more general than ?scratch?.
A mere unimportant trifle.
> * For those who uses scratch buffer for elisp coding, she can set
> the default mode for untitled buffer to emacs lisp mode.
Or, more precisely, Lisp Interaction Mode. But this option exists
already: `initial-major-mode'.
> * Adopting the suggestion would fix several problems for those who
> actually use emacs's scratch buffer. (1) emacs no longer mysteriously
> respawn the ?*scratch*? buffer when user didn't want it. (2) user can
> create multiple scratch buffers by just pressing a shortcut. (3) User
> can close a scratch buffer and emacs will ask the user if she wants to
> save it.
> Draft Implementation
> The above suggestion is experimentally implemented in my Ergonomic
> Keyboard Shortcut Layout For Emacs.
Just as a suggestion, this seems silly. Creating buffers has nothing to
do with keyboard layouts. Why not separate out the functionality?
[ .... ]
David Kastrup
> David Kastrup <d...@gnu.org> writes:
>
>> tyler <tyler...@mail.mcgill.ca> writes:
>>
>>> Xah Lee <x...@xahlee.org> writes:
>>>
>>>> �I think the existance of the lisp scratch buffer is one of the major
>>>> usability problem of emacs that prevents emacs from being widely
>>>> adopted by most text editing audience.�
>>>
>>> Ironically, I just used the scratch buffer as the repository for the
>>> text of your previous message. rot13-region doesn't work in the
>>> read-only gnus buffers, so I needed to transfer it to a different
>>> buffer.
>>
>> C-c C-r works in gnus. Which does not mean that alternative ways are a
>> bad idea.
>
> That combination is not defined for me in gnus, but it did lead me to
> discover toggle-rot13-mode, which I *will* now bind to C-c C-r. Thanks!
Huh? When in the summary buffer, I get
C-c C-r runs the command gnus-summary-caesar-message, which is an
interactive compiled Lisp function in `gnus-sum.el'.
It is bound to C-c C-r, W r, <menu-bar> <Article> <Washing> <Rot 13>.
(gnus-summary-caesar-message &optional ARG)
Caesar rotate the current article by 13.
With a non-numerical prefix, also rotate headers. A numerical
prefix specifies how many places to rotate each letter forward.
[back]
Xah Lee
> We just call them (scratch) buffers. They provide all the
> same featuresXah's"untitled files" do. Really, the only differences are
> nomenclature, the way of creating them and the fact that one exists by
> default.
That's not the only differences. I have given detail on other
differences.
Quote from my article:
http://xahlee.org/emacs/modernization_scratch_buffer.html
«
• There is no easy, intuitive way to create multiple scratch buffers.
(it is done by using the switch-to-buffer command (C-x b) and give
name that is not one of existing buffers.)
• Emacs does not provide a user level function to create a new buffer.
It has menu “File‣Open file...” (a wrapper to the find-file command),
which immediately prompt user for a full file path. This is annoying.
Modern apps's New File command actually just create a new untitled
file without prompting, and only when user save it it prompt a file
name. If user closes it, it prompts for saving.
»
and quote from my post here:
I don't agree that emacs does provide a user-level function for
creating a new buffer. The 2 practical methods to create a new buffer,
by find-file or switch-to-buffer, are both not designed to create a
new buffer for temp use, and each has serious problems in my opinion.
• There is no easy, intuitive way to create multiple scratch buffers.
(it is done by using the switch-to-buffer command (C-x b) and give
name that is not one of existing buffers.)
• Emacs does not provide a user level function to create a new
buffer. It has “Open file...” (a wrapper to the find-file command),
which immediately prompt user for a full file path. This is annoying.
Modern apps's New File command actually just create a new untitled
file without prompting, and only when user save it it prompt a file
name. If user closes it, it prompts for saving.
In summary: the problem with find-file is that it promps user to enter
a file name upfront. The problem with switch-to-buffer is that it
doesn't promp to save when user closes it. In both, the functions are
simply not designed for creating a new temp buffer.
Xah
∑ http://xahlee.org/
☄
Xah Lee
> 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.
>
> wierd variable length quotes with dangling bits, make your message all
> but indecipherable.
you think? could it be that your criticial thinking and readings
skills are not mature enough?
Seriously.
I recommend you read some of my literature annotations on my website:
• The Tale Of The Bull And The Ass
http://xahlee.org/p/arabian_nights/an2.html
• The Tragedy Of Titus Andronicus
http://xahlee.org/p/titus/titus.html
• Politics and the English Language
http://xahlee.org/p/george_orwell_english.html
> Eli has one up on you there. English isn't his native language either,
> yet he manages to convey his ideas with style and panache.
you think?
> > I'm not sure ur a moron, but i wondered, because in my previous
> > message i specifically pointed out that please focus on main ideas.
> > You seem to me don't have much general education to sufficiently
> > understand the situation, but gave a retort about precision that is
> > typical of sophomorons.
>
> OK, back to the main point. It seems that `switch-to-buffer' (C-x b)
> does pretty much what you want.
The question is not about whether it “pretty much” does. Nor is it
about whether what i want.
The issue, is about a problem with emacs's “*scratch*” buffer, and how
the 2 alternative practical existing ways to create empty buffer each
are unfit for the purpose. I detailed them in my article:
http://xahlee.org/emacs/modernization_scratch_buffer.html
Please u peruse of it.
> Except you seem upset that when you do
> M-x kill-buffer, Emacs kills the buffer. I'd be unhappy if it didn't.
The issue is not about whether i'm upset. Nor is it about whether kill-
buffer not killing the buffer.
Please think.
> Actually, you'd be better typing C-x k. All you want, I think, is that
> Emacs should give you a warning when you're about to kill such a buffer.
Huh? what r u talking about?
> Why don't you implement this and post it up? It's not rocket science,
> and you do have a basic grasp of Emacs Lisp. You seem to expect that
> somebody else should do the work of implementing your ideas - that's
> just not the way things work. Implement it now - it should take more
> than an hour or two to modify C-x b - then we can try it out to see how
> good it actually is.
>
> > Fuck you.
>
> Xah, don't try to fuck - you're not very good at it. Write some Elisp
> instead.
The issue is not about fucking.
Please focuse on the issue if u are interested in discussing it.
Xah
∑ http://xahlee.org/
☄
Xah Lee
> It is necessary to have _some_ buffer when starting Emacs.
Not really. If you look at most apps, they provide either untitle or
empty page, and has user pref to set whether to do that or just have
nothing.
Even so, you don't need *scratch*. You can just have “untitled”.
> I don't know
> where you get your figure of 99% from.
It is a ballpark estimate. Sad to say, but my experiences tells me
that tech geekers (you being one good example), lack any basic
knowledge of social things that are generally classified under social
science. Maybe u too old to do so, but you might want to take a few
courses under social science heading in college, like history,
psychology, philosophy, letters. Or, u can read some text books n u
can buy them online at amazon.com or browse used books store. Esp the
older editions, are just few dollars.
To answer your question or help you think more specifically, you can
actually try to spend 1 hour thinking about this specific issue. Start
with, for example, how many people in the world actually code elisp.
What's the percentage with respect to programers. What's the
percentage with respect to all IT professionals. (look up definition
or ask a professor in social science department on what is meant by
“IT professional”) Also, think about what emacs is supposed to be, and
think about its relation to writers. Think about how many writers are
there in the world, what's their percentage with respect to, say,
programers.
Perhaps the concept of thinking for one hour on academic subject is
something you've never done. That's ok. I can suggest that instead of
just philosophizing on it, you could instead do a activity approach.
Try to go to library or online and find statistics about these issues.
Alternatively, if u have a lot money, you can pay research firms that
answer these questions for you. Typically, big corps like Microsoft
and Apple spend, i dunno, hundreds of thousands dollars on it yearly.
> Even when it is not used, it's
> not that big a nuisance.
To you, a emacs tech geeker, doesn't seems a nuisance. To your
grandma, or even most professional, or another tech geeker of the vi
faction, it stops them using emacs.
> > * The ?*scratch*? ?buffer? is primarily designed for elisp
> > programers. (it defaults to lisp mode) Majority of people who use
> > emacs are not lisp coders. For lisp coders, they can easily customize
> > their emacs to have a ?*scratch*? ?buffer?.
>
> It's designed for any rough notes, including bits of Lisp. The only
> thing here I found bothersome was having C-j bound to
> `eval-print-last-sexp', but I just rebound it to `newline-and-indent'.
>
> > * The ?*scratch*? ?buffer? is a intrusive idiosyncrasy. It is
> > persistent, cannot be closed (it regenerates). It is foreign to all
> > programers. This idiosyncrasy is the first thing presented to users,
> > and it persists.
>
> Have you considered coding an option so that this buffer would only be
> created when, at startup time, there was no other buffer? And coding
> another option so that when you killed it, it would stay killed? Write
> a patch, and submit it to emacs-de...@gnu.org. It might well be
> accepted for Emacs 23.
Please understand, the issue is not:
(1) whether i should write a patch,
(2) nor is it about writing a patch that do something you think is
better.
To illustrate (1), for example, suppose you say that fucking in the
ass is not moral and government should ban it. Then someone says why
don't you stop fucking in the ass yourself.
To illustrate (2), suppose you say that fucking in the ass should be
better done with lubes first. Then someone says why don't you try to
fuck in the ass with butter.
> [ .... ]
>
> > Proposed Fix
> > I propose that emacs should also add a menu command ?New buffer?, with
> > the keyboard shortcut ?Ctrl+n?. Once called, it should create a
> > scratch buffer titled ?untitled?. If one already exists, append
> > numbers such ?untitled 2?. Here are the reasons:
>
> As you know very well, there's already an important binding for C-n.
Yes, thanks. Yesterday, i have done more polishing on the article
( http://xahlee.org/emacs/modernization_scratch_buffer.html ) Among
the editing is a addition about the shortcut. Quote:
«Note: the proposed keybinding “Ctrl+n” and “Ctrl+w” need not be part
of this proposal because emacs already use “Ctrl+n” and “Ctrl+w” for
basic cursor movement and cut. However, it could be adapted in
conjunction with newly designed Ergonomic Keybinding. (see below)»
> > * The New command is a standard across Mac, Windows, Unix (Linux).
> > It is familiar to all software users.
>
> However, in Emacs, which uses many more key bindings than just about any
> other program, such a prime binding can't be spared for a command used
> only sporadically. Of course, anybody who wants to rebind it is welcome.
For keybinding issues on this, see the above paragraph.
> > * The Ctrl+n shortcut for New is standard and familiar to all
> > software users.
>
> That's not true. It's not familiar to me.
You are not a typical software user. You are a tech geek.
> > * A New Buffer command (where the corresponding elisp command name
> > might will be named new-empty-buffer), can supplant completely the
> > functionality of *scratch* buffer.
>
> This exists already: C-x b <new-name>. I suggest you hack
> `switch-to-buffer', possibly using advice at first, so that a C-u prefix
> would cause it to create this new buffer.
I suggest you enhance your critical thinking skills. You can start by
reading Wikipedia here:
http://en.wikipedia.org/wiki/Critical_thinking
> > * When users want to have a scratch buffer, he can create it by
> > simply pressing the shortcut, and when he doesn't want it, he can
> > simply close it with a standard keystroke Ctrl+w.
>
> <sigh>. Yet again, a prime binding like C-w can't be spared for such a
> minor command. As you know, C-w is bound to `kill-region'.
See above.
> > * By adopting the New Buffer and Ctrl+n, users can intuitively
> > create multiple scratch buffers for any purpose.
>
> Being able to create several *scratch*'es might well be useful.
Yes. Thank you.
> > * The name ?untitled? is conventional, far more widely understood,
> > and more general than ?scratch?.
>
> A mere unimportant trifle.
it's not umimportant trifle. Familiarity is important aspect of
software usability.
> > * For those who uses scratch buffer for elisp coding, she can set
> > the default mode for untitled buffer to emacs lisp mode.
>
> Or, more precisely, Lisp Interaction Mode.
you are right. Thanks for correction.
> But this option exists
> already: `initial-major-mode'.
Yes, but what's your point?
> > * Adopting the suggestion would fix several problems for those who
> > actually use emacs's scratch buffer. (1) emacs no longer mysteriously
> > respawn the ?*scratch*? buffer when user didn't want it. (2) user can
> > create multiple scratch buffers by just pressing a shortcut. (3) User
> > can close a scratch buffer and emacs will ask the user if she wants to
> > save it.
> > Draft Implementation
> > The above suggestion is experimentally implemented in my Ergonomic
> > Keyboard Shortcut Layout For Emacs.
>
> Just as a suggestion, this seems silly. Creating buffers has nothing to
> do with keyboard layouts. Why not separate out the functionality?
Thanks for your feedback.
I do not mean they should be the final form. That's why i said it's
experimental draft implementation. I started with elisp code for
ergonomic keybindings, then my studies lead me to find minor
improvements on text manipulating functions and other things such as
keybindings for common operations such as Open, Close, Save, and among
things is the discovery of emacs problems in creatig new empty buffer,
closing unsaved buffer with potential data lose, etc. Long story
short, it leads to a solution to the *scratch* and i have implemented
that doesn't have much to do with ergonomic keybindings.
You suggested few times about how i should code elisp in some way and
submit the patch. Perhaps, let me suggest to you, that you should try
to take what code i have, polish it, and start a discussion in emacs
dev lisp, and send the patch into GNU emacs.
Xah
∑ http://xahlee.org/
☄
Xah Lee
> On 2008-09-19, Xah Lee <x...@xahlee.org> wrote:
>
> > A: This attitude has plagued unix and computer geekers for decades. In
> > the early 1990s (DOS and unix), tech geekers would sneer at graphical
> > menus and mouse, with hordes of reasons how pure text interface, the
> > command line, and or keyboard operations are sufficient and superior
> > than graphical user interface or using a mouse. This seems ridiculous
> > today, but such voices are commonly seen all over newsgroups. (Since
>
> the reasons still stand and they are not ridiculous.
In argument, you can't just say something is ridiculous. You have to
give reasons.
Perhaps you think something is obvious. But in arguments, others might
think the opposite is obvious. That's why good argument needs explicit
reasons.
Xah
∑ http://xahlee.org/
☄
Cor Gest
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> The issue is not about fucking.
>
> Please focuse on the issue if u are interested in discussing it.
Right!
NOBODY is interested in discussion(for discussions sake),
unless it is accompanied by working code.
Chetan
I haven't followed this closely, but this seems to be back where this
started, although I am not sure if the original issue of "*Gnum Emacs*"
buffer got resolved. Actually, I didn't realize it existed until I ran
with -q. Presumably all this is meant for a newbie, so is it expected to
be bundled with CUA mode and enabled by default for a newbie?
Chetan
Allan Gottlieb
> David Kastrup <d...@gnu.org> writes:
>
>> tyler <tyler...@mail.mcgill.ca> writes:
>>
>>> Xah Lee <x...@xahlee.org> writes:
>>>
>>>> «I think the existance of the lisp scratch buffer is one of the major
>>>> usability problem of emacs that prevents emacs from being widely
>>>> adopted by most text editing audience.»
>>>
>>> Ironically, I just used the scratch buffer as the repository for the
>>> text of your previous message. rot13-region doesn't work in the
>>> read-only gnus buffers, so I needed to transfer it to a different
>>> buffer.
>>
>> C-c C-r works in gnus. Which does not mean that alternative ways are a
>> bad idea.
>
> That combination is not defined for me in gnus, but it did lead me to
> discover toggle-rot13-mode, which I *will* now bind to C-c C-r. Thanks!
What version of emacs are you using?
What happens if you are in a gnus summary buffer and type
C-h k C-c C-r
allan
Kevin Rodgers
> I don't agree that emacs does provide a user-level function for
> creating a new buffer. The 2 practical methods to create a new buffer,
> by find-file or switch-to-buffer, are both not designed to create a
> new buffer for temp use, and each has serious problems in my opinion.
>
> • There is no easy, intuitive way to create multiple scratch buffers.
> (it is done by using the switch-to-buffer command (C-x b) and give
> name that is not one of existing buffers.)
>
> • Emacs does not provide a user level function to create a new
> buffer. It has “Open file...” (a wrapper to the find-file command),
> which immediately prompt user for a full file path. This is annoying.
> Modern apps's New File command actually just create a new untitled
> file without prompting, and only when user save it it prompt a file
> name. If user closes it, it prompts for saving.
>
> In summary: the problem with find-file is that it promps user to enter
> a file name upfront. The problem with switch-to-buffer is that it
> doesn't promp to save when user closes it. In both, the functions are
> simply not designed for creating a new temp buffer.
Wow, if you had put 1% of the effort into coding that you put into this
thread, you could have come up with something like this:
(defun switch-to-new-buffer ()
"Switch to a new *scratch* buffer."
(interactive)
(switch-to-buffer (generate-new-buffer "*scratch*"))
(setq switch-to-new-buffer t))
If it's such a huge problem for 99% of users, you could propose to the
maintainers that it be added to files.el
--
Kevin Rodgers
Denver, Colorado, USA
Xah Lee
> XahLeewrote:
Thanks. But the issue is not about how to code a better switch-to-new-
buffer. The issue is about criticism of *scratch* buffer, and a
suggestion that emacs should remove it.
Please see:
http://en.wikipedia.org/wiki/Critical_thinking
If you didn't read the original article, please see:
Xah Lee
> Some entity, AKAXahLee<x...@xahlee.org>,
> wrote this mindboggling stuff:
> (selectively-snipped-or-not-p)
>
> > The issue is not about fucking.
>
> > Please focuse on the issue if u are interested in discussing it.
>
> Right!
>
> NOBODY is interested in discussion(for discussions sake),
> unless it is accompanied by working code.
Actually, people are interested in discussion, and in fact that's what
newsgroup is for.
Also, you seems to suggest that people should not criticize software
such criticism is not valuable, unless it is companied by code patches
that fixes it.
That is not true. In fact, successful software companies, from Open
Source ones such as GNU to commercial corps such as Apple and
Microsoft, highly value user feedback and criticism, and very actively
change their software due to criticisms.
Possibly you do not understand the meaning of criticism, or the
meaning of “constructive” criticism. I suggest the following articles:
http://en.wikipedia.org/wiki/Criticism
http://xahlee.org/UnixResource_dir/writ/criticism.html
plain text version follows
--------------------
Criticism versus Constructive Criticism
Xah Lee, 2003-01
A lot intelligent people are rather confused about criticism,
especially in our “free-speech” free-for-all internet age. When they
say “constructive criticisms are welcome” they mostly mean “bitching
and complaints not welcome”. Rarely do people actually mean that
“criticism without suggestion of possible solutions are not welcome”
or “impolite criticism not welcome”.
Such discernment is important. Wanton bitching as internet-using geeks
are used to is not criticism is any form.
People can be respected and make a living out of criticisms, called
critics, but not bitching. And when one really value opinions, you
often want criticism without qualifications. Just be happy that
valuable criticisms may come to you free from the experts in the
public. The instant you qualify what kind of feedback are welcome,
your feedback is compromised. (this is particularly so for political
or controversial subjects)
One easy way for many of the unix geekers to see this is the
cryptology industry.
If a person really desires valuable criticisms that are polite or with
solutions or “constructive” (whatever that means), one usually has to
pay.
Xah
∑ http://xahlee.org/
☄
Alan Mackenzie
On Fri, Sep 19, 2008 at 05:50:38PM -0700, Xah Lee wrote:
> On Sep 19, 1:36 pm, Alan Mackenzie <a...@colin2.muc.de> wrote:
> > It is necessary to have _some_ buffer when starting Emacs.
> Not really. If you look at most apps, they provide either untitle or
> empty page, and has user pref to set whether to do that or just have
> nothing.
There is no nothing. Something must appear on the screen, even if it's
only blank space. In Emacs, that something is a buffer, even if it's
empty. From a pragmatic point of view, to change Emacs to be able to
have no buffer would be a massive amount of work for negligible gain -
people use Emacs to edit things, not to look at nothing.
> Even so, you don't need *scratch*. You can just have ???untitled???.
I think all those question marks would confuse people. Anyhow, "scratch"
is easier and quicker to say. And in a niche market, a *scratch* is
what's wanted. ;-)
> > I don't know where you get your figure of 99% from.
> It is a ballpark estimate.
You mean a wild guess, based on nothing at all?
> Sad to say, but my experiences tells me that tech geekers (you being
> one good example), .....
Hey, thanks!
> lack any basic knowledge of social things that are generally classified
> under social science.
You might be surprised.
> To answer your question or help you think more specifically, you can
> actually try to spend 1 hour thinking about this specific issue. Start
> with, for example, how many people in the world actually code elisp.
> What's the percentage with respect to programers. What's the percentage
> with respect to all IT professionals. (look up definition or ask a
> professor in social science department on what is meant by ???IT
> professional???) Also, think about what emacs is supposed to be, and
> think about its relation to writers. Think about how many writers are
> there in the world, what's their percentage with respect to, say,
> programers.
Emacs is intended for programmers, though it's great that other sorts of
writers find it useful too.
> Perhaps the concept of thinking for one hour on academic subject is
> something you've never done.
Hahahaha! That's so funny it's not even an insult.
> > Even when it [the *scratch* buffer] is not used, it's not that big a
> > nuisance.
> To you, a emacs tech geeker, doesn't seems a nuisance. To your grandma,
> or even most professional, or another tech geeker of the vi faction, it
> stops them using emacs.
In the places I've worked, lots of people have asked me for help on their
Emacsen, but the question of getting rid of *scratch* hasn't come up even
once. How many people have you met in real life who've asked you to do
that? Xah, it really isn't a big deal.
[ .... ]
> > Have you considered coding an option so that this buffer would only
> > be created when, at startup time, there was no other buffer? And
> > coding another option so that when you killed it, it would stay
> > killed? Write a patch, and submit it to emacs-de...@gnu.org. It
> > might well be accepted for Emacs 23.
> Please understand, the issue is not:
> (1) whether i should write a patch,
> (2) nor is it about writing a patch that do something you think is
> better.
No, it's about writing a patch for something _you_ want.
> To illustrate (1), for example, suppose you say that fucking in the
> ass is not moral and government should ban it. Then someone says why
> don't you stop fucking in the ass yourself.
> To illustrate (2), suppose you say that fucking in the ass should be
> better done with lubes first. Then someone says why don't you try to
> fuck in the ass with butter.
Er, somebody elsewhere in the thread said the issue wasn't fucking, so in
deference to him, I won't answer this bit.
> > [ .... ]
> > > Proposed Fix
> > > I propose that emacs should also add a menu command ?New buffer?,
> > > with the keyboard shortcut ?Ctrl+n?. Once called, it should create
> > > a scratch buffer titled ?untitled?. If one already exists, append
> > > numbers such ?untitled 2?. Here are the reasons:
> Yes, thanks. Yesterday, i have done more polishing on the article
> ( http://xahlee.org/emacs/modernization_scratch_buffer.html )
I've had a wee look at it. You have at least one thing there which is
false, namely "Emacs does not provide a user level function to create a
new buffer". There is C-x b. You then go on to complain about having to
give a definite file name when you do C-x C-f to create a new file. It
seems to me that between these two commands you can get what you want
here.
> > > * The Ctrl+n shortcut for New is standard and familiar to all
> > > software users.
> > That's not true. It's not familiar to me.
> You are not a typical software user. You are a tech geek.
I am a software user. "All" means all without exception. What you wrote
has been refuted by counterexample. (Guess what I subject I graduated
in!) Take it as a free lesson in English. ;-)
> > > * By adopting the New Buffer and Ctrl+n, users can intuitively
> > > create multiple scratch buffers for any purpose.
> > Being able to create several *scratch*'es might well be useful.
> Yes. Thank you.
Taking another look at my .emacs, I see I've got M-n bound for this:
(define-key lisp-interaction-mode-map "\M-n" 'clone-buffer)
This is easy enough, apart from discovering that it's possible.
> > > * The name ?untitled? is conventional, far more widely understood,
> > > and more general than ?scratch?.
> > A mere unimportant trifle.
> it's not umimportant trifle. Familiarity is important aspect of
> software usability.
OK, let me put it this way. Of all the things which an Emacs newbie will
find unfamiliar, this is amongst the least important.
But "familiarity is [an] important aspect of ... usability". This is
confused thinking. Merely by using software, any software, you will
become familiar with it. This has no bearing on how usable the software
is. Emacs is supremely easy to use, and some programs (several popular
Microsoft programs, for example) remain ghastly to use, no matter how
familiar with them you become.
> > > * For those who uses scratch buffer for elisp coding, she can set
> > > the default mode for untitled buffer to emacs lisp mode.
> > Or, more precisely, Lisp Interaction Mode.
> you are right. Thanks for correction.
> > But this option exists
> > already: `initial-major-mode'.
> Yes, but what's your point?
You seemed to be arguing for a feature which already exists, suggesting
you were unaware of it. I was making sure you found out about it.
> Thanks for your feedback.
No problem!
> You suggested few times about how i should code elisp in some way and
> submit the patch. Perhaps, let me suggest to you, that you should try
> to take what code i have, polish it, and start a discussion in emacs
> dev lisp, and send the patch into GNU emacs.
OK, just stop right there. That's just not the way Emacs develpment
works. If you want to promote a new feature, you have to do the work
yourself. Even on the developers' mailing list, if you put an idea
forward, no matter who you are, nobody else is going to take it up and do
the work for you. You might ask people to criticise the idea in advance
(like you are doing at the moment) and incorporate their ideas. You then
implement the idea as a patch, and then ask people to try it out. Then
the real criticism starts. And that criticism can be robust indeed.
I'm afraid I won't be helping you with your code. I don't agree that
your suggestions are good ones. Even if I did, I still wouldn't be
offering the help you want, because I've got too many things of my own to
do. However, even though I don't like your changes, I do support your
right to promote them.
A small tip: using swear words doesn't help you get your message across.
It really doesn't.
Alan Mackenzie
One small but important point you made:
On Thu, Sep 18, 2008 at 04:50:50PM -0700, Xah Lee wrote:
> Here are few minor reasons:
> * When the scratch buffer is closed, emacs does not prompt user to
> save it. This easily causes data loss.
The other side of the argument is that *scratch* is intended for
temporary, unimportant doodling, and for anybody who uses it this way,
being continually prompted to save it would rapidly become annoying.
I don't think there's a built in option to change this. However, you
could write a hook function to add in this check. The hook is
`kill-buffer-query-functions' and is documented in the Elisp manual on
the page "Killing Buffers".
[ .... ]
> * modern_operations.el.
A small point about this file (at
<http://xahlee.org/emacs/modern_operations.el>): you don't really need
the function `kill-line-backwards', since M-0 C-k will do this for you.
However, that key binding is a bit clumsy. You could use it like this:
(defun kill-line-backwards ()
"Doc string ...."
(interactive)
(kill-line 0))
Nikolaj Schumacher
> On Sep 19, 9:13 am, Nikolaj Schumacher <m...@nschum.de> wrote:
>
>> We just call them (scratch) buffers. They provide all the
>> same featuresXah's"untitled files" do. Really, the only differences are
>> nomenclature, the way of creating them and the fact that one exists by
>> default.
>
> That's not the only differences. I have given detail on other
> differences.
Yes. Please note that the post you quoted was sent after my message, so
the other difference hadn't been made clear at that time.
> • There is no easy, intuitive way to create multiple scratch buffers.
> (it is done by using the switch-to-buffer command (C-x b) and give
> name that is not one of existing buffers.)
But on the other hand, creating multiple scratch buffers with names like
"untitled" through "untitledN" might not be in the users best interest.
I agree there should probably at least be a menu entry for "New buffer"
in the "Buffers" menu.
> • Emacs does not provide a user level function to create a new
> buffer. It has “Open file...” (a wrapper to the find-file command),
> which immediately prompt user for a full file path. This is annoying.
> Modern apps's New File command actually just create a new untitled
> file without prompting, and only when user save it it prompt a file
> name.
Well, not exclusively. For instance, Xcode prompts for the type of
file, then for the name.
You should note that apps that do this differently almost never call
this "New file". Because a file without a file name doesn't make sense.
Instead, they call this "New <document type>" or just "New". (At least
all the apps on my computer do.) So in the context of Emacs, the
correct name would probably be "New buffer".
> The problem with switch-to-buffer is that it doesn't promp to save
> when user closes it. In both, the functions are simply not designed
> for creating a new temp buffer.
Of course that depends on how you define "temp" buffer... I would avoid
that name for for what you're suggesting.
I /would/ like certain buffers to prompt before closing. You should add
autosaving to the mix, too. Sometimes I do too much actual work in the
scratch buffer, which is lost if Emacs crashes.
All this, however, is no reason to remove the scratch buffer. I can see
it defaulting to fundamental-mode, not having that message in it, and
prompting if modified and killed. But somehow I feel your proposed fix
doesn't fit your initial demand (removing the scratch buffer). The
scratch buffer itself isn't a usability problem. It's limitations are.
So, if anything, you're improving the scratch buffer not scrapping it.
regards,
Nikolaj Schumacher
Christian Herenz
> I think the existance of the lisp scratch buffer is one of the major
> usability problem of emacs that prevents emacs from being widely
> adopted by most text editing audience.
Hah... Having not read the whole conversation of this topic, I want to add an
experience I made last week. I was in the lab, and saw that a guy on the other
site worked inside an xemacs session. I asked him, why he puts everything in the
*scratch* buffer - and he looked at me and asked "buffer - scratch - sure you
are allright". I think that lots of emacs users today just use emacs as it where
notepad.exe or something like that, especially in scientifc environments some
people could boost their productivity, if they would at least know some of the
basics of the editor in the beginning of their career. When I told the guy: "Do
you know, that you can open more than one file at a time in emacs?" He asked me:
"Why the hell should I want to do that - I just open another emacs...".
Just a little story...
Greets,
Christian
Joost Kremers
> Xah schrieb:
>
>> I think the existance of the lisp scratch buffer is one of the major
>> usability problem of emacs that prevents emacs from being widely
>> adopted by most text editing audience.
personally, i find it unlikely that the *scratch* buffer has ever kept
anyone from adopting emacs. i also find it extremely unlikely that anyone
will be convinced to start using emacs when the *scratch* buffer is
ditched.
personally, i see emacs as a sophisticated tool for professionals. just as
i wouldn't buy a €10.000 SLR camera for the occasional holiday snapshot
i take, other people don't depend on an editor that much to (want to)
invest time in learning emacs.
> Hah... Having not read the whole conversation of this topic, I want to add an
> experience I made last week. I was in the lab, and saw that a guy on the other
> site worked inside an xemacs session. I asked him, why he puts everything in the
> *scratch* buffer - and he looked at me and asked "buffer - scratch - sure you
> are allright". I think that lots of emacs users today just use emacs as it where
> notepad.exe or something like that, especially in scientifc environments some
> people could boost their productivity, if they would at least know some of the
> basics of the editor in the beginning of their career. When I told the guy: "Do
> you know, that you can open more than one file at a time in emacs?" He asked me:
> "Why the hell should I want to do that - I just open another emacs...".
man... such people should simply be banned from using emacs ever again. ;-)
--
Joost Kremers joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Eric S Fraga
> On Sep 19, 8:32 am, Eric S Fraga <ucec...@ucl.ac.uk> wrote:
>> On 2008-09-19, Xah Lee <x...@xahlee.org> wrote:
>> > than graphical user interface or using a mouse. This seems ridiculous
>> > today, but such voices are commonly seen all over newsgroups. (Since
>>
>> the reasons still stand and they are not ridiculous.
>
> In argument, you can't just say something is ridiculous. You have to
> give reasons.
Excuse me? *You* said the reasons were ridiculous, not me. The
reasons are there, as you implied. Let me give you a couple:
1. RSI: I cannot use a mouse without pain.
2. speed: I type 60+ wpm, which is not particularly fast but results
in faster output than using the mouse, especially if the GUI is badly
designed (which applies to most graphical apps in my experience).
Others will have their own reasons and calling them ridiculous is
potentially insulting. If you prefer a graphical interface, fine. I
do not.
> Perhaps you think something is obvious. But in arguments, others might
> think the opposite is obvious. That's why good argument needs explicit
> reasons.
I agree; you said reasons had been given for text based interfaces.
You then said these were ridiculous and then failed to give any
reasons why. Maybe you should start listening to your own advice?
Just a friendly suggestion.
--
Eric S Fraga, UCL
Xah Lee
On the subject of RSI, perhaps you should use Dvorak, and you'd be
interested in my article here:
How To Avoid The Emacs Pinky Problem
http://xahlee.org/emacs/emacs_pinky.html
Text version follows:
-------------------------------------
How To Avoid The Emacs Pinky Problem
Xah Lee, 2006
Emacs makes frequent use of the control key. On a conventional
keyboard, the Control Key is at the lower left corner of the keyboard,
usually not very large and is pressed by the pinky finger. For those
who use emacs all day, this will result in repetitive strain injury↗.
This page lists some tips on avoiding this pinky problem.
I've been using computer since 1991, at least 8 hours a day on average
every singe day. I was a QWERTY touch-typist with 80 wpm and worked as
a secretary for about 2 years, then in ~1994 i switched to Dvorak. I
started to use emacs everyday since 1998. I am a keyboard and key
macro nerd, and have used tens of keyboard macro or keymap type of
utilities on the Mac, unixes, and Windows, always looking for the most
ergonomic and efficient way to operate the keyboard and computer. This
page summarize my experiences applied to emacs.
The best way to avoid the pinky problem is actually to use a good
keyboard. Let us start with some tips on choosing a good keyboard.
Tips For Selecting A Computer Keyboard
Here are some keyboard hardware advices:
• Buy a keyboard such that the Alt and Control keys are large.
• Buy a keyboard where Alt and Control are also available on the right
side.
• The Alt and Control key's positions on the left and right sides
should have the same distance to your left and right thumbs (while
your hands are rested in standard touch-type position). Specifically:
the distance from the left Alt to the F key should be the same as the
right Alt to the J key.
BAD
Apple keyboard
above: The Apple keyboard as of 2006. Note the ridiculous distance of
the right side's modifier keys. It is not possible, to use the right
thumb to press the alt key while the index finger remains on the J.
Many keyboards don't have full set of modifier keys on the right side,
and when they do, they are positioned far to the right, making them
not much usable for touch typing. For example, the keyboards made by
Apple Computer, their right-side Command/Alt/Ctrl keys are inferior
citizens. They are placed far more to the right, making the right set
of modifier keys difficult or impossible to reach with the thumb. It
makes these keys essentially decorative in nature. (Apple did this to
make the keys flush at the lower right corner; sacrificing function
for esthetics.).
GOOD
Microsoft Natural Multimedia keyboard
above: The Microsoft Natural Multimedia keyboard. Note, the keys are
split and oriented for each hand. And, the Ctrl, Alt are very large
and symmetrically positioned with respect to each hand's thumb. (See A
Review of Microsoft Natural Keyboards)
For more extensive commentary on various computer keyboards and
design, see: Computer keyboards Gallery.
How To Press The Control Key
Use Your Palm or Semi-Fist
Do not use your pinky to press the Control key.
For most PC keyboards, it is very easy to press the control key using
your palm. Just open your hand somewhat and push down with the meat at
the chopping edge of your hand. Alternatively, you can roll your wrist
a bit, curl in your fingers into a semi-fist, then sit your fist on
the control key.
Use Both Hands
Do not use a just one hand to type a Control+‹key› combo.
Use one hand to press Control, use the other hand to press the
combination key. This is the same principle for pressing the Shift key
in touch-typing.
When the key you want to press is on the left side of the keyboard,
use the right side of Control key. For example, to press “Ctrl+a”,
hold down the right Control with your right palm edge, and use your
left hand to press “a”. Make this into a habit. Using a single hand to
press “Ctrl+‹key›” combo usually means your hand needs to cram into a
particular shape, thus putting stress on it when done repeatedly.
This is also why choosing a keyboard with Control keys positioned on
both sides of the keyboard symmetrically, is important.
Software Ways To Avoid the Pinky Problem
A good keyboard and good typing habit is good. But suppose you are
stuck with a lousy keyboard or your notebook computer. A notebook
computer usually don't have control key on both sides of the keyboard.
Its control key is very small, and it cannot be pressed by palm. Here
are some suggestions for this situation.
Swap Control and Alt
Try swapping the Control and Alt keys.
Emacs's are developed for Lisp Machine's keyboards of the 1980s, which
have the Control key near the space bar, and the Meta key further away
from the space bar. So, Control key is the primary modifier key.
However, today's keyboards have Alt instead of Meta, and the Control
key is placed at the far corner instead. Emacs did not change its
shortcuts. It simply mapped the Meta to Alt. That is why today, most
frequently used keyboard shortcuts have the more difficult to press
Control key instead of the Alt. For more detail on this and other
aspects of emacs's shortcuts, see: Why Emacs's Keyboard Shortcuts Are
Painful.
By switching the Alt and Control key, will make Emacs's keyboard
shortcuts much easier to use as it was designed.
The other advantage of swapping Alt and Control, is that on Windows
and Linuxes, most direct shortcuts involve the Ctrl key. By swapping,
Windows shortcuts are made easier since now Control is right under
your thumb. On the Mac, shortcuts are made with the Cmd key. If you
swap Control with Cmd, the primary modifier Cmd will be at the corner,
thus make it more difficult to use all other applications. The best
thing to do on the Mac is to swap Control and Cmd only in Emacs. I do
not know if it is possible to swap Ctrl and Alt within emacs.
For system-wide swap of modifier keys on OS X, see: How to Swap
Modifier Keys on OS X.
Swap Cap Lock and Control
Another commonly suggested solution is to remap the the Cap Lock and
Control key by swapping them. This is not a optimal solution, because
the Control key is still pressed by the pinky, and somewhat displaces
your hand on home position. Also, there is now only one Control key,
making the left pinky doing double work. (modifier keys comes in pairs
for good reasons. Try pick out a Shift key and type for a week)
However, if you are stuck on a lousy keyboard such as laptops, and
unable to swap Ctrl and Alt, then making the Cap Lock key as Control
might be a practical solution.
For detail, see: Why You Should Not Swap Cap Lock With Control.
It is not possible to swap cap locks and control key within emacs,
because the cap-lock key signal is not received by applications.
However, you can do it with several system utilities. In unix-like
systems, this is done with xmodmap. See Emacs wiki: moving the Ctrl
key↗.
Use a Ergonomic Shortcut Layout
If you are adventurous, the best solution is to use a ergonomically
designed shortcut layout for emacs.
See: A Ergonomic Keyboard Shortcut Layout For Emacs.
Dvorak Keyboard Layout
Perhaps a more important ergonomic improvement one can make is by
using the Dvorak keyboard layout.
dvorak keyboard layout
I've been using Dvorak keyboard since 1994. It works beautifully with
emacs. It makes typing more comfortable. (i use emacs since 1997). If
you use unix/X11, you can switch to dvorak by running
dvorakKeymap.txt. On Mac OS X, use “System Preference: International”.
On Windows XP, go to “Control Panel:Regional and Language Options”.
For more info about Dvorak layout, see Wikipedia: Dvorak Simplified
Keyboard↗.
A web comics introducing Dvorak: http://www.dvzine.org/zine/index.html
A video game: The Typing of the Dead↗.
Xah
∑ http://xahlee.org/
☄
On Sep 22, 1:25 am, Eric S Fraga <ucec...@eeepc.chemeng.ucl.ac.uk>
wrote:
> On 2008-09-20,XahLee<x...@xahlee.org> wrote:
>
> > On Sep 19, 8:32 am, Eric S Fraga <ucec...@ucl.ac.uk> wrote:
Lennart Borgman (gmail)
> Hi Erik Fragga,
>
> On the subject of RSI, perhaps you should use Dvorak, and you'd be
> interested in my article here:
>
> How To Avoid The Emacs Pinky Problem
> http://xahlee.org/emacs/emacs_pinky.html
Xah, it is good that you try to help people with this, but why don't you
mention sticky keys:
http://www.emacswiki.org/cgi-bin/wiki/StickyModifiers
On the bottom of that page is also a link to Alex Schröder's comment
about physical fitness and RSI. I very much agree with Alex conclusion.
Xah Lee
> 'Morning,Xah!
>
> On Fri, Sep 19, 2008 at 05:50:38PM -0700,XahLeewrote:
> > On Sep 19, 1:36 pm, Alan Mackenzie <a...@colin2.muc.de> wrote:
> > > It is necessary to have _some_ buffer when starting Emacs.
> > Not really. If you look at most apps, they provide either untitle or
> > empty page, and has user pref to set whether to do that or just have
> > nothing.
>
> There is no nothing. Something must appear on the screen, even if it's
> only blank space. In Emacs, that something is a buffer, even if it's
> empty. From a pragmatic point of view, to change Emacs to be able to
> have no buffer would be a massive amount of work for negligible gain -
> people use Emacs to edit things, not to look at nothing.
many apps, including most browsers and text editor, can start without
a window present. (on the Mac)
In fact, i think that's most apps behave on the Mac these days. (as
opposed to must having a window present. (on Windows, this is somewhat
irrelavent since each app are often in its own window with menu bar))
In AquaMacs for example, you can close all buffers, windows, frames,
without quiting the app.
> > Even so, you don't need *scratch*. You can just have ???untitled???.
>
> I think all those question marks would confuse people.
Why do u keep using a broken newsreader that don't understand unicode
and insist about the issue? C'mon.
> > > I don't know where you get your figure of 99% from.
> > It is a ballpark estimate.
>
> You mean a wild guess, based on nothing at all?
Lol. Alan, do u really live in a cave or what?
I've always found emacs developers or lisp coders to be weird cave
dwellers who bury their head in their perspective tech and have little
understanding of software industry and professional programers.
I started using emacs daily since 1998. I only started learning elisp
in 2006. I have actually actively resisted in learning elisp, because
of fear of falling into a blackhole of code diddling of little
significance. Too bad, i have now since fallen into this hole. After
all, i haven't had a day job since about 2004.
it's quite bizzar when you hear some of the lispers. When's the last
time you saw the sun, Alan?
> > Sad to say, but my experiences tells me that tech geekers (you being
> > one good example), .....
>
> Hey, thanks!
>
> > lack any basic knowledge of social things that are generally classified
> > under social science.
>
> You might be surprised.
>
> > To answer your question or help you think more specifically, you can
> > actually try to spend 1 hour thinking about this specific issue. Start
> > with, for example, how many people in the world actually code elisp.
> > What's the percentage with respect to programers. What's the percentage
> > with respect to all IT professionals. (look up definition or ask a
> > professor in social science department on what is meant by ???IT
> > professional???) Also, think about what emacs is supposed to be, and
> > think about its relation to writers. Think about how many writers are
> > there in the world, what's their percentage with respect to, say,
> > programers.
>
> Emacs is intended for programmers, though it's great that other sorts of
> writers find it useful too.
That sentiment is rather silly to meaningless.
Sometimes in other context, you see emacs fanatics insist that emacs
is the best tool for non-programing text editing, period. In fact, you
see a few heads popping up here now and then saying how great they
love emacs and they are not programers but writers.
In other times, like now, you see emacs hotheads insists that emacs is
more for programers and programers primarily, to the degree that if
they don't know much about program, perhaps they should goto Microsoft
Word, and about how emacs “should not dumb down for these people”.
Execuse my French, but when i discusses these issues, it gets me angry
over the degree of their FANTASTICAL STUPIDITY.
So Alan, what does it really mean, to say that “Emacs is intended for
programmers, though it's great that other sorts of writers find it
useful too.”? What does it signify? Does it imply anything? Does it
actually mean anything other than a sentimental catch phrase to
express certain love of emacs??
actually.... i do know exactly what's on your mind. I can write say a
2 thousand words article on emacs that is 100% of how you feel, how
you see things, what you know about it. Cause i understand tech
geekers far too well.
> > Perhaps the concept of thinking for one hour on academic subject is
> > something you've never done.
>
> Hahahaha! That's so funny it's not even an insult.
>
> > > Even when it [the *scratch* buffer] is not used, it's not that big a
> > > nuisance.
> > To you, a emacs tech geeker, doesn't seems a nuisance. To your grandma,
> > or even most professional, or another tech geeker of the vi faction, it
> > stops them using emacs.
>
> In the places I've worked, lots of people have asked me for help on their
> Emacsen, but the question of getting rid of *scratch* hasn't come up even
> once. How many people have you met in real life who've asked you to do
> that? Xah, it really isn't a big deal.
most people simply stopped using emacs. See:
Text Editors Popularity
http://xahlee.org/emacs/text_editor_trends.html
plain text version follows:
∑ Back to Emacs Tutorial.
Text Editors Popularity
Xah Lee, 2007-08
This page shows the popularity of programer's text editors and IDEs.
The following lists them in order of popularity as of 2007-08.
1. (Microsoft Word↗)
2. Microsoft Visual Studio↗
3. emacs↗, Vim↗
4. Notepad++↗
5. Xcode↗
6. Textmate↗
7. Eclipse IDE↗
8. (Wordpad↗)
9. JEdit↗
10. BBEdit↗, Notepad2↗
11. NEdit↗
12. (TextEdit↗)
The ranking is based on Google Trends↗. This is not be a very accurate
measurement of user base, but gives a rough indication.
Those in parenthesis are text editors not used for programing, but
included here just to give a context, and a sense of the relative
ranking by Google Trend.
Ideally, i'd like to list all programer's text editors and IDEs, by
the number of users. (and limiting the entries to 10 or so)
Preferably, also show the data by a graph so that we can see the
relative gap between ajacent entries. (for example, when shown as a
pie chart, Microsoft Word and Visual Studio together might be 90%,
while all the rest is just 10%)
I haven't done much research on what IDEs are common on the Windows
platform. (Never developed for MS technologies) So if you work in the
Windows platform and knew some of the commonly used IDEs or editors,
please let me know.
Among the above list, some editor should be there but for one reason
or another i wasn't able to use Google Trends to get some sensible
statistics are: Microsoft Notepad↗, Programmer's Notepad↗, Borland
Delphi↗, Kate (text editor)↗, GEdit, roughly same popularity as Nedit
according to google trends, but it doesn't have Wikipedia entry!
Also note: Google trends has records back to about 2004. This
conveniently marks the beginning year to be considered on this list.
Personally, i've been using Mac in about 1991. Many IDEs on the mac
has come and gone. From roughly 1990 to 2002, the following are the
major editor/platform used on the Mac, each basically replaced the
previous one chronologically: Macintosh Programmer's Workshop↗, THINK
C↗, CodeWarrior↗, SimpleText↗. But since the arrival of OS X,
CodeWarrior and SimpleText went extinct primarily due to the platform
change and arrival of XCode and TextEdit. Also, BBEdit is widely
popular throughout the 1990s, but its user base gradually declined
with the arrival of OS X↗ in 2001.
Who Cares?
We all have heard “vi vs emacs” a million times, and have participated
in brawls and polls about which editors are the best. Although, these
are almost always carried out in a facetious fashion among tech
people, without any hint about the social importance of these kind of
questions.
Statistics such as market share, is broadly speaking part of the info
and activity of demographics and market research. Such information is
very important in decision making, and corporations will often spend
tens of thousand dollars to research or buy the info. (there are a
entire market of business dedicated to market research) For example, a
corporation will need to know its market share to make decisions on
marketing budget, development budget, pricing decision, corporate
buyout negotiation, down to the technical details of a feature design.
Good and bad directional decisions can mean success and extinction.
(For more on this, see Wikipedia Market research↗. )
Non-commercial software such as emacs, isn't dependent on paying
customers nor driven by financial investors, so many market questions
are moot. (since in a sense nobody really could care if a particular
free software went exinct for lack of users, and thousands of
OpenSource or FreeSoftware big and small come and went all the time
without a beep.) However, getting users and getting info about users
is still a important aspect in understanding and for improving our
software, because we like emacs and want our time investment into it
survive. (put it in another way, we don't want to have to be forced to
switch to vi due to emacs dilapidation and oblivion.)
In our OpenSource or Freedom software world, competition such as emacs
vs xemacs vs vi, or GNOME vs KDE, etc, isn't about cutting-throat or
bankruptcy or loosing our daily bread and butter, but it is still a
valid competition, similar to sports and games.
As a example of importance of the info about market share of editors,
consider emacs advocates and Free Software Foundation (emacs
developers), in their consideration of modernization of Emacs. If
emacs is used by majority of professional programers (defined as those
who makes a living primarily by coding), then perhaps it is not so
important to changes emacs to conform to modern UI. But if data
indicates that, say, the combined users emacs and vi is less than 10%
of the programing population, then the modernization of emacs issue
warrants much more weight.
--------------------------
little usability issues addds up. You say *scratch* is little problem,
but then emacs uses non-standard terminology (buffer, yank, kill-ring-
save, window/frame, ... etc), non-standard UI (minibuffer instead of
popup dialog...etc), non-standard keyboard shortcuts, and etc etc too
many to list. You basically end up with a system that is just too
foreign, and difficult to learn is one primary complaint of emacs.
there are many reasons why emacs is the way it is, and many reasons
that many emacs ways are superior and operatively more efficient. We
need to exam on the whole, all thing considered, and improve those
problematic or of little utility and or a simple solution that can
work.
I think my criticism and proposed fix on the *scratch* buffer problem
is quite simple and effective...
on hindsight of this thread of all things already been said ...
perhaps give it another scan?
http://xahlee.org/emacs/modernization_scratch_buffer.html
> [ .... ]
>
> > > Have you considered coding an option so that this buffer would only
> > > be created when, at startup time, there was no other buffer? And
> > > coding another option so that when you killed it, it would stay
> > > killed? Write a patch, and submit it to emacs-de...@gnu.org. It
> > > might well be accepted for Emacs 23.
> > Please understand, the issue is not:
> > (1) whether i should write a patch,
> > (2) nor is it about writing a patch that do something you think is
> > better.
>
> No, it's about writing a patch for something _you_ want.
in commercial software, it's not about something you want. It's about
what makes money, and that is determined by how people actually want
to pull money out of their pocket. In order to achieve that, is about
what's really best, that people want.
Successful software corps, such as Apple, Microsoft, IBM, google, etc
roughly did that. You don't become successful by breaking the law as
most tech geekers likes to think of Microsoft.
In Open Source software, it's largly driven by the need of a few
coders. Emacs came to be largely because that's what Richard Stallman
needs in the 1980s. He has ceased being a coder who actively work in
the industry since maybe 1990s. ...
... am not going to write another thousands word article and surely
followed by wild discussion on this ... maybe you see some of my
points.
> > To illustrate (1), for example, suppose you say that fucking in the
> > ass is not moral and government should ban it. Then someone says why
> > don't you stop fucking in the ass yourself.
> > To illustrate (2), suppose you say that fucking in the ass should be
> > better done with lubes first. Then someone says why don't you try to
> > fuck in the ass with butter.
>
> Er, somebody elsewhere in the thread said the issue wasn't fucking, so in
> deference to him, I won't answer this bit.
>
> > > [ .... ]
> > > > Proposed Fix
> > > > I propose that emacs should also add a menu command ?New buffer?,
> > > > with the keyboard shortcut ?Ctrl+n?. Once called, it should create
> > > > a scratch buffer titled ?untitled?. If one already exists, append
> > > > numbers such ?untitled 2?. Here are the reasons:
> > Yes, thanks. Yesterday, i have done more polishing on the article
> > (http://xahlee.org/emacs/modernization_scratch_buffer.html)
>
> I've had a wee look at it. You have at least one thing there which is
> false, namely "Emacs does not provide a user level function to create a
> new buffer". There is C-x b. You then go on to complain about having to
> give a definite file name when you do C-x C-f to create a new file. It
> seems to me that between these two commands you can get what you want
> here.
I have given reasons why C-x b is unfit for creating a temp buffer. To
begin, the name is switch-to-buffer. Also, emacs doesnt offer to save
a buffer not associated with file, so you have potential data lose...
I also give reason why C-x C-f is unfit, because it prompt for a file
name... in fact i listed these two ways in my article originally.
Given my article, i do not see any new point or argument against what
i said already.
Please, do read my article with a open mind. I am effectively
repeating my article for each reply in this now 50 messages thread.
> > > > * The Ctrl+n shortcut for New is standard and familiar to all
> > > > software users.
> > > That's not true. It's not familiar to me.
> > You are not a typical software user. You are a tech geek.
>
> I am a software user. "All" means all without exception. What you wrote
> has been refuted by counterexample. (Guess what I subject I graduated
> in!) Take it as a free lesson in English. ;-)
it would be ridiculous to say that you are not familiar with Ctrl+n.
Try to put that on your resume. Like this: “I, Alan, although am a
tech geek, but i don't know what Ctrl+n” is in today's software.
Please do hire me though.”
LOL. How silly can tech geekers get? Really? How utterly bizarre and
silly can they get? Alan, you “are not familiar with Ctrl+n” eh?
> > > > * By adopting the New Buffer and Ctrl+n, users can intuitively
> > > > create multiple scratch buffers for any purpose.
> > > Being able to create several *scratch*'es might well be useful.
> > Yes. Thank you.
>
> Taking another look at my .emacs, I see I've got M-n bound for this:
>
> (define-key lisp-interaction-mode-map "\M-n" 'clone-buffer)
>
> This is easy enough, apart from discovering that it's possible.
huh? are you saying that clone-buffer is a good way to create a new
buffer?
> > > > * The name ?untitled? is conventional, far more widely understood,
> > > > and more general than ?scratch?.
> > > A mere unimportant trifle.
> > it's not umimportant trifle. Familiarity is important aspect of
> > software usability.
>
> OK, let me put it this way. Of all the things which an Emacs newbie will
> find unfamiliar, this is amongst the least important.
As i mentioned, little oddities here and there adds up. See above.
> But "familiarity is [an] important aspect of ... usability". This is
> confused thinking. Merely by using software, any software, you will
> become familiar with it. This has no bearing on how usable the software
> is. Emacs is supremely easy to use, and some programs (several popular
> Microsoft programs, for example) remain ghastly to use, no matter how
> familiar with them you become.
Sorry if i sound rude, but what you said, your attitude, your
sentiment, your feelings about software user interface, typical of
tech geekers, are the most motherfucking, baseless, stupid.
Fantastically stupid. Moronic. Flat earth.
Step outside of your cave. Go ask a librarian, or someone in Apple or
Microsoft who works or research on UI, or even try to consult academic
professors...
> > > > * For those who uses scratch buffer for elisp coding, she can set
> > > > the default mode for untitled buffer to emacs lisp mode.
> > > Or, more precisely, Lisp Interaction Mode.
> > you are right. Thanks for correction.
> > > But this option exists
> > > already: `initial-major-mode'.
> > Yes, but what's your point?
>
> You seemed to be arguing for a feature which already exists, suggesting
> you were unaware of it. I was making sure you found out about it.
>
> > Thanks for your feedback.
>
> No problem!
>
> > You suggested few times about how i should code elisp in some way and
> > submit the patch. Perhaps, let me suggest to you, that you should try
> > to take what code i have, polish it, and start a discussion in emacs
> > dev lisp, and send the patch into GNU emacs.
>
> OK, just stop right there. That's just not the way Emacs develpment
> works. If you want to promote a new feature, you have to do the work
> yourself. Even on the developers' mailing list, if you put an idea
> forward, no matter who you are, nobody else is going to take it up and do
> the work for you. You might ask people to criticise the idea in advance
> (like you are doing at the moment) and incorporate their ideas. You then
> implement the idea as a patch, and then ask people to try it out. Then
> the real criticism starts. And that criticism can be robust indeed.
... here we venture into the problem of Open Source... see above i
already give some pointers on the issue. In commercial softs, you have
a goal, and how your app will be are based on facts and professional
experts works on it with their daily bread at stake. In Open Source,
joe moron has the final word, or else, start your own!
It is not a wonder, most Open Source software for the desktop users
don't have any foothold on the market, even though $free$ as cig given
to children.
This does not mean open source softs has to be stupid. Little
thinking, little suggestion, and a whole lot of copying of commercial
apps helps (such as linuxes copying almost entire Microsoft Window
UI). Emacs copied a whole lot from the commercial Xemacs (Lucid Emacs)
from about 1990 to 2004. Open source softs do improve slowly (e.g. CUA
mode).
you want emacs to improve? think more, and get away from tech geeker
mindset. Go to college and study more about humanities. Your thoughts
on software will improve far more than decades of tech geeking and
slashdot.
> I'm afraid I won't be helping you with your code. I don't agree that
> your suggestions are good ones. Even if I did, I still wouldn't be
> offering the help you want, because I've got too many things of my own to
> do. However, even though I don't like your changes, I do support your
> right to promote them.
>
> A small tip: using swear words doesn't help you get your message across.
> It really doesn't.
That depends. In fact, a lot people swore or worse, and they made a
change... e.g. recently i learned of:
http://en.wikipedia.org/wiki/Lenny_Bruce
http://en.wikipedia.org/wiki/George_Carlin
... and see also
http://xahlee.org/Periodic_dosage_dir/lacru/crumb.html
http://xahlee.org/Periodic_dosage_dir/lacru/goya.html
http://xahlee.org/Periodic_dosage_dir/lacru/odalisque.html
... we could go on and discuss the history of swearing and impact on
society, or exam the world's culture and attitude about swearing, or
the psychology of swearing, swearing in modern society, the history of
swearing tolerance ... i think we'd have a ball.
also note, swearing is sometimes the most effective way of expression.
For example, if someone bugs you and you just burst out “fuck off”,
that says a lot, and would avoid potential damage to all parties ...
and, of course, if your aspiration is to be a political leader, than
swearing in public is often bad ... in some sense, it is about a
image, a diplomacy, or in some tech geeker way of thinking, it's about
lying and smiling.
Smile!
Ok, quickly typed out n no time to edit.
Xah
∑ http://xahlee.org/
☄
Xah Lee
Xah Lee
<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/
☄
Lennart Borgman (gmail)
> On Sep 22, 5:16 am, "Lennart Borgman (gmail)"
>> 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 ...).
Nikolaj Schumacher
> 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
Sean Sieger
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.
Xah Lee
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/
☄
Xah Lee
> 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
> 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/
☄
Ted Zlatanov
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
Alan Mackenzie
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.
[ .... ]
Eric S Fraga
> 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...
David Kastrup
> 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
Xah Lee
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/
☄
Xah Lee
<lennart.borg...@gmail.com> wrote:
> XahLeewrote:
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/
☄
Xah Lee
> 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/
☄
Eric S Fraga
> 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.
>
> 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
Xah Lee
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/
☄
Lennart Borgman (gmail)
> On Sep 22, 7:50 am, "Lennart Borgman (gmail)"
>>
>> 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.
Xah Lee
On Sep 23, 8:47 am, "Lennart Borgman (gmail)"
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/
☄
Lennart Borgman (gmail)
> 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/
>
> ☄
>
>
Xah Lee
<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/
☄
Lennart Borgman (gmail)
Maybe. But I am an optimist. You have some logical elements in your
thinking after all.
Michael Ekstrand
> 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.
Nikolaj Schumacher
> 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
Nikolaj Schumacher
> 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
harven
> 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
Xah Lee
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/
☄
Xah Lee
> 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/
☄
Xah Lee
> 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/
☄
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
Kevin Rodgers
> 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
Kevin Rodgers
> 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))
^^^^^^^^^^^^^^^^^^^^
>> 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.
Eric S Fraga
>> 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.
Xah Lee
> Kevin Rodgers wrote:
> >XahLeewrote:
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/
☄
Nikolaj Schumacher
> 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
Xah Lee
> 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/
☄
Giorgos Keramidas
> 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.
Giorgos Keramidas
>On 2008-09-24, Xah Lee <x...@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) :-)
Alan Mackenzie
On Tue, Sep 23, 2008 at 12:36:38AM +0200, David Kastrup wrote:
> Alan Mackenzie <a...@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).
Xah Lee
> 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/
☄
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 <uce...@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
rustom
> 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...
Andreas Politz
> 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 <uce...@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
Xah Lee
wrote:
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/
☄
Xah Lee
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/
☄
Juanma Barranquero
> 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
Juanma Barranquero
> 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
Xah Lee
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/
☄