FDT5 and HaXe

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

Nicolas Cannasse
Le 27/10/2011 21:37, Philippe Elsass a écrit :
> I'm a bit disappointed to hear people are disappointed by FDT5's haxe
> support
> - I sincerely hope they will improve that because then it may get
> traction in "serious shops".

Same here.

> I don't want to bring down all this motivation about creating a new IDE,
> but...
> - bringing together CoreMirror (very impressive BTW) + haxe compiler's
> --display + a little bit of project management would be very reasonable
> (and fun) project,
> - then adding all the other features that one will expect from an IDE is
> a hell of a lot of work: find/replace in
> files, templates/config, debugging, refactoring, etc.

Of course, I completely agree with you here.

There is a huge difference between a code editor and an IDE.

But haXe being IDE agnostic, I was thinking that having a small
haXe-written editor would not be a bad idea and would complete the other
IDE supports.

> BTW @Nicolas you could help by providing:
> - some "--find-declaration" switch which would return member meta infos
> (type, declaration file/position) to easily enable jump-to-declaration
> features in editors,
> - what about "--find-uses" which would return all the locations where
> the element is used (think refactoring)?

I think that both - and especially the first - can actually be
implemented with macros without touching the compiler.

> - documentation in completion (pretty please).

Yes, there's still some issue with the resuming parser "eating"
comments. Could you add it as a issue on googlecode ? This way it does
get remembered.

Best,
Nicolas



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

Tarwin Stroh-Spijer
Would -find-uses and -find-declaration be a lot faster if it is in the compiler though? Speed is a big-ish issue when it comes to IDEs though at least for refactoring you don't care about that. But if it took a second when I went to declaration it could be annoying.

Regards, 


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Fri, Oct 28, 2011 at 7:27 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 27/10/2011 21:37, Philippe Elsass a écrit :

I'm a bit disappointed to hear people are disappointed by FDT5's haxe
support
- I sincerely hope they will improve that because then it may get
traction in "serious shops".

Same here.


I don't want to bring down all this motivation about creating a new IDE,
but...
- bringing together CoreMirror (very impressive BTW) + haxe compiler's
--display + a little bit of project management would be very reasonable
(and fun) project,
- then adding all the other features that one will expect from an IDE is
a hell of a lot of work: find/replace in
files, templates/config, debugging, refactoring, etc.

Of course, I completely agree with you here.

There is a huge difference between a code editor and an IDE.

But haXe being IDE agnostic, I was thinking that having a small haXe-written editor would not be a bad idea and would complete the other IDE supports.


BTW @Nicolas you could help by providing:
- some "--find-declaration" switch which would return member meta infos
(type, declaration file/position) to easily enable jump-to-declaration
features in editors,
- what about "--find-uses" which would return all the locations where
the element is used (think refactoring)?

I think that both - and especially the first - can actually be implemented with macros without touching the compiler.


- documentation in completion (pretty please).

Yes, there's still some issue with the resuming parser "eating" comments. Could you add it as a issue on googlecode ? This way it does get remembered.

Best,
Nicolas



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

Dion Whitehead Amago
In reply to this post by Elsass Philippe
I'd like to plug jEdit again.  My haxe plugin is pretty basic (and
could use more love), but jEdit itself gives you project management,
error navigation, and tons of other features all available via
optional plugins. It's open source and cross platform (Java). I know
Java has a bad rap for desktop apps, but IMO this one is an exception
simply due to it's utility and extensibility and cross platform
nature.

On Thu, Oct 27, 2011 at 2:37 PM, Philippe Elsass
<[hidden email]> wrote:

