From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Tue, 13 Jul 2010 07:43:18 -0400 Message-ID: <4C3C5156.4070004@siege-engine.com> References: <4C3B6A8A.80105@gmx.de> <87wrt0e81n.fsf@telefonica.net> <87bpabls4a.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1279020544 20851 80.91.229.12 (13 Jul 2010 11:29:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Jul 2010 11:29:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 13 13:29:03 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 1OYdfZ-00018E-OP for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 13:29:02 +0200 Original-Received: from localhost ([127.0.0.1]:57308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYdfZ-0001av-3m for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 07:29:01 -0400 Original-Received: from [140.186.70.92] (port=34836 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYdfT-0001Yn-SR for emacs-devel@gnu.org; Tue, 13 Jul 2010 07:28:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYdfS-0005Mq-6I for emacs-devel@gnu.org; Tue, 13 Jul 2010 07:28:55 -0400 Original-Received: from bird.interbax.net ([75.126.100.114]:50441) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYdfS-0005MI-20 for emacs-devel@gnu.org; Tue, 13 Jul 2010 07:28:54 -0400 Original-Received: (qmail 20270 invoked from network); 13 Jul 2010 06:28:50 -0500 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net (HELO ?192.168.1.201?) (71.184.83.10) by interbax.net with SMTP; 13 Jul 2010 06:28:50 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <87bpabls4a.fsf@lola.goethe.zz> X-detected-operating-system: by eggs.gnu.org: Windows 98 (1) 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:127166 Archived-At: On 07/13/2010 04:10 AM, David Kastrup wrote: > writes: > >> I disagree that Emacs is actively trying to work against certain classes >> of users, as you seem to suggest. >> >> Obviously, Emacs has varying degrees of support for different >> programming languages. Somebody has to provide such support, it does not >> materialise out of the blue, and as with most free software support >> follows the interest of the developers. >> >> If C# is poorly supported, it simply means that very few dedicated emacs >> hackers has had the need/motivation/time to provide it. In contrast, >> Emacs offers some of the best Common Lisp support anywhere, complete >> with cross-referencing, documentation access, completion and minibuffer >> argument hints. > > The question is why the respective facilities are not part of the > generic Emacs language support framework. Support for every language > has a completely disjoint set of features, keybindings, highlighting, > and so on of wildly differing quality, design and usability. I have to agree with David here. I'd noticed for a long time that every mode is a little different. Different C-c special bindings doing similar things, or the same C-c binding doing the different things. This is something I addressed from the start with CEDET. Every mode-specific configuration fits in the CEDET infrastructure, not at the user interaction level. Parsers, project support, template support, etc can be provided for a language without consideration for how it might be used. The results are managed by the CEDET infrastructure, and tools built on top of that infrastructure will work for every language with support the same way. ECB is a great example of this language homogenization at work on a complex and very cool app. Getting the suite of tools in CEDET to do this wasn't that hard, but did take time. Finding tools I liked, figuring out the commonality between languages, and trying to make it "easy" to add language support was the first step, and there are lots of tools out there to start from. Many other "ui" like tools do the same. Anything and predictive come to mind. I don't want to claim that CEDET is the best thing going, but I do think that building up infrastructure for languages to add specialty support is what will make having consistent language support more likely, and thus make Emacs easier to learn for all languages. Eric Eric