From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Tue, 13 Jul 2010 20:45:17 +0200 Message-ID: <87hbk3w79e.fsf@engster.org> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279046744 25174 80.91.229.12 (13 Jul 2010 18:45:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Jul 2010 18:45:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 13 20:45:43 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 1OYkU9-0004Hs-ME for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 20:45:42 +0200 Original-Received: from localhost ([127.0.0.1]:50620 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYkU9-0006w7-2C for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 14:45:41 -0400 Original-Received: from [140.186.70.92] (port=38961 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYkU1-0006tX-Cn for emacs-devel@gnu.org; Tue, 13 Jul 2010 14:45:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYkTz-0003nl-HS for emacs-devel@gnu.org; Tue, 13 Jul 2010 14:45:33 -0400 Original-Received: from m61s02.vlinux.de ([83.151.21.164]:60925) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYkTz-0003nY-2R; Tue, 13 Jul 2010 14:45:31 -0400 Original-Received: from dslc-082-083-062-014.pools.arcor-ip.net ([82.83.62.14] helo=spaten) by m61s02.vlinux.de with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1OYkTx-00079b-KP; Tue, 13 Jul 2010 20:45:29 +0200 In-Reply-To: <87bpabl55y.fsf@lola.goethe.zz> (David Kastrup's message of "Tue, 13 Jul 2010 18:26:01 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) Mail-Followup-To: David Kastrup , emacs-devel@gnu.org 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:127206 Archived-At: David Kastrup writes: > David Engster writes: > >> David Kastrup writes: >>> Well, cedet has no discernible documentation. It has no info file. >>> semantics has an info file. It talks about bovine and wisent parser >>> generators. It mentions their source files. They don't exist. Wisent >>> files presumably have an extension of .wy. The semantics documentation >>> claims that there is a mode for creating them. Opening a file with .wy >>> extension puts it in fundamental mode. There are no interactive >>> commands autoloaded starting with wisent- or bovin that would have >>> anything to do with writing language support using >>> Cedet/semantics/whatever. >> >> When the integration of CEDET was discussed, it was decided to leave the >> grammar development upstream. See >> >> http://thread.gmane.org/gmane.emacs.devel/115053/focus=115054 >> >> People who want to extend CEDET should always use its CVS version. > > This means that supporting new languages with CEDET means _extending_ > CEDET, and extending CEDET is apparently not possible with the CEDET > extract included in Emacs. > Whatever happened to "the preferred form for modification"? In short: yes, that is the current state of the CEDET merge. Longer explanation, as far as I remember it: It's not unusual for development of Emacs packages to happen primarily in their own projects (org, Gnus). However, CEDET is a bit special in this regard, because it has a pretty complicated build process, in which for example the grammars are converted to Emacs Lisp code. The grammar files are then not needed anymore. So a full CEDET merge would also require to merge this build process, but that's a pretty big task, and just getting a core CEDET into Emacs was difficult enough on its own. A full CEDET merge would be desirable; maybe it is possible for Emacs24. >> It seems this fact is not reflected in the documentation. > > Nor is it reflected in the beliefs of the people who state on-list that > since the time CEDET was "included" in Emacs distribution, it has become > inaccurate to state that Emacs does not come with a unified approach to > creating new language modes. 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. -David