> I'm a bit disappointed to hear people are disappointed by FDT5's haxe
> support
> - I sincerely hope they will improve that because then it may get traction
> in "serious shops".
>
> I don't want to bring down all this motivation about creating a new IDE,
> but...
> - bringing together CoreMirror (very impressive BTW) + haxe compiler's
> --display + a little bit of project management would be very reasonable (and
> fun) project,
> - then adding all the other features that one will expect from an IDE is a
> hell of a lot of work: find/replace in files, templates/config, debugging,
> refactoring, etc.
> Which means I gladly welcome projects based on existing editors/IDEs: gedit,
> SublimeText (I'm a fan), MonoDevelop (C# so could reuse some FD code),
> TextMate, vim, etc.
>
> BTW @Nicolas you could help by providing:
> - some "--find-declaration" switch which would return member meta infos
> (type, declaration file/position) to easily enable jump-to-declaration
> features in editors,
> - what about "--find-uses" which would return all the locations where the
> element is used (think refactoring)?
> - documentation in completion (pretty please).
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

singmajesty
In reply to this post by Tarwin Stroh-Spijer
I think that speed is more important for -display. The completion in  
FlashDevelop is fast because it has its own parsing, independent of the  
haxe compiler.

I wonder if it would speed things up if it were possible to keep a running  
compiler instance, similar to FCSH, to provide completion?


On Thu, 27 Oct 2011 14:13:43 -0700, Tarwin Stroh-Spijer  
<[hidden email]> wrote:

> Would -find-uses and -find-declaration be a lot faster if it is in the
> compiler though? Speed is a big-ish issue when it comes to IDEs though at
> least for refactoring you don't care about that. But if it took a second
> when I went to declaration it could be annoying.
>
> Regards,
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: +61 3 8060 5321
> _______________________
>
>
> On Fri, Oct 28, 2011 at 7:27 AM, Nicolas Cannasse  
> <[hidden email]
>> wrote:
>
>> Le 27/10/2011 21:37, Philippe Elsass a écrit :
>>
>>  I'm a bit disappointed to hear people are disappointed by FDT5's haxe
>>> support
>>> - I sincerely hope they will improve that because then it may get
>>> traction in "serious shops".
>>>
>>
>> Same here.
>>
>>
>>  I don't want to bring down all this motivation about creating a new  
>> IDE,
>>> but...
>>> - bringing together CoreMirror (very impressive BTW) + haxe compiler's
>>> --display + a little bit of project management would be very reasonable
>>> (and fun) project,
>>> - then adding all the other features that one will expect from an IDE  
>>> is
>>> a hell of a lot of work: find/replace in
>>> files, templates/config, debugging, refactoring, etc.
>>>
>>
>> Of course, I completely agree with you here.
>>
>> There is a huge difference between a code editor and an IDE.
>>
>> But haXe being IDE agnostic, I was thinking that having a small
>> haXe-written editor would not be a bad idea and would complete the  
>> other IDE
>> supports.
>>
>>
>>  BTW @Nicolas you could help by providing:
>>> - some "--find-declaration" switch which would return member meta infos
>>> (type, declaration file/position) to easily enable jump-to-declaration
>>> features in editors,
>>> - what about "--find-uses" which would return all the locations where
>>> the element is used (think refactoring)?
>>>
>>
>> I think that both - and especially the first - can actually be  
>> implemented
>> with macros without touching the compiler.
>>
>>
>>  - documentation in completion (pretty please).
>>>
>>
>> Yes, there's still some issue with the resuming parser "eating"  
>> comments.
>> Could you add it as a issue on googlecode ? This way it does get  
>> remembered.
>>
>> Best,
>> Nicolas
>>
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

sledorze


On Fri, Oct 28, 2011 at 12:50 AM, singmajesty [via Haxe] <[hidden email]> wrote:
I think that speed is more important for -display. The completion in  
FlashDevelop is fast because it has its own parsing, independent of the  
haxe compiler.
 
What makes you believe that? I don't think so as it provides completion which includes macros results..
 
I wonder if it would speed things up if it were possible to keep a running  
compiler instance, similar to FCSH, to provide completion?
 

On Thu, 27 Oct 2011 14:13:43 -0700, Tarwin Stroh-Spijer  
<[hidden email]> wrote:

> Would -find-uses and -find-declaration be a lot faster if it is in the
> compiler though? Speed is a big-ish issue when it comes to IDEs though at
> least for refactoring you don't care about that. But if it took a second
> when I went to declaration it could be annoying.
>
> Regards,
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321
> _______________________
>
>
> On Fri, Oct 28, 2011 at 7:27 AM, Nicolas Cannasse  
> <[hidden email]
>> wrote:
>
>> Le 27/10/2011 21:37, Philippe Elsass a écrit :
>>
>>  I'm a bit disappointed to hear people are disappointed by FDT5's haxe
>>> support
>>> - I sincerely hope they will improve that because then it may get
>>> traction in "serious shops".
>>>
>>
>> Same here.
>>
>>
>>  I don't want to bring down all this motivation about creating a new  
>> IDE,
>>> but...
>>> - bringing together CoreMirror (very impressive BTW) + haxe compiler's
>>> --display + a little bit of project management would be very reasonable
>>> (and fun) project,
>>> - then adding all the other features that one will expect from an IDE  
>>> is
>>> a hell of a lot of work: find/replace in
>>> files, templates/config, debugging, refactoring, etc.
>>>
>>
>> Of course, I completely agree with you here.
>>
>> There is a huge difference between a code editor and an IDE.
>>
>> But haXe being IDE agnostic, I was thinking that having a small
>> haXe-written editor would not be a bad idea and would complete the  
>> other IDE
>> supports.
>>
>>
>>  BTW @Nicolas you could help by providing:
>>> - some "--find-declaration" switch which would return member meta infos
>>> (type, declaration file/position) to easily enable jump-to-declaration
>>> features in editors,
>>> - what about "--find-uses" which would return all the locations where
>>> the element is used (think refactoring)?
>>>
>>
>> I think that both - and especially the first - can actually be  
>> implemented
>> with macros without touching the compiler.
>>
>>
>>  - documentation in completion (pretty please).
>>>
>>
>> Yes, there's still some issue with the resuming parser "eating"  
>> comments.
>> Could you add it as a issue on googlecode ? This way it does get  
>> remembered.
>>
>> Best,
>> Nicolas
>>
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
--
haXe - an open source web programming language
http://haxe.org



If you reply to this email, your message will be added to the discussion below:
http://haxe.1354130.n2.nabble.com/FDT5-and-HaXe-tp6934213p6938319.html
To unsubscribe from FDT5 and HaXe, click here.



--
Stéphane Le Dorze


Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

singmajesty
To my knowledge, FlashDevelop has a completion engine that is independent  
of the haxe compiler. FlashDevelop already provides completion for  
Actionscript 2 and Actionscript 3, which do not have compiler-based  
completion. Providing support for haxe, in most ways, is likely similar. I  
believe it uses its own type completion, but then merges the results of  
hitting the haxe compiler (which takes longer), particularly when  
something is unknown.

I didn't write it, though, so I won't pretend to be the expert :)



