lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs lily mode WAS: [announcement] Elysium - LilyPond IDE for Eclip


From: David Kastrup
Subject: Re: Emacs lily mode WAS: [announcement] Elysium - LilyPond IDE for Eclipse
Date: Thu, 15 Jul 2010 08:28:14 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Jan Nieuwenhuizen <address@hidden> writes:

> Op donderdag 01-07-2010 om 18:44 uur [tijdzone -0300], schreef Bernardo
> Barros:
>
>> Is the Emacs mode being actively also developed?  If so, is there a
>> project/repository somewhere?
>
> That depends.  We've had our emacs mode sitting in the elisp/ directory
> for quite a while.  I started a minimal thing hoping it would be fixed,
> and never put time into it.
>
> Nicolas wrote a more advanced thing, lyqi and recently David Kastrup
> mentioned he wanted to work on it.
>
> I think it would be nice if the efforts could be joined and have
> lyqi merged with lilypond's [new?] mode, or with emacs.

Well, it does not look like this is going to be a fast thing.

a) Nicolas has decided against using CEDET/Semantic for the parsing of
   Lilypond because of performance reasons.  That is a no-go for my
   tastes because of being Emacs fanboy: if Semantic is not good enough,
   it needs to be improved.  Fortunately, its performance problems are
   claimed to be mostly fixed.
b) I was banking on CEDET being an integral part of the Emacs
   development version.  That is not the case with regard to the
   development tools of CEDET allowing to _write_ new mode support
   rather than use existing ones (like c-mode support).
c) Nicolas' Scheme/Lisp/Elisp coding style is a world of its own heavily
   depending on whatever is available to make for some object oriented
   Common Lisp programming style, to a degree where the code is utterly
   unfathomable to people not familiar with the libraries providing the
   respective syntax macros.  Since those facilities are not "built-in"
   but heavily rely on macros and support functions, a lot of which are
   _not_ to be loaded at runtime for "standard" Emacs modes since they
   change Emacs' operation, one has to touch a lot of areas in order to
   convert the code into something that can at least _run_ without
   loading cl and stuff.

So this does not look like leading to a common project anytime soon.  As
a start, I am working on b), namely pestering CEDET developers to try
getting a version of CEDET useful (and documented) for writing new mode
support into Emacs.

a) is not going to fly for me: too much code to maintain separately from
Emacs main.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]