From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.help Subject: Re: How to get rid of *GNU Emacs* buffer on start-up? Date: Fri, 26 Sep 2008 21:45:18 +0000 Message-ID: <20080926214518.GB4071@muc.de> References: <87ljxoffs6.fsf@atthis.clsnet.nl> <71208e97-140c-445d-8eda-1705f11b14b3@r15g2000prd.googlegroups.com> <095ef0c0-c7f4-494d-8bf6-8a5ee43fd934@i20g2000prf.googlegroups.com> <3c61c357-0705-4ff4-b793-fa6827415fdd@n38g2000prl.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1222465159 18869 80.91.229.12 (26 Sep 2008 21:39:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Sep 2008 21:39:19 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Xah Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Sep 26 23:40:16 2008 connect(): Connection refused Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KjL2n-0007Ex-RQ for geh-help-gnu-emacs@m.gmane.org; Fri, 26 Sep 2008 23:40:10 +0200 Original-Received: from localhost ([127.0.0.1]:40207 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KjL1l-0006CA-6d for geh-help-gnu-emacs@m.gmane.org; Fri, 26 Sep 2008 17:39:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KjL1N-0006AT-4c for help-gnu-emacs@gnu.org; Fri, 26 Sep 2008 17:38:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KjL1M-00069e-MA for help-gnu-emacs@gnu.org; Fri, 26 Sep 2008 17:38:40 -0400 Original-Received: from [199.232.76.173] (port=55574 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KjL1L-00069S-TF for help-gnu-emacs@gnu.org; Fri, 26 Sep 2008 17:38:40 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:2754 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KjL1L-0004zt-7j for help-gnu-emacs@gnu.org; Fri, 26 Sep 2008 17:38:39 -0400 Original-Received: (qmail 12953 invoked by uid 3782); 26 Sep 2008 21:38:31 -0000 Original-Received: from acm.muc.de (pD9E52AB6.dip.t-dialin.net [217.229.42.182]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Fri, 26 Sep 2008 23:38:28 +0200 Original-Received: (qmail 6342 invoked by uid 1000); 26 Sep 2008 21:45:18 -0000 Content-Disposition: inline In-Reply-To: <3c61c357-0705-4ff4-b793-fa6827415fdd@n38g2000prl.googlegroups.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:58124 Archived-At: Hi, Xah! Surely this thread of discussion is approaching its end, now. On Fri, Sep 26, 2008 at 06:28:03AM -0700, Xah wrote: > Kevin Rodgers wrote: > > > « > > > * There is no easy, intuitive way to create multiple scratch > > > buffers. (it is done by using the switch-to-buffer command (C-x b) and > > > give name that is not one of existing buffers.) > > We'll have to disagree: I think that is both easy and intuitive. > What seems to you intuitive is not intuitive to the general text > editing audience. The text editing audience is broad, including all IT > professionals, those in academics. Many of these people, wouldn't have > clude if you ask them to define variable or algorithm or byte. Perhaps > you are thinking these people are stupid. Perhaps when compared to you > as a tech geeker, they are quite ignorant about computers. But the > world is big, there are all walks of life. Many of them are in fact > scientists, engineers, mathematicians, lawers. We know all this. > You wouldn't know shit if i ask you some elementary math concepts > (trust me). Similarly, you don't know the most elementary thing about > laws, engineering, ... all all sort of fields. Again, the Emacs developers, certainly the users, collectively have substantial knowledge in all these fields. > One element of User Interface design is that the user don't have to > learn anything in order to use it, as much as possible. Possibly. But that element of UI is subordinate to efficiency in things like Emacs or a modern airliner. > Emacs has too many unusual ways... (btw, i'm damn repeating myself > again and again and again here... in this thread i've already wrote > paragraph(s) that details this). Yes, Emacs has lots of "unusual" ways, and yes, you are repeating yourself. But consider how these "unusual" things have come about; they've sort of evolved: new things have been tried, and if they've been good they've become part of Emacs, otherwise they've been discarded and forgotten about. Emacs's features aren't random. > Please, have a open mind. Open mind is not easy, you really have to > put effort into it. Please, you too. > For example, let me ask this: have you ever, actually try to look into > the knowledge of User Interface? What it entails? What academic field > in involves? Have you actually read a text book on it? Whats the > latest research on it? Who are the dignitaries in the research? What > are the common, standard, or well known reference for UI? No, I haven't. Have you? Emacs, by the very way it has developed, has a good UI. If you could cite me any papers written by UI academics about Emacs, I'd certainly be interested to read them. I'm sure I could learn quite a bit. > again i'm repeating, and you may think i sound like ergomaniac, or you > might think i'm bullshitting ... but the opinions expressed here by > tech geekers are really completely ignorant. Ask any UI expert, > researcher, they'll laugh. Would they really? Again, have you seen any relevant publications where some UI expert has criticised Emacs's interface. Perhaps we could improve it. > The things i say, just about every aspect of this thread's argument, > can be reasonably verified, acertined. That's unlikely; unless I've missed something, you haven't yet cited any authoritative sources. Mostly, you've just cited your own work. > But you guys didn't even go up to the level of question about > verification, such as how can we carried out, etc. You you guys are > saying, basically at the level of ???emacs is not Microsoft and emacs > should not dumb down???!! Yes, indeed. Many of these other programs are intended to be easy to learn. Emacs is intended, instead, to be easy to use. The aims are different, so the results are different. > > > * When the scratch buffer is closed, emacs does not prompt user > > > to save it. This easily causes data loss. > > What part of the initial contents of the *scratch* buffer is not clear: > > ;; This buffer is for notes you don't want to save, and for Lisp evaluation. > > ;; If you want to create a file, visit that file with C-x C-f, > > ;; then enter the text in that file's own buffer. > See above. One element of software UI design is that it should keep it > to minimal for users having to spend time learning things that is not > directly relevant to her tasks. No. As said above, Emacs is designed to be _efficient_. One of the costs of this is that there a lot of little details that users need to learn. It's a tradeoff. People who don't want to put in the learning time should be using a different editor. [ .... ] > > So set initial-major-mode to your favorite text or programming language > > mode. Mine is emacs-lisp-mode. > Again, the discussion, criticism, is not about ???Hi guys, do you know > a way so that i can do xyz in emacs????. It is not about how one > individual can customize emacs to some way. Sorry, Xah, but that is PRECISELY what Emacs is about. Emacs was designed explicitly to be as configurable as possible. That way, each user can set up her own Emacs to suit her way of working. I couldn't work well with Emacs set up the way you're advocating, and I doubt you'd much like the way I've set up my Emacs. There are some defaults in Emacs which, to me, are utterly stupid and crazy, and I've spent many, many hours trying to explain to the rest of the Emacs developers why some of their ideas are so stupid. ;-) They, in their turn, have defended their stupidity, and argued that they're the best thing ever invented. ;-) There are no absolutes here. Users vary enormously. > I have written this again and again... Yes, you have. But that doesn't make what you've written any truer or more valid than if you'd only written it once. [ .... ] > It is one of the items that details a problem of *scratch*, in support > of my proposal. It is not about ???how can i, Xah Lee, set emacs so > that the *scratch* buffer start in xyz mode???. It isn't an intrinsic problem with *scratch*. The problem is in the relationship between the user and the *scratch* buffer. The solution is to configure Emacs until that relationship functions smoothly. > No disrespect, but please perhaps take a course in college about > critical thinking or philosophy: > http://en.wikipedia.org/wiki/Critical_thinking That is very disrespectful. There has been no lack of quality critical thinking from most of the people in this debate. Would you please now reassure all of us that you have taken, or will take heed of what we've been telling you, and will incorporate our points into your thinking, whether you agree with them or not. > ----------------------- [ .... ] > > Agreed. I think you should lobby the Emacs maintainers to include > > something like the switch-to-new-buffer command I proposed. But it > > does need to be enhanced to prompt for saving when it is killed. > You can help me with it, by filing a bug report on the *scratch* > buffer, borrowing whatever part in my article you think you agree, or > perhaps completely on your own reasons. But you could do this yourself, couldn't you? > As you perhaps know, i've had quite few heated arguments here. This > thread is now 120 messages going to the level of ???fuck you's???. > About 3 or 4 similar threads on other emacs issues has happend in the > past 2 or 3 monhs. Indeed. Remember me telling you a few days ago that using swear words (even without 6 surrounding question marks ;-) doesn't help you get your message across? If we looked at the thread to see who has been using these bad words most, I wonder who would it be? > I'm not getting paid to debate. The several items in emacs > modernization proposals doesn't benefit me directly in any way, and it > is not likly to be incorporated into emacs anytime soon. No. They're never going to be incorporated until somebody implements them. > Instead of suggesting me to do something, why don't you do something > about it? I'm not trying to be rude, and i very much appreciate your > argument here, one of the 3 or 4 in this thread that actually are > sincere and has content, in my opinion. Is there any reason you can't implement these things yourself? Or is there some reason you don't want to? [ .... ] > > >> 3. You contradict yourself to some degree by complaining that > > >> temporary buffers can be killed without prompting the user about > > >> whether and under what name to save them. I think it would be > > >> clearer if you said "empty" buffer instead of "temporary". > > > I'm not sure i understood exactly what u mean. > > Temporary objects are those which are not intended to be saved. > Ok. i see what you are saying. > > > What i meant in my article or post was that, emacs won't offer save > > > for buffers not associated with a file. This is so for buffers > > > created using the switch-to-buffer command. > > Yes, it is a convenient feature. :-) > Emacs not prompting to save for any buffer not associated with a file, > is a major problem. Please check with any respected UI expect... Emacs also doesn't offer to save the contents of the minibuffer, or any of a whole host of other buffers. > i don't think it's fruitful for me to keep arguing. I've outlined all > the reasons i can think of in my article. The large discussions in 120 > messages thread, almost added no value. ... Surely you have learnt quite a bit from it? I've learnt that in many programs, Ctrl-n creates a new thingy. > maybe to be constructive, how about you giving me a reason why not > prompting for save is good? This is one of those "relationship" things. For some people, this prompting would be useful, for many (including Kevin and me) it would be a nuisance. > ok, let me start... the emacs way of not prompting, you argue that's > because some buffers are just temp, so user don't need to be prompted > because they used it as throwaway ones in the first place. I argue no, > because having user to remember which buffer is temp, or having user > to be aware that the buffer is the *scratch* one, is a burden on the > mind. Of course, it's not a major one, but such little things are > problems. On the other hand, if you follow my proposal, user no longer > need to keep in mind which buffer is meant for temp. As soon as they > call close command, emacs will promp them to save if necessary. And this prompting to save is an unnecessary and unpleasant nag. When you get something like this time after time after time, eventually you just press the 'n' key automatically, without thinking. Sooner or later, you'll do the same when it's prompting you about a valuable buffer. So this feature of prompting to save *scratch* would cause you to lose valuable buffers. (This has happened to me in other programs.) > > >> I prefer progress to modernization. > > > The ???modernization??? is just a descriptive tag. Am not sure > > > exactly what you mean. Modernization is simply a collective term > > > for emacs improvements that happens to make emacs more compatible > > > with modern terminologies, UI sandards. Many tech geekers will > > > perhaps think ???modernization??? means ???let's make emacs like > > > Microsoft???. No. It is not the intention nor the goal. (Of > > > interest to note, that it is EXACTLY Linux's KDE's prominently > > > published manifesto, for example, when it starts in about 1998.) My impression of your proposals is that they would make Emacs more like these other programs, and in so doing make Emacs worse. For example, it stands to reason that you reserve short key bindings for frequently used commands. Yet you are advocating using a shortest binding (Ctrl-n) for opening a new buffer, something which is done only rarely. (I use it, on average, less than once per Emacs session.) > > Whether a technology or UI convention (not standard) is good has > > little to do with how modern it is, regardless of its sponsor. > to be perfectly logical, that's right, but it kinda disregard common > sense. As a analogy, whether a technology is better does not depend on > whether it is modern. So, irregation, transportations methods in say > 1500s, may actually be better than today's. But that's silly. A better way of looking at it is how long a technology has been developed for. Since irrigation has developed over several millennia, you'd expect it to have attained an optimum by now. Similarly, the Emacs UI has developed over ~30 years. The sort of things you want to put in are much newer by comparison, and exist mainly in environments where they're not subject to selection and improvement. > In software UI, sure, the issue is not that clear cut. However, you > cannot brush away, or in the case of tech geekers, to sneer the UI > designed by successful companies such as Microsoft, Apple, Google. Oh, we could, but there's no need to. Those UIs have different design objectives from Emacs's. > In other point of view, why not take the perspective and think, to > what degree you are simply being a emacs fanatic and refuse to see > things? Surely, you can imagine how vi users will argue to the death > if you tell them some vi ways is inferior to emacs. Sure, there's a > lot fanaticism. Are you saying fanatism is good? Are you saying that > Microsoft, Apple, Google, etc are mere marketing and exploination of > the dumb? I'm really not sure what you mean by "Emacs fanatic". Of course the people on this mailing list will tend to be Emacs fanatics. You are, yourself, are you not? > I get quite worked up when discussiing with you tech geekers... > sometimse i don't care... you guys are just extremely idiotic. That's what's known as an "ad hominem attack". Rather than debating the issues with people, you attack them personally. > You can quote me on this. Argue with me, argue with all your silly > argument with me and snowball this thread... so perhaps we can get it > to some wider public attention. When the discussion of tech geekers > such as this thread goes to the wide public, perhaps the public at > large, all expert of various fields, will come to know that i'm a > nutcase, but there's one thing they'll agree on: how ignorant and > downright stupid the tech geekers are about UI, critical thinking. Just what is it that makes you think that you're right, and we're all wrong? That's not a rhetorical question. After so many people have disagreed with you on this thread, have you not examined your own thinking to see whether or not you might have gone wrong somewhere? Perhaps made a few unwarranted assumptions, and then followed them with impeccable logic? > Have a good day Kevin. (^_^) I'm not Kevin, but you have a good day too, Xah! > Xah > ??? http://xahlee.org/ -- Alan Mackenzie (Nuremberg, Germany).