From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Wed, 14 Jul 2010 10:19:19 +0300 Message-ID: <83y6der0nc.fsf@gnu.org> References: <4C3B6A8A.80105@gmx.de> <87wrt0e81n.fsf@telefonica.net> <83lj9fspjq.fsf@gnu.org> <87tyo3c8k5.fsf@telefonica.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1279092147 22192 80.91.229.12 (14 Jul 2010 07:22:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Jul 2010 07:22:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 14 09:22:25 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OYwIR-0002I0-9p for ged-emacs-devel@m.gmane.org; Wed, 14 Jul 2010 09:22:23 +0200 Original-Received: from localhost ([127.0.0.1]:53708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYwIQ-00063e-AF for ged-emacs-devel@m.gmane.org; Wed, 14 Jul 2010 03:22:22 -0400 Original-Received: from [140.186.70.92] (port=49372 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYwHd-0005tg-0L for emacs-devel@gnu.org; Wed, 14 Jul 2010 03:21:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYwHQ-0005Sw-Ei for emacs-devel@gnu.org; Wed, 14 Jul 2010 03:21:21 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:54000) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYwHQ-0005Sg-0S for emacs-devel@gnu.org; Wed, 14 Jul 2010 03:21:20 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L5J00A00DC65V00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Wed, 14 Jul 2010 10:21:18 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.120.144]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L5J004BCDRGDSE0@a-mtaout22.012.net.il>; Wed, 14 Jul 2010 10:21:18 +0300 (IDT) In-reply-to: <87tyo3c8k5.fsf@telefonica.net> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127254 Archived-At: > From: =C3=93scar Fuentes > Date: Wed, 14 Jul 2010 00:37:30 +0200 >=20 > Read again my message and you see how between the two paragraphs > you quoted there is a lot of substance. That substance seemed unrelated to the outburst. Basically, I don't understand how a bunch, even a large bunch, of usability problems could lead to far-fetched (and IMO wrong) conclusions that Emacs development is controlled by a band of reactionaries. > > Contrary to what you've read, I maintain that reading the tutoria= l is > > not a necessity. >=20 > I'm not sure about this. Maybe we should experiment with a few seas= oned > hackers who never used Emacs and observe if they reflect surprise o= r > confussion about some features that are contrary to all their previ= ous > experience, without perceiving any advantage on them. I already conducted those experiments, on my daytime job. None of th= e users whom I introduced to Emacs ever read the tutorial. > >> IMAO the Emacs maintainers should ignore the winning and threate= ning of > >> those users and focus on making Emacs as attractive as possible = to the > >> new generations of hackers. > > > > Breaking news: There is no such thing as "Emacs maintainers". >=20 > Well, call them by some other name, but the maintainers I'm thinkin= g of > are those with the power of making controversial decisions against = the > opinion of other prominent Emacs contributors. Currently they are C= hong > and Stefan, AFAIK. None of whom said anything against better usability so far. And Yidong did most of the hard work of integrating CEDET into Emacs to begin with. > This is fine with me, as far as those people do not stop developmen= t, > advancement, change or whatever you call it, on other areas. I don't recollect any incident that would go by that handle. There was a lot of tiresome longish discussions about defaults for this or that option, but I wouldn't recommend generalizing them to something as significant as what you are talking about. That's why I suggested not to start arguing about options, but instead to present a vision and a plan. > One related > example comes to mind: when the bug tracker was discussed, some > maintainer of a key package threatened with stopping his Emacs work= if > the tracker's interface was such and such (being "such and such" > precisely the kind of UI which is considered the most open and > user-friendly for beginners.) How's this relevant to Emacs features and usability in general? Did anyone suggest a change that was rejected because it was incompatible with the bug tracker? > Well, I was thinking on that plan, because I'm working on a project= that > is tangential to this, so I was even considering to write an sketch= and > submit it here just in case there is something on it that is unacep= table > or someone proposes an improved strategy. Guess what? there was no = need > for it: was smashed a few post above. I didn't see anyone smashing the plan, because no plan was ever presented. > * Follow the GNU guidelines wrt the programming language. There is = quite > a bit of personal, questionable opinions there. But well, maybe w= e > could devise a design that buries the "ugly" code out of sight (I > share the opinion about the uglyness, but I must take on account = the > usefulness of the beast. Besides, some C code in Emacs can rival = a C++ > template meta-programming library on terms of readability.) If you read those parts of the Standards document carefully, you will see that they are merely _recommendations_. A case in point is the Groff project: a very old member of the GNU family, it was implemente= d in C++ from day one. Anyway, I'd expect most, if not all, of the usability-related job to be done in Lisp, so I see no problems with the choice of programming language here. > * When there is a GNU package for doing something, use it instead o= f a > non-GNU one. It doesn't help much that the non-GNU package is > compatible with the GPL. Given the nature of the GNU project, thi= s > makes sense, as long as the GNU package is a match for the non-GN= U one > on terms of how good is it for the job. However, as we have > experienced recently, an inferior GNU system triumphs over a supe= rior > non-GNU one, hoping that, eventually, the GNU system improves. Th= ere > is little point on convincing the key people about the slight > possibilities of seeing those hopes ever realized. Is this even relevant? Did someone analyze what external packages ar= e needed for the job at hand and presented that analysis? Giving up because of theoretical complications doesn't sound wise to me. > * Unless it is something accessory that does not conflict with exis= ting > code, the plan must be technically acceptable for an overwhelming > majority of the key Emacs hackers. For a plan that introduces > significant changes, this happens with less frequency than the > alignment of the four outer planets of the Solar System. Again, is this relevant? What "significant changes" are we talking about? I would imagine a specialized package, perhaps built based on CEDET, and/or specialized mode. These can be turned on and off; thos= e "reactionaries" who don't want these features will never turn them on= , or at worst will turn them off in their ~/.emacs. Puff -- the proble= m is gone. > * Ditto for the UI changes included in the plan. This is, possibly,= even > more difficult. Once you have write access to the repo you are on= your > own for changing things (or you can work on your own branch) but = some > existing users will complain out loud if they are suppossed to ad= d a > line to their .emacs for keeping the previous behavior. Think abo= ut > something that changes some core piece of Emacs philosophy. See above: start with making it an optional feature that is off by default. If it's good, it will eventually be turned on. There were enough examples of that in Emacs history. > > Then start producing code according to that Plan. There's nothin= g > > like a working code to convince non-believers (if there are such = among > > the active developers) >=20 > Sorry, only for the GUI infrastructure, this would be a multi-year > effort (working an average of 10 hours per week.) Yeah! But even a 1000-mile journey begins with a single first step. If no one will ever make that step, the journey will never end. In other words, the fact that a significant effort is required is jus= t a test of the will and motivation of those who are the most profound critics of the current state of Emacs usability. If the motivation and the will power are high enough, they will pass that test with flying colors. > But it doesn't matter, because my plan was already rejected. No, it wasn't. Don't give up too early. Most of the complications and obstacles you see are imaginary, or could made to be so, given some creative thinking and positive attitude. Be prepared to listen to the old guard and respect their opinions, and be prepared to look for ways to compromise that don't defeat your goals. It's not that hard. > > and there's nothing like a workable plan to attract followers. I= f > > there's anything clear from this confused thread, it's that we so= rely > > need some kind of unified "vision" and specific goals. Throwing > > random ideas and critique will get us nowhere. >=20 > I completely agree, but it is in contradiction with what you wrote = above > about every developer scratching it itch. I was hoping the Plan will attract new developers with the right itch= .