From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Wed, 14 Jul 2010 00:37:30 +0200 Message-ID: <87tyo3c8k5.fsf@telefonica.net> References: <4C3B6A8A.80105@gmx.de> <87wrt0e81n.fsf@telefonica.net> <83lj9fspjq.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279060693 10116 80.91.229.12 (13 Jul 2010 22:38:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Jul 2010 22:38:13 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 14 00:38:10 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 1OYo77-0008Es-2z for ged-emacs-devel@m.gmane.org; Wed, 14 Jul 2010 00:38:10 +0200 Original-Received: from localhost ([127.0.0.1]:34749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYo75-0005td-LY for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 18:38:07 -0400 Original-Received: from [140.186.70.92] (port=33603 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYo6i-0005it-Qy for emacs-devel@gnu.org; Tue, 13 Jul 2010 18:38:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYo6f-0003nX-Dc for emacs-devel@gnu.org; Tue, 13 Jul 2010 18:37:42 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:34956) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYo6f-0003n7-3w for emacs-devel@gnu.org; Tue, 13 Jul 2010 18:37:41 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OYo6d-00085k-JI for emacs-devel@gnu.org; Wed, 14 Jul 2010 00:37:39 +0200 Original-Received: from 83.42.13.171 ([83.42.13.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Jul 2010 00:37:39 +0200 Original-Received: from ofv by 83.42.13.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Jul 2010 00:37:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 139 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.13.171 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:Y4uKIvzApObt2m7wjhnxjPrR3Go= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:127226 Archived-At: Eli Zaretskii writes: [snip] > I don't see anything in this situation that could trigger this > outburst: > >> It is disheartening to see how every >> time that someone proposes a tiny change on the default configuration >> for lowering the entry barrier, a vociferous group of reactionaries try >> to block the initiative, usually winning the fight, just because they >> don't want to add a line or two to their .emacs file. > > What "reactionaries"? All I see is a newly added package and a job to > be done with making it better, waiting (for a relatively short time, > up until now) for volunteers to do it. > > How on earth evident problems with a single Emacs package can lead to > such extremist opinions? Did you have an awfully bad day or > something? If you do selective quoting and paragraph reordering for reaching a negative opinion, I'm left wondering who of us is having an awfully bad day. Read again my message and you see how between the two paragraphs you quoted there is a lot of substance. >> Emacs does just the opposite. See how people on this discussion says "of >> course the new Emacs user will read the Tutorial etc." > > Contrary to what you've read, I maintain that reading the tutorial is > not a necessity. I'm not sure about this. Maybe we should experiment with a few seasoned hackers who never used Emacs and observe if they reflect surprise or confussion about some features that are contrary to all their previous experience, without perceiving any advantage on them. [snip] > Of course, what you can do with Emacs from day one does not > necessarily include features like CEDET or Gnus -- but the tutorial > will not help here, either. As is implicit on the message you quoted, the features provided by CEDET are a must-have if you pretend to advertise Emacs as a productivity boost for certain tasks which are becoming more prevalent as time passes, so those features should work (and work well) from the very moment the user visits a file where they are applicable. >> IMAO the Emacs maintainers should ignore the winning and threatening 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". Well, call them by some other name, but the maintainers I'm thinking of are those with the power of making controversial decisions against the opinion of other prominent Emacs contributors. Currently they are Chong and Stefan, AFAIK. > There's a group of people who contribute to Emacs development, each > one in the area of his/her interests. (In addition, they fix bugs, as > much as their time and energy allows them -- but I hope you will agree > that what you want cannot be achieved by way of fixing bugs.) Areas > that are not within the interests or expertise of these developers do > not get developed, no matter how important they are. The support for > editing bidirectional text is a good recent case in point, if you need > one. This is fine with me, as far as those people do not stop development, advancement, change or whatever you call it, on other areas. 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.) > Conclusion: people who are interested in making Emacs more usable by > "new generations of hackers" should stop complaining, and instead > _act_. Don't try to fix this or that isolated feature -- this just > tends to get bogged down in endless bike-shed arguments about defaults > and faces. Instead, work out and present "The Plan" -- a list of > issues that need to be handled, infrastructure that needs to be added, > and features and packages that need to be developed or added, in order > to reach the goal. 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 unaceptable or someone proposes an improved strategy. Guess what? there was no need for it: was smashed a few post above. It seems that a workable plan here must meet the following conditions: * Follow the GNU guidelines wrt the programming language. There is quite a bit of personal, questionable opinions there. But well, maybe we 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.) * When there is a GNU package for doing something, use it instead of 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, this makes sense, as long as the GNU package is a match for the non-GNU one on terms of how good is it for the job. However, as we have experienced recently, an inferior GNU system triumphs over a superior non-GNU one, hoping that, eventually, the GNU system improves. There is little point on convincing the key people about the slight possibilities of seeing those hopes ever realized. * Unless it is something accessory that does not conflict with existing 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. * 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 add a line to their .emacs for keeping the previous behavior. Think about something that changes some core piece of Emacs philosophy. > Then start producing code according to that Plan. There's nothing > like a working code to convince non-believers (if there are such among > the active developers) Sorry, only for the GUI infrastructure, this would be a multi-year effort (working an average of 10 hours per week.) But it doesn't matter, because my plan was already rejected. > and there's nothing like a workable plan to attract followers. If > there's anything clear from this confused thread, it's that we sorely > need some kind of unified "vision" and specific goals. Throwing > random ideas and critique will get us nowhere. I completely agree, but it is in contradiction with what you wrote above about every developer scratching it itch.