Atom.io support?
Ciantic opened this issue · comments
I found this video: https://www.youtube.com/watch?v=RGiwiAoIn6w of fsharpbinding used in Atom, but it's not listed in here.
Maybe it was someones first try?
The autocomplete project is used by the atom F# support, but it's hosted in a separate repo.
On 18 Apr 2015, at 13:34, Jari Pennanen notifications@github.com wrote:
I found this video: https://www.youtube.com/watch?v=RGiwiAoIn6w of fsharpbinding used in Atom, but it's not listed in here.
Maybe it was someones first try?
—
Reply to this email directly or view it on GitHub.
There is an early prototype at https://github.com/Krzysztof-Cieslak/FSharp.Atom, which I would be happy to support here if the author wants to move it here or under fsprojects. It uses FSharp.AutoComplete like the emacs and vim support.
As discussed with @dsyme in https://github.com/Krzysztof-Cieslak/FSharp.Atom/issues/1 I don't see any problem with moving Fsharp.Atom project to fsprojects or to fsharpbindings. Just someone has to make a decision that it should be moved and where put it.
I think Atom requires it's a own repository and not a directory under this repo, it updates the packages from Github release tags if I've understood this right. So maybe fsharp/FSharp.Atom?
Perhaps we should have a more general discussion about whether editor support should live together in a single repo or be split out over individual repositories? With MD/XS moving out of the repo it would be nice to have a more consistent approach.
@kjnilsson Are you suggesting MS/XS was causing inconstancies?
@Ciantic fsharp/* is only reserved for uber core projects that have a history o being stable and maintained, it would likely go in fsprojects/* or a subdirectory of fsharp/fsharpbinding/
I would suggest separating concrete editor implementations to other repositories ( preferably under fsprojects). But again, my project is newest in the group and I will do what You guys decide.
I would be happy to have fsharp.AutoComplete in its own repository,
probably under fsharp still, and do github binary releases of it for the
editor packages to pull in. Then each editor could have its own repo under
fsharp or fsprojects. This would make distributing packages quite a bit
easier I imagine.
On 22 Apr 2015 14:22, "Krzysztof Cieślak" notifications@github.com wrote:
I would suggest separating concrete editor implementations to other
repositories ( preferably under fsprojects). But again, my project is
newest in the group and I will do what You guys decide.—
Reply to this email directly or view it on GitHub
#990 (comment)
.
Dave, I think Karl meant that as the XS support is moving out soon there
would be inconsistency between which editors have their support here and
which in separate repos. When will the XS move be complete?
On 22 Apr 2015 18:20, "Robin Neatherway" robin.neatherway@gmail.com wrote:
I would be happy to have fsharp.AutoComplete in its own repository,
probably under fsharp still, and do github binary releases of it for the
editor packages to pull in. Then each editor could have its own repo under
fsharp or fsprojects. This would make distributing packages quite a bit
easier I imagine.
On 22 Apr 2015 14:22, "Krzysztof Cieślak" notifications@github.com
wrote:I would suggest separating concrete editor implementations to other
repositories ( preferably under fsprojects). But again, my project is
newest in the group and I will do what You guys decide.—
Reply to this email directly or view it on GitHub
#990 (comment)
.
@7sharp9 any update? Then we could move forward on splitting the repo.
When 5.9 goes stable, probably the end of the month? All that needs doing is a 5.9 branch, then master can be zapped.
On 25 Apr 2015, at 12:01, Robin Neatherway notifications@github.com wrote:
@7sharp9 any update? Then we could move forward on splitting the repo.
—
Reply to this email directly or view it on GitHub.
Thanks Robin - yes that is what I meant - Sorry about the confusion Dave!.
:)
Robin - I think spitting fsautocomplete (and other related tools if there
are any) and having separate repos for each editor may be a good move. It
would also make the vim install process a bit more in line with other vim
plugins.
On Sat, 25 Apr 2015 at 13:07 Dave Thomas notifications@github.com wrote:
When 5.9 goes stable, probably the end of the month? All that needs doing
is a 5.9 branch, then master can be zapped.On 25 Apr 2015, at 12:01, Robin Neatherway notifications@github.com
wrote:@7sharp9 any update? Then we could move forward on splitting the repo.
—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub
#990 (comment)
.
@kjnilsson I was just kidding anyway :-)
@rneatherway Maybe tomorrow it will go stable
I would be interested in Sublime Text package ( see #996 ). One option is to host it under https://github.com/SublimeText org.
As it was suggested in this discussion I have decided to put my project under fsprojects organization.
https://github.com/fsprojects/FSharp.Atom
I'm not sure how install process looks like in the other plugins but here we decided to use develop branch which contains F# code and main branch which contains plugin in form required by Atom Package Manager.
In similar fashion we've created Paket plugin for Atom (https://github.com/fsprojects/Paket.Atom) but I guess it's another story.
From my point of view most important thing in short term is creating good way of getting fsautocomplete.exe - either put on nuget, or put compiled file on GitHub. Also it would be cool to add support for sln files - @kjnilsson already did some investigation on this topic.
In long term I think it's worth to discuss possibility of putting FSharpbindings on top of some kind server (different than standard I/O). @7sharp9, suggested also investigating possibility of working with Omnisharp team since they've discussed allowing plugins.
👍 for omnisharp integration as a binary delivery vehicle.
@Krzysztof-Cieslak I have asked for the repos to be split out. As soon as FSharp.AutoComplete is in its own repo I will create a binary release using the Github release mechanism. I agree with you that this is important. I'd be happy to review and merge work on sln support, what exactly do you have in mind? Adding and removing projects?
Using another kind of server is an interesting suggestion. What are the benefits of moving away from using a pipe?
Working with Omnisharp would definitely be interesting, especially for smoothly combining C# and F#.
I'm not sure if any work was done but reviewing some code and examples by @kjnilsson. Idea is to provide some way of parsing sln files (either by returning project list or parsing them) to get support for complex, multiple fsproj solutions in editors. Those were just early ideas and discussions, everything is open for setting up.
Again, different kind of server is also just an idea. I thing @7sharp9 has some more points. From my point of view it's just hard to do those I/O calls in Node.js (which works under the hood of Atom). With other kind of server ( maybe sockets ?) it should be easier to do async or fire & forget style requests.
But as I said, I would suggest checking what Omnisharp guys are doing and contacting with them - I know they've discussed plugins, our interest can make them do it / put more priority on it. Having common way of communication for both F# and Roslyn could be interesting.
Omnisharp use either kestrel or stdio wrapped in an async call in the same fashion, this means they can be easily swapped out and hosting can be made socket based. That said the format is http, but the stdio line format adds v8 debugger protocol to match up req/resp. Plugin will be MEF based but there are currently no contracts or interfaces decided. That's my brain dump for now.