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: Wed, 14 Jul 2010 07:43:42 -0400 Message-ID: <4C3DA2EE.7070607@siege-engine.com> References: <4C3B6A8A.80105@gmx.de> <87wrt0e81n.fsf@telefonica.net> <62E9699C07054418AB66F9C5FCB54E5C@us.oracle.com> <87sk3oe3la.fsf@telefonica.net> <1154D96E7D2F401D849266F359E44BB9@us.oracle.com> <87ocecdzou.fsf@telefonica.net> <87hbk4i1m4.fsf@uwakimon.sk.tsukuba.ac.jp> <87bpacdpwl.fsf@telefonica.net> <878w5fizcb.fsf@uwakimon.sk.tsukuba.ac.jp> <4C3C553D.9090203@siege-engine.com> <87vd8jlh4h.fsf@lola.goethe.zz> <87mxtvl7l6.fsf@lola.goethe.zz> <87r5j7webw.fsf@engster.org> <87bpabl55y.fsf@lola.goethe.zz> <87hbk3w79e.fsf@engster.org> <87wrsyhj5w.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1279107657 8131 80.91.229.12 (14 Jul 2010 11:40:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Jul 2010 11:40:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 14 13:40:55 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 1OZ0KV-0000r2-7R for ged-emacs-devel@m.gmane.org; Wed, 14 Jul 2010 13:40:52 +0200 Original-Received: from localhost ([127.0.0.1]:45894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZ0KT-0001Fd-5v for ged-emacs-devel@m.gmane.org; Wed, 14 Jul 2010 07:40:45 -0400 Original-Received: from [140.186.70.92] (port=48332 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZ092-00015f-AC for emacs-devel@gnu.org; Wed, 14 Jul 2010 07:28:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZ091-0002CP-73 for emacs-devel@gnu.org; Wed, 14 Jul 2010 07:28:56 -0400 Original-Received: from bird.interbax.net ([75.126.100.114]:36682) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZ091-0002CB-1V for emacs-devel@gnu.org; Wed, 14 Jul 2010 07:28:55 -0400 Original-Received: (qmail 4545 invoked from network); 14 Jul 2010 06:28:52 -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; 14 Jul 2010 06:28:52 -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: <87wrsyhj5w.fsf@uwakimon.sk.tsukuba.ac.jp> 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:127276 Archived-At: On 07/13/2010 10:49 PM, Stephen J. Turnbull wrote: > David Engster writes: > > > As you know, a language mode consists of different things. For instance > > font locking, indentation, accessing some kind of documentation, or > > communication with an interpreter. CEDET doesn't really immediately have > > much to do with those, although font locking could probably profit from > > a semantic parser and semantic tags can also contain documentation; > > indentation is entirely another beast, though. > > > > I think all that was said was that CEDET can provide stuff like semantic > > parsing, project support and template generation under a general > > framework, so that other tools (like ECB) can use that information, and > > therefore it might be possible to unify those areas of a language mode. > > Maybe that's all that was intended to be said, but the requirement was > for a unifying framework *now*, and it was claimed that CEDET fits the > bill. According to the description above, it does not. Instead, it > adds yet another set of semantics for overlaying on a text buffer. It > does not unify the existing sets (syntax highlighting, grinding, MMM > for mixed-language files, maybe others like project membership), and > it hasn't even been demonstrated that it *can*. I feel the need to both agree and disagree. I agree that CEDET is not a unifying force for *all* things a language mode may wish to do. I had responded to a couple different assertions. One was something David Kastrup wrote: | 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. My response was meant that CEDET is not a C/C++ only feature, but an infrastructure under which a mode can support code completion and the like. CEDET doesn't tackle keybindings or font lock since Emacs already does that. However, a suite of minor modes based on the infrastructure of CEDET can provide features (like code completion) which a mode author then does not need to implement themselves if a grammar is supplied. Thus, advanced major modes that try to solve some complex problems like code completion, compilation, or code generation could have a unified set of keybindings and behaviors for those features based on those minor modes. Hopefully that is more clear. A second thing I responded to was something Tom wrote: | Since we don't have a killer feature which would attract new | users like perfect code assist (context aware completion, instant | display of documentation of elements, live indication of syntax | errors, etc.) out of the box with near-zero configuration, we to which this current thread branch originates. The CEDET/Semantic tools can do these things such as code assist, display documentation (though you have to ask for it) and even live indication of some syntax errors. (A feature that could use some help in CEDET.) In theory, things like font-lock, or MMM mode features could work with the parsers CEDET/Semantic. I've participated in discussions on these topics to try and solve them, but they are not solved, so I agree there is no quick fix there. Eric