Thanks for the help. I will be looking more at the current plugins then for help on building mine.<br><br>On Wednesday, 18 April 2012, Milian Wolff  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tuesday 17 April 2012 20:58:54 Tatsh wrote:<br>
> I am looking into the KDevelop PHP plugin for ideas on how to properly<br>
> begin a plugin. I'd like to implement JavaScript support, including code<br>
> completion, type detection (via annotations and literal/new notation),<br>
> 'this' detection, etc.<br>
><br>
> I haven't been able to find any documentation on developing a plugin and<br>
> there is not a KDevelop template.<br>
<br>
Yes, we really need that... So far all we have is API-Documentation, our<br>
existing language plugins, and this email:<br>
<br>
<a href="http://barney.cs.uni-potsdam.de/pipermail/kdevelop/2011-January/016852.html" target="_blank">http://barney.cs.uni-potsdam.de/pipermail/kdevelop/2011-January/016852.html</a><br>
<br>
> Note about my system: using Gentoo generally stable amd64; currently have<br>
> KDE 4.8.2 installed via Portage.<br>
><br>
> A few questions:<br>
> - Which KDevelop version should I use?<br>
<br>
definitely git master<br>
<br>
> - Can I use external (differently licensed) sources for a parser such as<br>
> V8's?<br>
<br>
Yes, as long as it stays open source and redistributable. Afaiks KDevelop is<br>
mostly GPL and LGPL code. If the other license allows to link against such<br>
libs, then you should be fine.<br>
<br>
> - Does KDE have a JavaScript parser to build off of?<br>
<br>
KHTML has one somewhere. The question is whether that is reusable<br>
(copy'n'paste and minor adjustions) or whether deep changes are required.<br>
<br>
One alternative might be JavascriptCore<br>
<br>
> - Has anyone began such a project?<br>
<br>
Not to my knowledge - no.<br>
<br>
> If the last question's answer is no, my idea is to make a primitive parser<br>
> for the only absolutely necessary 'must be parsed by C++' part (primitives<br>
> like keywords, strings, and numbers). Once at that point, if there is<br>
> something that can run JavaScript (KJS?), then plain old JS can parse<br>
> things like Objects, Arrays, and other types (similar to parsing JSON but a<br>
> bit more complicated). This is similar to how Chrome parses JavaScript, and<br>
> probably makes for easier maintenance.<br>
<br>
I don't really get it. You need to construct an AST that needs to be accessed<br>
from C++ to report errors, build declarations, uses, contexts etc. pp. Imo you<br>
should rather try to find some JS parser that you can copy without too many<br>
changes (keep in mind that it might need to be updated later on - we don't<br>
want to maintain that if possible). Then use that parser to create an AST and<br>
with that you should be ready to go for a proper KDevelop language plugin.<br>
<br>
> The 'Class list' tool view would display any globally namespaced objects.<br>
> JSDoc annotations would be required for this to work generally. Example:<br>
><br>
> /**<br>
>  * @constructor<br>
>  */<br>
> var soCalledClass = function () {};<br>
> /**<br>
>  * @type number<br>
>  * @const<br>
>  */<br>
> var CONSTANT_VALUE = 1; // on the list as a, warning (red underline) if<br>
> this gets changed in code somewhere because @const<br>
> /**<br>
>  * @namespace My description.<br>
>  * @name namespace<br>
>  */<br>
> soCalledClass.namespace = {}; // shown after expanding the list<br>
> // Inheritance detection (shows up as separate item and under the<br>
> soCalledClass namespace):<br>
> /**<br>
>  * @constructor<br>
>  * @augments soCalledClass<br>
>  */<br>
> var inherits = function () {}<br>
> inherits.prototype = new soCalledClass();<br>
><br>
> ECMA3 with optional JSDoc annotations would be the first supported version.<br>
> And then of course ECMA5 and 6, including strict.<br>
<br>
Sounds good. One big task though might be to get the JS-specific scoping<br>
right. Not sure whether that might require special changes in our KDevplatform<br>
code since we so far mostly follow the "usual" scoping rules that apply to C-<br>
like languages but also work fine for Ruby and Python so far afaiks. But as<br>
far as I know, JS is pretty different in that regard.<br></blockquote><div><br></div><div>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)).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> After that, 'externs' files define things like what's in a browser<br>
> environment, what's available in node, etc. If you are familiar with<br>
> Closure Compiler, I am thinking to use their externs files (which include<br>
> nearly everything in all common browsers, including proprietary<br>
> extensions). This is similar to how phpfuncs.php includes all function<br>
> documentation in the PHP plugin.<br>
<br>
Yes that sounds good.<br>
<br>
> After that really works, another great thing would be Closure Compiler<br>
> integration, with parsing of the warnings and errors, and easy GUI-based<br>
> specification of arguments to the compiler.<br>
<br>
Jup but that would be another plugin unrelated to the language plugin. More<br>
like our makebuilder plugin e.g.<br>
<br>
Bye<br>
--<br>
Milian Wolff<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'mail@milianw.de')">mail@milianw.de</a><br>
<a href="http://milianw.de" target="_blank">http://milianw.de</a></blockquote>