On Thu, 27 Oct 2011 16:15:03 -0700, sledorze <[hidden email]>  
wrote:

> On Fri, Oct 28, 2011 at 12:50 AM, singmajesty [via Haxe] <
> [hidden email]> wrote:
>
>> I think that speed is more important for -display. The completion in
>> FlashDevelop is fast because it has its own parsing, independent of the
>> haxe compiler.
>>
>
> What makes you believe that? I don't think so as it provides completion
> which includes macros results..
>
>
>> I wonder if it would speed things up if it were possible to keep a  
>> running
>>
>> compiler instance, similar to FCSH, to provide completion?
>>
>>
>
>> On Thu, 27 Oct 2011 14:13:43 -0700, Tarwin Stroh-Spijer
>> <[hidden email] <http://user/SendEmail.jtp?type=node&node=6938319&i=0>>
>> wrote:
>>
>> > Would -find-uses and -find-declaration be a lot faster if it is in the
>> > compiler though? Speed is a big-ish issue when it comes to IDEs  
>> though at
>>
>> > least for refactoring you don't care about that. But if it took a  
>> second
>> > when I went to declaration it could be annoying.
>> >
>> > Regards,
>> >
>> >
>> > Tarwin Stroh-Spijer
>> > _______________________
>> >
>> > Touch My Pixel
>> > http://www.touchmypixel.com/
>> > phone: +61 3 8060 5321
>> > _______________________
>> >
>> >
>> > On Fri, Oct 28, 2011 at 7:27 AM, Nicolas Cannasse
>> > <[hidden email] <http://user/SendEmail.jtp?type=node&node=6938319&i=1>
>> >> wrote:
>> >
>> >> Le 27/10/2011 21:37, Philippe Elsass a écrit :
>> >>
>> >>  I'm a bit disappointed to hear people are disappointed by FDT5's  
>> haxe
>> >>> support
>> >>> - I sincerely hope they will improve that because then it may get
>> >>> traction in "serious shops".
>> >>>
>> >>
>> >> Same here.
>> >>
>> >>
>> >>  I don't want to bring down all this motivation about creating a new
>> >> IDE,
>> >>> but...
>> >>> - bringing together CoreMirror (very impressive BTW) + haxe  
>> compiler's
>> >>> --display + a little bit of project management would be very  
>> reasonable
>>
>> >>> (and fun) project,
>> >>> - then adding all the other features that one will expect from an  
>> IDE
>>
>> >>> is
>> >>> a hell of a lot of work: find/replace in
>> >>> files, templates/config, debugging, refactoring, etc.
>> >>>
>> >>
>> >> Of course, I completely agree with you here.
>> >>
>> >> There is a huge difference between a code editor and an IDE.
>> >>
>> >> But haXe being IDE agnostic, I was thinking that having a small
>> >> haXe-written editor would not be a bad idea and would complete the
>> >> other IDE
>> >> supports.
>> >>
>> >>
>> >>  BTW @Nicolas you could help by providing:
>> >>> - some "--find-declaration" switch which would return member meta  
>> infos
>>
>> >>> (type, declaration file/position) to easily enable  
>> jump-to-declaration
>> >>> features in editors,
>> >>> - what about "--find-uses" which would return all the locations  
>> where
>> >>> the element is used (think refactoring)?
>> >>>
>> >>
>> >> I think that both - and especially the first - can actually be
>> >> implemented
>> >> with macros without touching the compiler.
>> >>
>> >>
>> >>  - documentation in completion (pretty please).
>> >>>
>> >>
>> >> Yes, there's still some issue with the resuming parser "eating"
>> >> comments.
>> >> Could you add it as a issue on googlecode ? This way it does get
>> >> remembered.
>> >>
>> >> Best,
>> >> Nicolas
>> >>
>> >>
>> >>
>> >> --
>> >> haXe - an open source web programming language
>> >> http://haxe.org
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the  
>> discussion
>> below:
>> http://haxe.1354130.n2.nabble.com/FDT5-and-HaXe-tp6934213p6938319.html
>>  To unsubscribe from FDT5 and HaXe, click  
>> here<
>>
>>
>
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

