Atom plugin?

[CRogers]

I was wondering if anyone had started an atom plugin for stack ide? It seems like you've set the groundwork with ghcjs support of the common project at least. If so, I'd love to help contribute. If not, I'd love to start building it.

[mgsloan]

As far as I know, no-one has started on this. Feel free to start building it, that would be awesome!

[drwebb]

@CRogers Good luck on the endevor, you might want to check out https://github.com/lukexi/stack-ide-sublime, which is the plugin that is the furthest along at the moment from my testing.

My wife just started getting into web dev, and I set her up with Atom. It would be great to see a plugin!

[lukexi]

Yes, I'm using stack-ide-sublime daily now (warts and all) since it's such a speed and simplicity improvement over SublimeHaskell — feel free to ask any questions!

I tried to document it decently so I hope it's helpful in getting an Atom version going; everything's in https://github.com/lukexi/stack-ide-sublime/blob/master/stack-ide.py

[parsonsmatt]

Aw, Sublime has one now? I really need to get around to writing the vim plugin... ;)

[snoyberg]

I for one eagerly await a vim plugin ☺

On Mon, Jul 13, 2015, 6:54 PM Matt Parsons [email protected] wrote:

Aw, Sublime has one now? I really need to get around to writing the vim
plugin...

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[huiwang]

@CRogers vote +1. I'm willing to try it too.

[CRogers]

@lukexi @drwebb stack-ide-sublime looks very cool. I tried to write my last haskell ide plugin for Sublime Text 3, SublimeGHCi, but got burned by Sublime's poor ETE test story (I had to build my own framework) and lack of docs. I'll get to work on building the Atom version - I'll try to just get autocomplete or some other simple feature working then release it to whoever wants to try it.

[CRogers]

Btw, this is happening (insert itshappening.gif) over at https://github.com/CRogers/stack-ide-atom. There's nothing interesting just yet (I've only got to the stage where I can read/write to processes) as I've made the (possibly dubious) decision to code the plugin in Haskell and compile to javascript via GHCJS.

[mgsloan]

Awesome! I'm really impressed with how well things work with GHCJS, so not that dubious of a decision. You may well end up with one of the largest atom plugins, though (in js size) :)

Let me know if you have any stack-ide / GHCJS questions and I'll try to help out!

I've got one unconventional idea for your effort, but it's up to you whether you want to try out this approach. The School of Haskell revamp uses the ace javascript editor. I got a bit tired of writing FFI definitions for it, and wanted something a bit less prone to errors. So in an evening or two I wrote the WIP version of ghcjs-from-typescript: https://github.com/fpco/ghcjs-from-typescript

It generates some raw GHCJS FFI stuff from a slightly modified https://github.com/borisyankov/DefinitelyTyped/blob/master/ace/ace.d.ts . The tool is very incomplete. I pretty much hacked on it till it accepted the ace definition and spit out usable FFI declarations.

I'd like to revisit the project, as it has the potential to give GHCJS reliable FFI bindings to many javascript packages. Here's the definition it's got for atom: https://github.com/borisyankov/DefinitelyTyped/blob/master/atom/atom.d.ts

From a skim, I don't see anything too strange, so I bet the tool is pretty close to being able to generate code from this definition.

[CRogers]

I was considering the idea of the a typescript-def to ffi compiler. It's great to see that you've made some progress one already. It's something I've tried before (for Fay) a while back but turned out to be way more complicated that I was expected. I'm severely time limited for this project so tempted just to manually add the little ffi I need but if it gets tedious I might look at getting ghcjs-from-typescript to work with atom :)

[drwebb]

To the moon!!! ┗(°0°)┛

On Sat, Jul 18, 2015 at 1:46 PM, Callum Rogers [email protected]
wrote:

Btw, this is happening (insert itshappening.gif) over at
https://github.com/CRogers/stack-ide-atom. There's nothing interesting
just yet (I've only got to the stage where I can read/write to processes)
as I've made the (possibly dubious) decision to code the plugin in Haskell
and compile to javascript via GHCJS.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[huiwang]

Hello @CRogers, it's great to hear about that. Could you please explain a little bit your approaches for developing this plugin? I'm a beginner both at Haskell and Atom.

After navigating rapidly the repo, it seems that

• instead of coffeescript you are trying to implement in haskell and compile it to javascript
• the stack ide modules are included in your repo

I'd like to understand why you've made such decisions.

Thanks

[CRogers]

Regarding why I chose to do this in Haskell rather than coffeescript:

• stack-ide already provides a haskell project for the json api. If I use
  Haskell I can build against that and get all the (de)serialisation for
  free. I also get static typechecking that I'm sending and recovering the
  right stuff. I expect this will be very useful as stack-ide is rapidly
  developed. This is the reason the sources for stack-ide and ide-backend are
  included in the repo (also that I prefer git subtree over git submodules).
• Haskell is generally a nicer language to work in as it has static
  typechecking, higher level abstractions and all the other goodness.
• This is a project that's almost entirely going to be used by haskellers,
  so building it in haskell means they are more likely to contribute/get
  involved. At least what put me off contributing to SublimeHaskell was the
  unwieldy mass of python.
• I'm building this in my free time. I already spend 40+ hours a week
  coding in coffeescript and frankly don't want to do that in my free time :p
  Doing it in Haskell is way more likely to make me actually work on it. That
  said, I expect I'll do the ETE tests in coffeescript, as I tried to use
  ghcjs for then last time and it was a huge pain.