On Monday, 27 October 2014 at 23:17:14 UTC, Rikki Cattermole wrote:
> Not to mention getting dscanner to output the correct line number/index ext. Fun times.

If the lexer is giving the wrong line numbers for tokens, I want to know about it. Do you have a file that reproduces this issue?

On Monday, 27 October 2014 at 23:50:22 UTC, Brian Schott wrote:
> On Monday, 27 October 2014 at 23:17:14 UTC, Rikki Cattermole wrote:
>> Not to mention getting dscanner to output the correct line number/index ext. Fun times.
>
> If the lexer is giving the wrong line numbers for tokens, I want to know about it. Do you have a file that reproduces this issue?

Not wrong numbers, just not outputting them with --ast (forked and working on it as I need it).
Although if it could also lex semi colons and whitespace it would be a huge help! (not needed).

On Monday, 27 October 2014 at 23:27:20 UTC, landaire wrote:
> On Monday, 27 October 2014 at 23:17:14 UTC, Rikki Cattermole wrote:
>> On Monday, 27 October 2014 at 22:06:28 UTC, landaire wrote:
>> I've also been playing with getting a Intellij IDEA plugin up but it utilises DScanner. The only issue I'm having right now is for some reason its adding two elements to the Psi's tree instead of just one. Where the second has correct data but first is the correct type.
>> Not to mention getting dscanner to output the correct line number/index ext. Fun times.
>
> Is your work published on GitHub or elsewhere? I'd like to take a look at your approach.

Not yet. But send me an email first@lastname.co.nz I'll either reply by that one or a gmail account (ssl certs). We can have a chat/send it to you about it.