Elsass Philippe
In reply to this post by kubson
@sledorze @joshua
That's true FD is using both haxe --display and built-in haxe parser/completion to (hopefully) provide the best of both worlds. It's not about merging results, but in some situations FD completion engine has enough information to provide code completion without having to run the compiler.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

Nicolas Cannasse
Le 28/10/2011 11:08, Philippe Elsass a écrit :
> @sledorze @joshua
> That's true FD is using both haxe --display and built-in haxe
> parser/completion to (hopefully) provide the best of both worlds. It's
> not about merging results, but in some situations FD completion engine
> has enough information to provide code completion without having to run
> the compiler.

As soon as there's one "using" or some more macro involved, FD will not
be able to display the accurate completion (unless it reproduces haXe
algorithms which I think is not really feasible).

We already talked before that it would be nice to display FD-based
completion tip first (immediately) and then run haXe --display in the
background and update the completion tip as soon as we get the results
(or kill the process if the user kills the tip).

This behavior will definitely be needed if we want to have
compiler-based toplevel completion (that is, completion of the available
identifiers, not only objects fields and methods parameters).

Any thoughts/progress on that ?

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and HaXe

Nikolay Krasko
In reply to this post by Daniel Uranga
Hello,

Nope, development for eclipse is easy enough. And I can tell you for sure that the only problem of the eclihx project currently is lack of time. The are a lot of huge and small technical improvements that should be done for comfortable coding, nothing is really difficult: make auto indentation, caching for auto-complete tips to make them faster, add local variables and class names to auto-complete. After that parser should be added to provide some basic refactorings.  What else?

