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: Tue, 13 Jul 2010 12:23:53 +0300 Message-ID: <83lj9fspjq.fsf@gnu.org> References: <4C3B6A8A.80105@gmx.de> <87wrt0e81n.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 1279013178 27197 80.91.229.12 (13 Jul 2010 09:26:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Jul 2010 09:26:18 +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 Tue Jul 13 11:26: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 1OYbkc-0001gY-KY for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 11:26:07 +0200 Original-Received: from localhost ([127.0.0.1]:37311 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYbkc-00080X-1F for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 05:26:06 -0400 Original-Received: from [140.186.70.92] (port=47652 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYbkT-00080S-9r for emacs-devel@gnu.org; Tue, 13 Jul 2010 05:25:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYbkR-0001ao-J1 for emacs-devel@gnu.org; Tue, 13 Jul 2010 05:25:57 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:44751) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYbkR-0001ae-CF for emacs-devel@gnu.org; Tue, 13 Jul 2010 05:25:55 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L5H00500OM90D00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 13 Jul 2010 12:25:53 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.120.144]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L5H000P2OV3YW90@a-mtaout22.012.net.il>; Tue, 13 Jul 2010 12:25:53 +0300 (IDT) In-reply-to: <87wrt0e81n.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:127162 Archived-At: > From: =C3=93scar Fuentes > Date: Mon, 12 Jul 2010 22:53:24 +0200 >=20 > A few weeks ago I was required to translate an old, small Visual Ba= sic > application to C#. I was less than thrilled with the job, but anywa= ys > the first thing was to configure Emacs as a C# editor. There is > csharp-mode, which does code formatting. So far, so good. There are= two > methods for code completion, one based on CEDET and the other on an > external tool. The CEDET method was a nonstarter, the other worked > so-so. As I'm an absolute beginner on C# and it comes with a vast A= PI, > code completion was too much of a time-saver to be neglected. After= 3 > hours trying to raise Emacs to the minimum usability level, I gave = up > and tried certain popular IDE, out of despair. 15 minutes later my > client's application, on its basic inception, was running on the sc= reen, > mostly thanks to an accurate and fast code completion system that n= ot > only shows the candidates for completion, but also displays some > documentation explaining what every method does. This saves a lot o= f > time browsing documentation. CEDET is a relatively new addition to Emacs. I don't use it, but fro= m some comments by its maintainer posted here, it sounds like it needs some work to bring it up to a reasonable level of usability for newbies. Like everything else in Emacs, this job needs motivated individuals to step forward and do it. I don't see anything in this situation that could trigger this outburst: > It is disheartening to see how ev= ery > time that someone proposes a tiny change on the default configurati= on > for lowering the entry barrier, a vociferous group of reactionaries= try > to block the initiative, usually winning the fight, just because th= ey > 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 t= o 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? > Emacs does just the opposite. See how people on this discussion say= s "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. Half of it describes issues that are common knowledge nowadays, anyway (e.g., "If you want to insert text, just type the text"). The other half is only needed for "advanced users". Most of that is available through menus, so no need to learn the keyboard keybindings, unless you are a touch typist. We are keeping the tutorial and recommend that users read it because of a certain policy. I happen to agree with that policy, but I also know that it has nothing to do with the ability to use Emacs reasonably well, right from day one. 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. > IMAO the Emacs maintainers should ignore the winning and threatenin= g 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". There'= s a group of people who contribute to Emacs development, each one in th= e 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 nee= d one. 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 default= s 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 orde= r to reach the goal. 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) 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.