development plans for cedet / semantic / nxhtml

development plans for cedet / semantic / nxhtml

[Jack Tanner]

I'm asking this as a user, not a developer, but I think the question belongs 
here because it involves coordination of development plans. The short version of 
the question is: is there work afoot to create a nice IDE for writing web apps 
in a mixture of object-oriented PHP, JavaScript, CSS, and XHTML? If so, what 
will that involve? nXhtml? CEDET? Semantic? Other elements?

The long version is this. 

1) I'm using Emacs 23.2 and trying out the new CEDET / Semantic integration, and 
it's not quite "there" yet. For example, I enabled semantic-mode, and switched 
to a js-mode buffer. I keep getting this: "wisent-parse-stream: - Invalid start 
symbol bovine-inner-scope". Seems like a relative of the bug here:

http://comments.gmane.org/gmane.emacs.semantic/686

I could just file a bug report, although I don't know where this particular 
report belongs. But I can also imagine that since the CEDET / Semantic 
integration is completely new in 23.2, that the developers are aware of many 
little bugs, and such reports would just be noise to them and wasted time for 
me.

2) Upstream CEDET apparently has some support for PHP. I'm looking here:

http://cedet.sourceforge.net/languagesupport.shtml
http://permalink.gmane.org/gmane.emacs.cedet/4389

The Emacs 23.2 branch doesn't. Is that coming some day? If not, I should try to 
use upstream CEDET. But then I come across threads like this:

http://thread.gmane.org/gmane.emacs.cedet/4432

3) Right now, my IDE is essentially Emacs + nXhtml. It's working out OK, but 
there are some more sophisticated features I'd like to use (e.g., automated UML 
diagramming). Do CEDET and nXhtml play together? Or will they? What about 
features that both seem to want to provide, like completion?

At the end of the day, switching IDEs is not a trivial cost. The support and 
features of an IDE affect not only how you write code, but what kind of code you 
write. It plays into plans short-term and long. I can devote some chunk of time 
to getting a new environment working, but I don't want to do that if another 
reorganization with a steep learning curve is just down the road.

Re: development plans for cedet / semantic / nxhtml

[Chong Yidong]

Jack Tanner <ihok@hotmail.com> writes:

> Upstream CEDET apparently has some support for PHP. I'm looking here:
>
> http://cedet.sourceforge.net/languagesupport.shtml
> http://permalink.gmane.org/gmane.emacs.cedet/4389
>
> The Emacs 23.2 branch doesn't. Is that coming some day? If not, I
> should try to use upstream CEDET.

The author of the PHP parser in the contrib/ directory of the upstream
CEDET distribution is unwilling to sign a copyright assignment for it.

If someone would like to write a new parser and is willing to sign
papers, we could check it in.  Like the contrib/ parser, this new effort
can use the on the Java parser (which does have an assignment) as a
starting point.

Re: development plans for cedet / semantic / nxhtml

[Jack Tanner]

Chong Yidong <cyd <at> stupidchicken.com> writes:

> The author of the PHP parser in the contrib/ directory of the upstream
> CEDET distribution is unwilling to sign a copyright assignment for it.

Is the reason why COGRE is lacking something similar?

FWIW, I tried to use the cogre subdirectory of the upstream CEDET 1.0pre7 
tarball, and it doesn't work with the Emacs 23.2 CEDET. Maybe I'm missing 
something; backtrace below.

Debugger entered--Lisp error: (file-error "Cannot open load file" "srecode-
dictionary")
  require(srecode-dictionary)
  eval-buffer(#<buffer  *load*<4>> nil "c:/site-lisp/cogre/cogre-srecode.el" nil 
t)  ; Reading at buffer position 1067
  load-with-code-conversion("c:/site-lisp/cogre/cogre-srecode.el" "c:/site-
lisp/cogre/cogre-srecode.el" nil t)
  (cogre-srecode-setup)
  (eval-after-load "srecode-map" (cogre-srecode-setup))
  eval-buffer(#<buffer  *load*<3>> nil "c:/site-lisp/cogre/cogre-loaddefs.el" 
nil t)  ; Reading at buffer position 5852
  load-with-code-conversion("c:/site-lisp/cogre/cogre-loaddefs.el" "c:/site-
lisp/cogre/cogre-loaddefs.el" nil t)
  load("cogre-loaddefs" nil t)
  eval-buffer(#<buffer  *load*<2>> nil "c:/site-lisp/cogre/cogre-load.el" nil t)  
; Reading at buffer position 1054
  load-with-code-conversion("c:/site-lisp/cogre/cogre-load.el" "c:/site-
lisp/cogre/cogre-load.el" nil t)
  require(cogre-load)
  eval-buffer(#<buffer  *load*> nil "c:/site-lisp/cogre/cogre.el" nil t)  ; 
Reading at buffer position 1416
  load-with-code-conversion("c:/site-lisp/cogre/cogre.el" "c:/site-
lisp/cogre/cogre.el" nil nil)
  load("cogre")
  load-library("cogre")
  call-interactively(load-library t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)

Re: development plans for cedet / semantic / nxhtml

[Eric M. Ludlam]

On 05/18/2010 12:27 PM, Jack Tanner wrote:
> I'm asking this as a user, not a developer, but I think the question belongs
> here because it involves coordination of development plans. The short version of
> the question is: is there work afoot to create a nice IDE for writing web apps
> in a mixture of object-oriented PHP, JavaScript, CSS, and XHTML? If so, what
> will that involve? nXhtml? CEDET? Semantic? Other elements?

Hi,

I'll put in what my plans are, but what you are looking for requires 
more than just my efforts.

I'm trying to get upstream CEDET stabilized and better tested for 
Emacsen before 23.2, and XEmacs.  I think it's pretty close, but also 
slow going since I don't get a lot of time in the summer for this sort 
of thing.

After that, I want to convert my repository to match the file naming 
scheme in Emacs to simplify merges.

Once that is done I'm hoping to focus on the "interface" part, and 
remove the many UI parts that have organically grown over the past many 
years, and focus on integration.  I can't do that alone, as I don't use 
most of the languages that CEDET supports, nor do I have to even write 
code for my job anymore, so it will be a big effort in that respect to 
find all the common use cases and start tuning things to those situations.

 From a configuration point of view, I don't have a clear picture of 
that doing anything but getting simplified over time.

Eric