JavaScript plugin

[Milian Wolff]

On Tuesday 17 April 2012 20:58:54 Tatsh wrote:
> I am looking into the KDevelop PHP plugin for ideas on how to properly
> begin a plugin. I'd like to implement JavaScript support, including code
> completion, type detection (via annotations and literal/new notation),
> 'this' detection, etc.
> 
> I haven't been able to find any documentation on developing a plugin and
> there is not a KDevelop template.

Yes, we really need that... So far all we have is API-Documentation, our 
existing language plugins, and this email:

http://barney.cs.uni-potsdam.de/pipermail/kdevelop/2011-January/016852.html

> Note about my system: using Gentoo generally stable amd64; currently have
> KDE 4.8.2 installed via Portage.
> 
> A few questions:
> - Which KDevelop version should I use?

definitely git master

> - Can I use external (differently licensed) sources for a parser such as
> V8's?

Yes, as long as it stays open source and redistributable. Afaiks KDevelop is 
mostly GPL and LGPL code. If the other license allows to link against such 
libs, then you should be fine.

> - Does KDE have a JavaScript parser to build off of?

KHTML has one somewhere. The question is whether that is reusable 
(copy'n'paste and minor adjustions) or whether deep changes are required.

One alternative might be JavascriptCore

> - Has anyone began such a project?

Not to my knowledge - no.

> If the last question's answer is no, my idea is to make a primitive parser
> for the only absolutely necessary 'must be parsed by C++' part (primitives
> like keywords, strings, and numbers). Once at that point, if there is
> something that can run JavaScript (KJS?), then plain old JS can parse
> things like Objects, Arrays, and other types (similar to parsing JSON but a
> bit more complicated). This is similar to how Chrome parses JavaScript, and
> probably makes for easier maintenance.

I don't really get it. You need to construct an AST that needs to be accessed 
from C++ to report errors, build declarations, uses, contexts etc. pp. Imo you 
should rather try to find some JS parser that you can copy without too many 
changes (keep in mind that it might need to be updated later on - we don't 
want to maintain that if possible). Then use that parser to create an AST and 
with that you should be ready to go for a proper KDevelop language plugin.

> The 'Class list' tool view would display any globally namespaced objects.
> JSDoc annotations would be required for this to work generally. Example:
> 
> /**
>  * @constructor
>  */
> var soCalledClass = function () {};
> /**
>  * @type number
>  * @const
>  */
> var CONSTANT_VALUE = 1; // on the list as a, warning (red underline) if
> this gets changed in code somewhere because @const
> /**
>  * @namespace My description.
>  * @name namespace
>  */
> soCalledClass.namespace = {}; // shown after expanding the list
> // Inheritance detection (shows up as separate item and under the
> soCalledClass namespace):
> /**
>  * @constructor
>  * @augments soCalledClass
>  */
> var inherits = function () {}
> inherits.prototype = new soCalledClass();
> 
> ECMA3 with optional JSDoc annotations would be the first supported version.
> And then of course ECMA5 and 6, including strict.

Sounds good. One big task though might be to get the JS-specific scoping 
right. Not sure whether that might require special changes in our KDevplatform 
code since we so far mostly follow the "usual" scoping rules that apply to C-
like languages but also work fine for Ruby and Python so far afaiks. But as 
far as I know, JS is pretty different in that regard.

> After that, 'externs' files define things like what's in a browser
> environment, what's available in node, etc. If you are familiar with
> Closure Compiler, I am thinking to use their externs files (which include
> nearly everything in all common browsers, including proprietary
> extensions). This is similar to how phpfuncs.php includes all function
> documentation in the PHP plugin.

Yes that sounds good.

> After that really works, another great thing would be Closure Compiler
> integration, with parsing of the warnings and errors, and easy GUI-based
> specification of arguments to the compiler.

Jup but that would be another plugin unrelated to the language plugin. More 
like our makebuilder plugin e.g.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120418/31784328/attachment.sig>