Flash develop is cool. Mainly because it currently make use wisely similarities in syntax and semantic of haXe and ActionScript. But I'm still sure that plugin for eclipse is more prospective. It's already have multiplatform support and integration with bunch of eclipse plugins. For example I have successfully tried to use eclihx with Aptana (http://www.aptana.com/) for using JS target. Will try to make a video tutorial soon. I don't believe that there will be plugins for FlashDevelop for other haXe targets in the near future. Next point is that haXe and ActionScript are currently have important differences and soon FlashDevelop plugin will also need time investment for development to stay actual.

I also don't believe in idea of creating full-featured IDE for haXe from scratch. Sorry. The problem that after "interesting-fun-challenge" stage there's will be "a-lot-of-work" stage. And you will still need to implement "make auto indentation, caching for auto-complete tips to make them faster, add local variables and class names to auto-complete". And that's exact position where eclihx is now. After that there should be either some sponsor support, internal motivation or community help. 

So if you a ready to do something for a better IDE for haXe appeared, I suggest to take a look to eclihx project and implement some feature or fix a bug :)

Nikolay Krasko.





2011/10/27 Daniel Uranga <[hidden email]>
A multiplatform open source solution with the level of quality of FlashDevelop would be awesome. I think that a MonoDevelop plugin could do that.
An eclipse plugin would be cool, but it seems to hard to do (neither FDT nor eclihx can compete with FlashDevelop).

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and HaXe

Elsass Philippe
In reply to this post by kubson
There definitely is room for an Eclipse plugin and if EcliHx is in good shape it would really be worth helping @Nikolay as it may be (remember ASDT?) the beginning of haxe in Eclipse shops. And yes, even if I don't like Eclipse, it's important to have it on the haxe ecosystem's map :)

Not sure about the other points @Nikolay makes, but FD does use haxe compiler for code completion so it should stay generally current. Also FD supports all the known haxe targets, including NME's specific install tool. 

@Nicolas currently FD completion is only used in a few edge cases and falls back to --display if it doesn't work. I'm definitely keeping in mind the idea to run --display in the background also. 

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

Juraj Kirchheim
In reply to this post by Nicolas Cannasse
>> BTW @Nicolas you could help by providing:
>> - some "--find-declaration" switch which would return member meta infos
>> (type, declaration file/position) to easily enable jump-to-declaration
>> features in editors,

The point is, if you have "foo".startsWith("f") when using
StringTools, it would be nice to be able to jump to the declaration of
startsWith, which is actually StringTools.startsWith. Maybe I have
overlooked something, but I can't see a way to do that with macros.
Some switch that will resolve the meaning of an identifier at the
given position would be really nice (be it a field, method, extension
method, local variable/parameter, enum constructor, class, typedef).

On a different note:
Would it be possible to have a compiler switch to just get back the
tokens of a given file (whitespaces and comments included) from line x
to line y (and possibly leading and trailing multiline tokens)? It
seems quite redundant to have this happen individually per IDE.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and Haxe

Cauê W.
Yeah, you're right. There's no way to do that with macros.

2011/10/28 Juraj Kirchheim <[hidden email]>
>> BTW @Nicolas you could help by providing:
>> - some "--find-declaration" switch which would return member meta infos
>> (type, declaration file/position) to easily enable jump-to-declaration
>> features in editors,

The point is, if you have "foo".startsWith("f") when using
StringTools, it would be nice to be able to jump to the declaration of
startsWith, which is actually StringTools.startsWith. Maybe I have
overlooked something, but I can't see a way to do that with macros.
Some switch that will resolve the meaning of an identifier at the
given position would be really nice (be it a field, method, extension
method, local variable/parameter, enum constructor, class, typedef).

On a different note:
Would it be possible to have a compiler switch to just get back the
tokens of a given file (whitespaces and comments included) from line x
to line y (and possibly leading and trailing multiline tokens)? It
seems quite redundant to have this happen individually per IDE.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and HaXe