On 27/10/2014 22:53, landaire wrote:
> On Monday, 27 October 2014 at 22:43:55 UTC, Jeremy Powers via
> Digitalmars-d wrote:
>>
>> From my mucking about before, I think you'll get more mileage from using
>> libdparse directly than trying to (re)implement a parser for the plugin.
>> For one, you save yourself all the pain of fixing weird edge cases and
>> keeping up to date.
>
> I agree, but integrating something external with IntelliJ's platform
> seems like kind of a PITA. It looks like a lot of stuff makes heavy use
> of PSI trees (see:
> https://confluence.jetbrains.com/display/IDEADEV/Developing+Custom+Language+Plugins+for+IntelliJ+IDEA#DevelopingCustomLanguagePluginsforIntelliJIDEA-ImplementingaParserandPSI)
>
>
> I'm no expert in developing IntelliJ plugins either though...

Have you considered the option of creating a Psi parser than creates PsiElements from the AST parsed by DDT's DTool ? That would should be fairly straightforward.

With of a fork of DDT/Dtool, you can even easily modify the DDT/Dtool parser to generate those PsiElements directly.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 27/10/2014 22:35, Jeremy Powers via Digitalmars-d wrote:
>
> An interesting path to take for an intellij plugin would be to use his
> DCD/libdparse for all the heavy lifting, with the plugin just farming
> out the work to external daemon process(es).  That would avoid having
> yet another lexer/parser implementation to keep up to date.

Integrating DCD might work well, because autocompletion is used sporadically (and is invoked explicitly by the user). But parsing is probably invoked quite often by IntelliJ, and as such it could be tricky to integrate with libdparse (because you'd have to invoke an external process all the time)

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 27/10/2014 22:06, landaire wrote:
> I'm trying to make a plugin for IntelliJ IDEA to support D
> (https://github.com/landaire/intelliD is what I have now utilizing DDT's
> lexer) but a lot of what's required to add advanced features like code
> folding, code completion, etc. is generally autogenerated by JetBrains's
> Grammar Kit plugin which only generates that stuff from a BNF grammar.

Nice to hear someone re-using DDT's DTool code for another tool. (it's called DTool BTW, not plugin_tooling - that's just the directory :P )

From https://github.com/landaire/intelliD:
"Backported to JDK 6 as the module made heavy use of JDK 7 and JDK 6 or lower is required for IntelliJ plugin development"

WUT?? That is so backwards... I even have a hard time believing that. (I'm no IntelliJ expert so I don't know for sure what is the case). But JDK 6 is getting quite old, 7 has been out for some time now, and is already superseded by 8 (and 9 is being concocted as we speak - the pace of Java changes has picked up now that Oracle took charge)

Are you really *sure* you can't write IntelliJ plugins with Java code using JDK 7 and above? IntelliJ is supposed to be Java IDE that is all fresh and up-to-date! (As opposed to Eclipse, whose code base has stagnated, I readily admit that, ;'( )

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

V Fri, 31 Oct 2014 11:41:58 +0000
Bruno Medeiros via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> On 27/10/2014 22:06, landaire wrote:
> > I'm trying to make a plugin for IntelliJ IDEA to support D (https://github.com/landaire/intelliD is what I have now utilizing DDT's lexer) but a lot of what's required to add advanced features like code folding, code completion, etc. is generally autogenerated by JetBrains's Grammar Kit plugin which only generates that stuff from a BNF grammar.
> 
> Nice to hear someone re-using DDT's DTool code for another tool. (it's called DTool BTW, not plugin_tooling - that's just the directory :P )
> 
>  From https://github.com/landaire/intelliD:
> "Backported to JDK 6 as the module made heavy use of JDK 7 and JDK 6
> or lower is required for IntelliJ plugin development"
> 
> WUT?? That is so backwards... I even have a hard time believing that. (I'm no IntelliJ expert so I don't know for sure what is the case). But JDK 6 is getting quite old, 7 has been out for some time now, and is already superseded by 8 (and 9 is being concocted as we speak - the pace of Java changes has picked up now that Oracle took charge)
> 
> Are you really *sure* you can't write IntelliJ plugins with Java code using JDK 7 and above? IntelliJ is supposed to be Java IDE that is all fresh and up-to-date! (As opposed to Eclipse, whose code base has stagnated, I readily admit that, ;'( )
> 

You can write intellij idea plugins with JDK 7 or even JDK 8, but that
plugins will only work with IDEA running on same version of JDK. You
must use same version for IDEA SDK and for IDEA itself. Currently
IDEA and all plugins are compatible with JDK 6, so this is why JDK 6 is
recommended.

At the moment many LTS linux distros has JDK 6 (ubuntu 12.04 LTS, RedHat/CentOS 6). But ubuntu 14.04 and readhat/centos 7 are here now, so maybe jdk7 will became recommended version soon.

On 1/11/2014 12:35 a.m., Bruno Medeiros wrote:
> On 27/10/2014 22:35, Jeremy Powers via Digitalmars-d wrote:
>>
>> An interesting path to take for an intellij plugin would be to use his
>> DCD/libdparse for all the heavy lifting, with the plugin just farming
>> out the work to external daemon process(es).  That would avoid having
>> yet another lexer/parser implementation to keep up to date.
>
> Integrating DCD might work well, because autocompletion is used
> sporadically (and is invoked explicitly by the user). But parsing is
> probably invoked quite often by IntelliJ, and as such it could be tricky
> to integrate with libdparse (because you'd have to invoke an external
> process all the time)

From my small test file with my attempt at this, its fine to call e.g. DScanner to grab the ast. Its actually pretty fast which I was a little shocked about.

On 31/10/2014 12:02, Daniel Kozák via Digitalmars-d wrote:
> You can write intellij idea plugins with JDK 7 or even JDK 8, but that
> plugins will only work with IDEA running on same version of JDK. You
> must use same version for IDEA SDK and for IDEA itself. Currently
> IDEA and all plugins are compatible with JDK 6, so this is why JDK 6 is
> recommended.

Ah, but that is totally fine then. It's actually the same scenario with Eclipse: The base Eclipse platform (and most official Eclipse plugins  - that is, the plugins released by eclipse.org) are made to run in JVM 6. But if you write a plugin that requires JVM 7, then you must run Eclipse with a JVM 7, naturally. (BTW, that's the case with DDT)

If you guys are writing an Intellij plugin for D, requiring the user to run it in a JVM 7 is perfectly reasonable. Even JVM 8 is trivial to install. There is not point in making your (the plugin developer's) life harder when installing a JVM 7 is trivial, in any OS.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 31/10/2014 12:16, Rikki Cattermole wrote:
> On 1/11/2014 12:35 a.m., Bruno Medeiros wrote:
>> On 27/10/2014 22:35, Jeremy Powers via Digitalmars-d wrote:
>>>
>>> An interesting path to take for an intellij plugin would be to use his
>>> DCD/libdparse for all the heavy lifting, with the plugin just farming
>>> out the work to external daemon process(es).  That would avoid having
>>> yet another lexer/parser implementation to keep up to date.
>>
>> Integrating DCD might work well, because autocompletion is used
>> sporadically (and is invoked explicitly by the user). But parsing is
>> probably invoked quite often by IntelliJ, and as such it could be tricky
>> to integrate with libdparse (because you'd have to invoke an external
>> process all the time)
>
>  From my small test file with my attempt at this, its fine to call e.g.
> DScanner to grab the ast. Its actually pretty fast which I was a little
> shocked about.
>

How fast is "pretty fast"? Milliseconds please.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros