JavaScript plugin

[Tatsh]

Thanks for the help. I will be looking more at the current plugins then for
help on building mine.

On Wednesday, 18 April 2012, Milian Wolff wrote:

> 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.
>

I don't know if you have implemented any support for PHP's closures, but
that also changes scope in a somewhat similar way. The only difference is
that PHP requires the use() construct to inject variables from the
outer-scope into the closure (and I think still requires global keyword to
get global variables). I think if any changes need to be made to KDevelop,
it would be effective for both JavaScript and PHP. It might even be helpful
in two other cases: gnu99 C where a closure-like functionality exists, and
closures in C/Objective-C/C++ (^ returntype (arg1, arg2) { /* body */ }
syntax (also known as blocks)).


>
> > 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 <javascript:;>
> http://milianw.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120418/d14fdad2/attachment.html>