Blue Sans douze
In reply to this post by Matthew Spencer-2
I'm really interested in that.
Please keep me in touch.
-Blue112


2011/10/27 Matthew Spencer <[hidden email]>
I've got a sublimetext plugin sitting at bout 60% to milestone one. Will try to release ASAP if people are interested.
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and HaXe

Alex Liebert
maybe we should just spread out one P/invoke in the flashdevelop source per haxe community member and pledge to port that bit to os x :)

On Sat, Oct 29, 2011 at 11:45 AM, Blue Sans douze <[hidden email]> wrote:
I'm really interested in that.
Please keep me in touch.
-Blue112


2011/10/27 Matthew Spencer <[hidden email]>
I've got a sublimetext plugin sitting at bout 60% to milestone one. Will try to release ASAP if people are interested.
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and HaXe

Elsass Philippe
Haha that and rewriting Scintilla .NET wrapper to work with the MacOS version of the DLL ;)

On Wed, Nov 2, 2011 at 10:31 PM, Alex Liebert <[hidden email]> wrote:
maybe we should just spread out one P/invoke in the flashdevelop source per haxe community member and pledge to port that bit to os x :)


On Sat, Oct 29, 2011 at 11:45 AM, Blue Sans douze <[hidden email]> wrote:
I'm really interested in that.
Please keep me in touch.
-Blue112


2011/10/27 Matthew Spencer <[hidden email]>
I've got a sublimetext plugin sitting at bout 60% to milestone one. Will try to release ASAP if people are interested.
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Philippe

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and HaXe

Michiel Crefcoeur
Just so you guys know:
Cloud9 IDE has recently added code completion.
It's a web-based IDE using NodeJS with GitHub and BitBucket integration.
Here's the repo, if anyone's interested in adding haXe support (haXe syntax highlighting definitions and code completion using WebSockets/XMLHttpRequest)



2011/11/2 Philippe Elsass <[hidden email]>
Haha that and rewriting Scintilla .NET wrapper to work with the MacOS version of the DLL ;)


On Wed, Nov 2, 2011 at 10:31 PM, Alex Liebert <[hidden email]> wrote:
maybe we should just spread out one P/invoke in the flashdevelop source per haxe community member and pledge to port that bit to os x :)


On Sat, Oct 29, 2011 at 11:45 AM, Blue Sans douze <[hidden email]> wrote:
I'm really interested in that.
Please keep me in touch.
-Blue112


2011/10/27 Matthew Spencer <[hidden email]>
I've got a sublimetext plugin sitting at bout 60% to milestone one. Will try to release ASAP if people are interested.
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Philippe

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: FDT5 and HaXe

Tony Polinelli
looking at cloud9 now - it seems like it might work perfectly with haxe (the local version). It would be great to explore adding compiler autocompletion. It would definately reduce alot of the work required to making a browser based IDE (which people keep talking about making) 



On Wed, Nov 2, 2011 at 8:20 PM, Michiel Crefcoeur <[hidden email]> wrote:
Just so you guys know:
Cloud9 IDE has recently added code completion.
It's a web-based IDE using NodeJS with GitHub and BitBucket integration.
Here's the repo, if anyone's interested in adding haXe support (haXe syntax highlighting definitions and code completion using WebSockets/XMLHttpRequest)



2011/11/2 Philippe Elsass <[hidden email]>
Haha that and rewriting Scintilla .NET wrapper to work with the MacOS version of the DLL ;)


On Wed, Nov 2, 2011 at 10:31 PM, Alex Liebert <[hidden email]> wrote:
maybe we should just spread out one P/invoke in the flashdevelop source per haxe community member and pledge to port that bit to os x :)


On Sat, Oct 29, 2011 at 11:45 AM, Blue Sans douze <[hidden email]> wrote:
I'm really interested in that.
Please keep me in touch.
-Blue112


2011/10/27 Matthew Spencer <[hidden email]>
I've got a sublimetext plugin sitting at bout 60% to milestone one. Will try to release ASAP if people are interested.
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Philippe

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Tony Polinelli
http://touchmypixel.com

--
haXe - an open source web programming language
http://haxe.org
12