From: Xah <xahlee@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: How to get rid of *GNU Emacs* buffer on start-up?
Date: Fri, 26 Sep 2008 06:28:03 -0700 (PDT) [thread overview]
Message-ID: <3c61c357-0705-4ff4-b793-fa6827415fdd@n38g2000prl.googlegroups.com> (raw)
In-Reply-To: mailman.19978.1222407641.18990.help-gnu-emacs@gnu.org
Kevin Rodgers wrote:
> > «
> > * There is no easy, intuitive way to create multiple scratch
> > buffers. (it is done by using the switch-to-buffer command (C-x b) and
> > give name that is not one of existing buffers.)
>
> We'll have to disagree: I think that is both easy and intuitive.
What seems to you intuitive is not intuitive to the general text
editing audience. The text editing audience is broad, including all IT
professionals, those in academics. Many of these people, wouldn't have
clude if you ask them to define variable or algorithm or byte. Perhaps
you are thinking these people are stupid. Perhaps when compared to you
as a tech geeker, they are quite ignorant about computers. But the
world is big, there are all walks of life. Many of them are in fact
scientists, engineers, mathematicians, lawers. You wouldn't know shit
if i ask you some elementary math concepts (trust me). Similarly, you
don't know the most elementary thing about laws, engineering, ... all
all sort of fields. One element of User Interface design is that the
user don't have to learn anything in order to use it, as much as
possible.
Emacs has too many unusual ways... (btw, i'm damn repeating myself
again and again and again here... in this thread i've already wrote
paragraph(s) that details this).
Please, have a open mind. Open mind is not easy, you really have to
put effort into it.
For example, let me ask this: have you ever, actually try to look into
the knowledge of User Interface? What it entails? What academic field
in involves? Have you actually read a text book on it? Whats the
latest research on it? Who are the dignitaries in the research? What
are the common, standard, or well known reference for UI?
again i'm repeating, and you may think i sound like ergomaniac, or you
might think i'm bullshitting ... but the opinions expressed here by
tech geekers are really completely ignorant. Ask any UI expert,
researcher, they'll laugh.
The things i say, just about every aspect of this thread's argument,
can be reasonably verified, acertined. But you guys didn't even go up
to the level of question about verification, such as how can we
carried out, etc. You you guys are saying, basically at the level of
“emacs is not Microsoft and emacs should not dumb down”!!
> > * When the scratch buffer is closed, emacs does not prompt user to
> > save it. This easily causes data loss.
>
> What part of the initial contents of the *scratch* buffer is not clear:
>
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
See above. One element of software UI design is that it should keep it
to minimal for users having to spend time learning things that is not
directly relevant to her tasks.
> > * A scratch pad can be very useful not just for temporary elisp
> > code but for any scratch notes or programing in other languages. (For
> > example, well known programer Stevey Yegg in his popular Effective
> > Emacs↗ blog list it as a top 10 tip in emacs productivity.) Emacs's
> > “*scratch*” buffer is narrowly geared for elisp editing only,
> > defaulting to emacs-lisp-mode.
>
> So set initial-major-mode to your favorite text or programming language
> mode. Mine is emacs-lisp-mode.
Again, the discussion, criticism, is not about “Hi guys, do you know a
way so that i can do xyz in emacs?”. It is not about how one
individual can customize emacs to some way.
I have written this again and again... Please see:
http://xahlee.org/emacs/modernization.html
the faq setion, i quote:
Q: Why don't you make these changes yourself? It is easy.
A: The issue is not about individual's convenience. Let's say you
lobby for greener planet. Then somebody retorts: “why don't you just
plant more trees in your backyard?”.
When i wrote this paragraph:
« * A scratch pad can be very useful not just for temporary elisp
code but for any scratch notes or programing in other languages. (For
example, well known programer Stevey Yegg in his popular Effective
Emacs↗ blog list it as a top 10 tip in emacs productivity.) Emacs's
“*scratch*” buffer is narrowly geared for elisp editing only,
defaulting to emacs-lisp-mode.»
It is one of the items that details a problem of *scratch*, in support
of my proposal. It is not about “how can i, Xah Lee, set emacs so that
the *scratch* buffer start in xyz mode”.
No disrespect, but please perhaps take a course in college about
critical thinking or philosophy:
http://en.wikipedia.org/wiki/Critical_thinking
-----------------------
> > * Emacs does not provide a user level function to create a new
> > buffer. It has menu “File‣Open file...” (a wrapper to the find-file
> > command), which immediately prompt user for a full file path. This is
> > annoying. Modern apps's New File command actually just create a new
> > untitled file without prompting, and only when user save it it prompt
> > a file name. If user closes it, it prompts for saving.
> > »
>
> Agreed. I think you should lobby the Emacs maintainers to include
> something like the switch-to-new-buffer command I proposed. But it
> does need to be enhanced to prompt for saving when it is killed.
You can help me with it, by filing a bug report on the *scratch*
buffer, borrowing whatever part in my article you think you agree, or
perhaps completely on your own reasons.
As you perhaps know, i've had quite few heated arguments here. This
thread is now 120 messages going to the level of “fuck you's”. About 3
or 4 similar threads on other emacs issues has happend in the past 2
or 3 monhs.
I'm not getting paid to debate. The several items in emacs
modernization proposals doesn't benefit me directly in any way, and it
is not likly to be incorporated into emacs anytime soon.
Instead of suggesting me to do something, why don't you do something
about it? I'm not trying to be rude, and i very much appreciate your
argument here, one of the 3 or 4 in this thread that actually are
sincere and has content, in my opinion.
> So: Don't use switch-to-buffer. Use something else. Lobby the
> Emacs maintainers to include that something else. Argue the case
> for that something else based on your actual usage, not speculation
> about what makes Emacs easy/hard/intuitive/nonintuitive for others.
See above.
Also, i have already wrote detailed articles on several aspects of
modernization. Totaly word count is probably over 20 tousand now. For
example, starting with this link:
http://xahlee.org/emacs/modernization.html
it links to other articles that give support or more detail, some part
even include patch.
So, i don't mean this to be directed at you, but for once, instead of
being argumentative and telling me what i should and should not do,
perhaps you can look at my proposals earnestly, pick out whatver part
you think are valuable, file a bug report or start a discussion in
emacs dev list, and share the burden of improving emacs.
> >> 3. You contradict yourself to some degree by complaining that
> >> temporary buffers can be killed without prompting the user about
> >> whether and under what name to save them. I think it would be clearer
> >> if you said "empty" buffer instead of "temporary".
>
> > I'm not sure i understood exactly what u mean.
>
> Temporary objects are those which are not intended to be saved.
Ok. i see what you are saying.
> > What i meant in my article or post was that, emacs won't offer save
> > for buffers not associated with a file. This is so for buffers created
> > using the switch-to-buffer command.
>
> Yes, it is a convenient feature. :-)
Emacs not prompting to save for any buffer not associated with a file,
is a major problem. Please check with any respected UI expect...
i don't think it's fruitful for me to keep arguing. I've outlined all
the reasons i can think of in my article. The large discussions in 120
messages thread, almost added no value. ...
maybe to be constructive, how about you giving me a reason why not
prompting for save is good?
ok, let me start... the emacs way of not prompting, you argue that's
because some buffers are just temp, so user don't need to be prompted
because they used it as throwaway ones in the first place. I argue no,
because having user to remember which buffer is temp, or having user
to be aware that the buffer is the *scratch* one, is a burden on the
mind. Of course, it's not a major one, but such little things are
problems. On the other hand, if you follow my proposal, user no longer
need to keep in mind which buffer is meant for temp. As soon as they
call close command, emacs will promp them to save if necessary.
Why do you think this is worse?
> >> I prefer progress to modernization.
>
> > The “modernization” is just a descriptive tag. Am not sure exactly
> > what you mean. Modernization is simply a collective term for emacs
> > improvements that happens to make emacs more compatible with modern
> > terminologies, UI sandards. Many tech geekers will perhaps think
> > “modernization” means “let's make emacs like Microsoft”. No. It is not
> > the intention nor the goal. (Of interest to note, that it is EXACTLY
> > Linux's KDE's prominently published manifesto, for example, when it
> > starts in about 1998.)
>
> Whether a technology or UI convention (not standard) is good has little
> to do with how modern it is, regardless of its sponsor.
to be perfectly logical, that's right, but it kinda disregard common
sense. As a analogy, whether a technology is better does not depend on
whether it is modern. So, irregation, transportations methods in say
1500s, may actually be better than today's. But that's silly.
In software UI, sure, the issue is not that clear cut. However, you
cannot brush away, or in the case of tech geekers, to sneer the UI
designed by successful companies such as Microsoft, Apple, Google.
In other point of view, why not take the perspective and think, to
what degree you are simply being a emacs fanatic and refuse to see
things? Surely, you can imagine how vi users will argue to the death
if you tell them some vi ways is inferior to emacs. Sure, there's a
lot fanaticism. Are you saying fanatism is good? Are you saying that
Microsoft, Apple, Google, etc are mere marketing and exploination of
the dumb?
I get quite worked up when discussiing with you tech geekers...
sometimse i don't care... you guys are just extremely idiotic.
You can quote me on this. Argue with me, argue with all your silly
argument with me and snowball this thread... so perhaps we can get it
to some wider public attention. When the discussion of tech geekers
such as this thread goes to the wide public, perhaps the public at
large, all expert of various fields, will come to know that i'm a
nutcase, but there's one thing they'll agree on: how ignorant and
downright stupid the tech geekers are about UI, critical thinking.
> I do not see how this single user command affects Emacs' efficiency,
> power, or usability. Your proposal is a sledgehammer that impacts all
> users, when all that is needed to address *your* criticism is a new
> command that behaves the way *you* want it to.
... I tried to punch my keyboard as fast as i could in this reply,
but my fingers got very tired at this point.
Have a good day Kevin. (^_^)
Xah
∑ http://xahlee.org/
☄
next prev parent reply other threads:[~2008-09-26 13:28 UTC|newest]
Thread overview: 163+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-16 5:28 How to get rid of *GNU Emacs* buffer on start-up? Davin Pearson
2008-09-16 7:39 ` Giorgos Keramidas
2008-09-16 8:47 ` Davin Pearson
2008-09-16 8:14 ` Adam Rooke
2008-09-16 8:44 ` Nikolaj Schumacher
2008-09-16 8:44 ` Charles Sebold
2008-09-16 20:57 ` Xah
2008-09-17 1:22 ` Giorgos Keramidas
2008-09-18 5:35 ` Xah Lee
2008-09-18 5:41 ` Xah Lee
2008-09-19 0:39 ` tyler
[not found] ` <mailman.19510.1221784782.18990.help-gnu-emacs@gnu.org>
2008-09-19 4:16 ` David Kastrup
2008-09-19 12:42 ` tyler
2008-09-20 1:53 ` Allan Gottlieb
2008-09-29 19:20 ` tyler
2008-10-01 10:26 ` Tassilo Horn
[not found] ` <mailman.19545.1221828161.18990.help-gnu-emacs@gnu.org>
2008-09-19 21:09 ` David Kastrup
2008-09-19 4:49 ` Xah Lee
2008-09-18 23:50 ` Xah Lee
2008-09-19 8:53 ` Eli Zaretskii
[not found] ` <mailman.19536.1221814453.18990.help-gnu-emacs@gnu.org>
2008-09-19 11:34 ` Xah Lee
2008-09-19 13:04 ` Cor Gest
2008-09-19 14:21 ` Xah Lee
2008-09-19 15:32 ` Eric S Fraga
2008-09-20 0:54 ` Xah Lee
2008-09-22 8:25 ` Eric S Fraga
2008-09-22 11:40 ` Xah Lee
2008-09-22 12:16 ` Lennart Borgman (gmail)
[not found] ` <mailman.19683.1222085805.18990.help-gnu-emacs@gnu.org>
2008-09-22 13:53 ` Xah Lee
2008-09-22 14:50 ` Lennart Borgman (gmail)
[not found] ` <mailman.19689.1222095038.18990.help-gnu-emacs@gnu.org>
2008-09-23 13:49 ` Xah Lee
2008-09-23 15:47 ` Lennart Borgman (gmail)
[not found] ` <mailman.19771.1222184864.18990.help-gnu-emacs@gnu.org>
2008-09-23 16:27 ` Xah Lee
2008-09-23 16:47 ` Lennart Borgman (gmail)
[not found] ` <mailman.19774.1222188466.18990.help-gnu-emacs@gnu.org>
2008-09-23 16:59 ` Xah Lee
2008-09-23 17:43 ` Lennart Borgman (gmail)
2008-09-22 18:25 ` Eric S Fraga
2008-09-23 8:16 ` Xah Lee
2008-09-23 13:02 ` Eric S Fraga
2008-09-23 15:20 ` Xah Lee
2008-09-23 18:55 ` Michael Ekstrand
2008-09-24 1:59 ` Xah Lee
2008-09-24 8:31 ` Eric S Fraga
2008-09-24 10:12 ` Giorgos Keramidas
2008-09-24 11:46 ` Alexey Pustyntsev
[not found] ` <mailman.19815.1222259480.18990.help-gnu-emacs@gnu.org>
2008-09-24 12:52 ` Andreas Politz
2008-09-24 13:30 ` Xah Lee
2008-09-24 9:28 ` Nikolaj Schumacher
[not found] ` <mailman.19809.1222248534.18990.help-gnu-emacs@gnu.org>
2008-09-24 14:38 ` Xah Lee
2008-09-24 17:15 ` Nikolaj Schumacher
[not found] ` <mailman.19834.1222276553.18990.help-gnu-emacs@gnu.org>
2008-09-25 3:16 ` Xah
2008-09-23 20:34 ` Nikolaj Schumacher
2008-09-23 21:16 ` harven
2008-09-24 1:35 ` Xah Lee
2008-09-19 16:13 ` Nikolaj Schumacher
[not found] ` <mailman.19563.1221840835.18990.help-gnu-emacs@gnu.org>
2008-09-20 0:02 ` Xah Lee
2008-09-20 1:12 ` Chetan
2008-09-20 2:35 ` Kevin Rodgers
2008-09-24 7:35 ` Kevin Rodgers
[not found] ` <mailman.19800.1222241766.18990.help-gnu-emacs@gnu.org>
2008-09-24 9:26 ` Xah Lee
2008-09-26 4:52 ` Kevin Rodgers
[not found] ` <mailman.19977.1222404766.18990.help-gnu-emacs@gnu.org>
2008-09-26 12:39 ` Xah
[not found] ` <mailman.19592.1221878128.18990.help-gnu-emacs@gnu.org>
2008-09-20 2:58 ` Xah Lee
2008-09-24 7:54 ` Kevin Rodgers
[not found] ` <mailman.19802.1222242899.18990.help-gnu-emacs@gnu.org>
2008-09-24 10:02 ` Xah Lee
2008-09-24 11:42 ` Xah Lee
2008-09-24 12:51 ` rustom
2008-09-24 13:33 ` Bug? buffer-offer-save Xah Lee
2008-09-24 14:31 ` Juanma Barranquero
2008-09-24 14:33 ` Juanma Barranquero
2008-09-26 5:40 ` How to get rid of *GNU Emacs* buffer on start-up? Kevin Rodgers
[not found] ` <mailman.19978.1222407641.18990.help-gnu-emacs@gnu.org>
2008-09-26 13:28 ` Xah [this message]
2008-09-26 21:45 ` Alan Mackenzie
2008-09-27 2:20 ` Kevin Rodgers
[not found] ` <mailman.20050.1222482050.18990.help-gnu-emacs@gnu.org>
2008-09-27 14:27 ` Xah
[not found] ` <mailman.20040.1222465122.18990.help-gnu-emacs@gnu.org>
2008-09-27 0:15 ` Chetan
2008-09-27 7:57 ` Andreas Politz
2008-09-27 14:17 ` Xah
2008-09-27 12:42 ` Chetan
2008-09-27 16:19 ` Xah
2008-09-27 17:28 ` Sean Sieger
2008-09-27 18:12 ` B. T. Raven
2008-09-27 22:48 ` Chetan
2008-09-28 3:43 ` Xah
[not found] ` <mailman.20073.1222536552.18990.help-gnu-emacs@gnu.org>
2008-09-28 2:46 ` Xah
2008-09-28 16:18 ` stan
2008-09-28 17:11 ` Richard Riley
2008-09-29 2:34 ` stan
2008-09-29 2:58 ` Richard Riley
2008-09-29 15:39 ` Cor Gest
2008-09-29 16:03 ` Richard Riley
2008-09-29 16:37 ` Cor Gest
2008-09-29 17:50 ` Richard Riley
2008-10-15 16:01 ` buffers and files and plus ca la change and all that OtherMichael
2008-10-01 1:37 ` How to get rid of *GNU Emacs* buffer on start-up? stan
2008-10-01 11:44 ` rustom
2008-10-01 19:58 ` Sean Sieger
2008-10-01 14:19 ` Richard Riley
2008-09-29 14:06 ` rustom
2008-09-29 14:32 ` Richard Riley
2008-09-29 16:56 ` Chetan
2008-09-30 9:46 ` Paul R
2008-09-30 13:37 ` Alexey Pustyntsev
2008-10-01 7:27 ` Paul R
[not found] ` <mailman.20241.1222781309.18990.help-gnu-emacs@gnu.org>
2008-09-30 19:20 ` xraysmalevich
2008-09-20 10:51 ` Nikolaj Schumacher
2008-09-19 13:08 ` xraysmalevich
2008-09-19 14:13 ` Xah Lee
2008-09-19 15:21 ` xraysmalevich
2008-09-19 15:36 ` Xah Lee
2008-09-19 13:46 ` Eli Zaretskii
[not found] ` <mailman.19551.1221832017.18990.help-gnu-emacs@gnu.org>
2008-09-19 14:32 ` Xah Lee
2008-09-19 15:31 ` Eli Zaretskii
2008-09-19 16:39 ` Alan Mackenzie
2008-09-20 0:12 ` Xah Lee
2008-09-20 0:48 ` Cor Gest
2008-09-20 3:06 ` Xah Lee
[not found] ` <mailman.19558.1221838316.18990.help-gnu-emacs@gnu.org>
2008-09-19 18:11 ` Lowell Gilbert
2008-09-19 20:36 ` Alan Mackenzie
2008-09-20 0:50 ` Xah Lee
2008-09-20 8:17 ` Alan Mackenzie
[not found] ` <mailman.19598.1221898300.18990.help-gnu-emacs@gnu.org>
2008-09-22 13:07 ` Xah Lee
2008-09-22 16:29 ` Nikolaj Schumacher
2008-09-22 16:58 ` Sean Sieger
[not found] ` <mailman.19706.1222102753.18990.help-gnu-emacs@gnu.org>
2008-09-22 17:56 ` Xah Lee
2008-09-22 19:15 ` Ted Zlatanov
2008-09-23 14:47 ` Xah Lee
2008-09-22 22:13 ` Alan Mackenzie
[not found] ` <mailman.19718.1222121219.18990.help-gnu-emacs@gnu.org>
2008-09-22 22:36 ` David Kastrup
2008-09-24 11:43 ` Alan Mackenzie
[not found] ` <mailman.19814.1222256243.18990.help-gnu-emacs@gnu.org>
2008-09-27 16:35 ` Xah
[not found] ` <mailman.19702.1222100964.18990.help-gnu-emacs@gnu.org>
2008-09-22 17:06 ` Xah Lee
2008-09-23 19:05 ` Nikolaj Schumacher
2008-09-24 2:08 ` Xah Lee
2008-09-24 4:32 ` Ross A. Laird
[not found] ` <mailman.19792.1222230766.18990.help-gnu-emacs@gnu.org>
2008-09-24 10:22 ` Giorgos Keramidas
2008-09-25 4:01 ` Xah
2008-09-20 8:50 ` Alan Mackenzie
[not found] ` <mailman.19599.1221900241.18990.help-gnu-emacs@gnu.org>
2008-09-22 13:08 ` Xah Lee
2008-09-17 7:36 ` Kevin Rodgers
[not found] ` <mailman.19399.1221637030.18990.help-gnu-emacs@gnu.org>
2008-09-17 23:16 ` Xah
2008-09-21 12:06 ` Christian Herenz
2008-09-21 19:01 ` Joost Kremers
2008-09-24 14:39 ` William Case
[not found] ` <mailman.19824.1222267150.18990.help-gnu-emacs@gnu.org>
2008-09-25 5:06 ` Tim X
2008-09-25 6:35 ` Xah
2008-09-25 8:13 ` Jonathan Groll
[not found] ` <mailman.19898.1222330438.18990.help-gnu-emacs@gnu.org>
2008-09-25 9:09 ` Andreas Politz
2008-09-25 10:01 ` Juanma Barranquero
2008-09-25 11:17 ` Xah
[not found] ` <mailman.19906.1222336893.18990.help-gnu-emacs@gnu.org>
2008-09-25 12:07 ` Xah
2008-09-25 12:53 ` Lennart Borgman
[not found] ` <mailman.19912.1222347213.18990.help-gnu-emacs@gnu.org>
2008-09-25 13:21 ` Xah
2008-09-25 13:48 ` Lennart Borgman
[not found] ` <mailman.19917.1222350495.18990.help-gnu-emacs@gnu.org>
2008-09-25 13:57 ` Xah
2008-09-25 15:39 ` Lennart Borgman (gmail)
[not found] ` <mailman.19926.1222357204.18990.help-gnu-emacs@gnu.org>
2008-09-26 1:07 ` Xah
2008-09-25 11:00 ` Xah
2008-09-25 13:34 ` language (was: How to get rid of *GNU Emacs* buffer on start-up?) Ted Zlatanov
2008-09-25 13:49 ` Xah
2008-09-25 19:47 ` language Ted Zlatanov
2008-09-25 17:58 ` How to get rid of *GNU Emacs* buffer on start-up? Sean Sieger
[not found] ` <mailman.19940.1222365501.18990.help-gnu-emacs@gnu.org>
2008-09-26 1:04 ` Xah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3c61c357-0705-4ff4-b793-fa6827415fdd@n38g2000prl.googlegroups.com \
--to=xahlee@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.