F# interactive in Emacs (mono)

[Eduardo Muñoz]

(sorry if this is repeated, I posted it using google groups but it didn't show up after posting it)

I've been advised to ask this question here (http://stackoverflow.com/questions/13088660/how-to-run-f-interactive-in-emacs-nix)

I've been trying for a week to get F# interactive working in Emacs and I haven't been able to.

The problem is that whenever I run "fsi" or "fsharpi" (either using fsharp mode or in a shell buffer), the buffer becomes unresponsive. I check the system monitor and see a mono process using 100% CPU and obviously anything I type doesn't get evaluated.

I've tried this on Emacs 24.1 and 23.2; also on OS X, Linux Mint and Fedora, and all cause the same exact problem.

I've tried different versions of mono (2.10.9, 3.0 and 2.8 on OS X; 2.10.8.1 on Linux Mint, can't remember on Fedora). I've also tried F# 2.0 and 3.0; all with same results.

I've also tried passing in "--no-gui" and "--readline" when launching the interpreter to no use.

Here's basically what happens (same with fsharp-mode 0.3):

bash-3.2$ fsharpi

Microsoft (R) F# 3.0 Interactive version (Mono build)

Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> - 1+2;;

# after waiting for a minute, I kill the mono process 

Killed: 9

bash-3.2$ bash: syntax error near unexpected token `;;'

However, the interpreter does work when running it on an "ansi-term" buffer:

bash-3.2$ fsharpi

Microsoft (R) F# 3.0 Interactive version (Mono build)

Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> - 1+2;; val it : int = 3

I want to use it with fsharp mode so that I can send code to the interpreter easily.

I haven't seen anyone having problems of this kind online, and resolving this would make development so much more convenient.

Any ideas on how to get this working?

Running it in comint mode also "hangs" (comint is what fsharp mode uses).

Is anyone able to run the interpreter on Emacs using fsharp-mode?

[Ben Winkel]

I've seen looping fsi.exe too. Please add an issue to https://github.com/fsharp/fsharp, we'll get it fixed.

mono --trace may reveal what's looping (though the trace can be v. big)

--
--
You received this message because you are subscribed to the Google
Groups "FSharp Open Source Community" group.
To post to this group, send email to fsharp-o...@googlegroups.com
To unsubscribe from this group, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource?hl=en
 
 
 

[Eduardo Muñoz]

For anyone interested, the link to the issue on Github is https://github.com/fsharp/fsharp/issues/47

[Ben Winkel]

Did you try

   fsharpi --readline-

The - after the flag turns off readline

On Sat, Oct 27, 2012 at 3:25 PM, Eduardo Muñoz <e...@rdomunoz.com> wrote:

--

[Eduardo Muñoz]

I feel so stupid now. I swear I had tried it, but it's working now with that argument!

Thanks for the suggestion, you don't know how much time I spent on this!

:)

[Laurent Le Brun]

On Sun, Oct 28, 2012 at 1:45 AM, Eduardo Muñoz <e...@rdomunoz.com> wrote:
> I feel so stupid now. I swear I had tried it, but it's working now with that
> argument!
>
> Thanks for the suggestion, you don't know how much time I spent on this!

That was in the README file! :)


By the way, if someone wants write access to the svn, I would be more
than happy to give them. The Emacs mode is not maintained because I'm
not using it often, and there are still a few things to fix.

--
Laurent

[Robin Neatherway]

Hi Laurent, others,

It would be great to have some auto-completion in emacs fsharp-mode.
Am I correct in saying that the prototype you developed only works for
single files currently?

Cheers,
Robin

[Laurent Le Brun]

That's correct.

* First step: I have no idea if the F# code still works. I expect it
needs a few changes to make it compile with latest F# (in particular
the wrapper in FSharpCompiler.fs). If it fails, Tomas Petricek might
be able to help you.

* Then, we need a way to list the files and libraries used in the
project. I don't know if users prefer to use the VS project files, or
if they want something simpler. If we use .vsproj files, we need a way
to parse them (is there something in .NET or in F# compiler code?)

* Update intellisense.el to send the information to the background
process. That should be easy.

* Probably some testing and polishing (eg. for the display).

That would be awesome if some people want to look at it!
Laurent

[Ben Winkel]

It would be very cool to have F# intellisense and F# 3.0 type providers in emacs!

I see the mention of FSharpBinding.fs and I thought I'd describe what I've learned about this magic while working on F# 3.0 support in MD.

• There is updated code for the Services/FSharpCompiler.fs wrapper in fsharp/fsharpbinding.

• This wrapper dynamically binds to either FSharp.Compiler.dll 2.0.0.0 or 3.0.0.0 acording to a global flag (or a request for a particular version can be passed in).  You could tightly bind but it is generally better if editing tooling is not tied to  particular version of a language....  f`or example, MD can be used with C# 2.0-5.0; VS 2012 can be used with C# 4.0 or 5.0, it is only F# in VS which tightly binds to F# 2.0 in VS2010 and F# 3.0 in VS2012. 
  

• The wrapper gives an API to some F# compiler functionality:

    InteractiveChecker.Create
    checker.TypeCheckSource
    checker.GetCheckOptionsFromScriptRoot
    checker.TryGetRecentTypeCheckResultsForFile
    checker.StartBackgroundCompile

    typeCheckInfo.GetDataTipText
    typeCheckInfo.GetDeclarations
  

These correspond to whats in vs/service/{fs,fsi} - it's just that you're not tightly bound to FSharp.Compiler.dll.

• You only need to compile the folllowing files to get this wrapper (but you'll also need the code in Parser.fs to get the info you need to pass to GetDeclarations and GetDataTipText - see the fsharp/fsharpbinding source code)

    <Compile Include="Services\Common.fs" />
    <Compile Include="Services\CompilerLocationUtils.fs" />
    <Compile Include="Services\FSharpCompiler.fs" />

For the emacs binding, you could include fixed copies of FSharp.Compiler.dll for F# 2.0 and 3.0 and adjust the loading code so it doesn't use the GAC.

For building from emacs you should just use xbuild or makefiles.

-- ben

p.s. There is also another "simpler" source code services API in FSharp.Compiler.dll that also lets you compile DLLs and execute scripts. I think we need to explore that. The FSharpCompiler.fs wrapper doesn't wrap  that - and there is a github suggestion to build a more complete compiler API - a bigger undertaking but one that could be very useful

[Tomas Petricek]

For those interested in F# IntelliSense for Emacs (vim, etc.), I think Laurent had some experimental version of it (for Emacs). It used a simple command-line interface for the compiler that loads the InteractiveChecker (described by Ben). It used to be available in "fsxplat" but the documentation for the sample somehow  got lost, so I moved it to GitHub:

 

https://github.com/tpetricek/FSharp.FsIntelliSense

 

There is quite long README document that describes how you can use the tool – I think this is a good starting point for doing Emacs (etc.) integration, because it is based on simple standard input/output, which should be easy to call from any langauge in any editor.

 

I’ll update it to use the latest version of FSharpCompiler (described below) once I figure out how to get the current version of fsharpbinding to compile :-).

 

T.

[Robin Neatherway]

Hi all,

On Tue, Oct 30, 2012 at 12:31 AM, Tomas Petricek <to...@tomasp.net> wrote:
> For those interested in F# IntelliSense for Emacs (vim, etc.), I think
> Laurent had some experimental version of it (for Emacs). It used a simple
> command-line interface for the compiler that loads the InteractiveChecker
> (described by Ben). It used to be available in "fsxplat" but the
> documentation for the sample somehow got lost, so I moved it to GitHub:

Yes, this is what I was asking Laurent about a few emails above.

> https://github.com/tpetricek/FSharp.FsIntelliSense
> There is quite long README document that describes how you can use the tool
> – I think this is a good starting point for doing Emacs (etc.) integration,
> because it is based on simple standard input/output, which should be easy to
> call from any langauge in any editor.

This README isn't present in the SVN repository of Laurent's prototype
at http://fsharp-mode.sourceforge.net/ so thanks for this useful and
thorough piece of documentation.

> I’ll update it to use the latest version of FSharpCompiler (described below)
> once I figure out how to get the current version of fsharpbinding to compile
> :-).

Good luck!

> [mailto:fsharp-o...@googlegroups.com] On Behalf Of Ben Winkel

> I see the mention of FSharpBinding.fs and I thought I'd describe what I've
> learned about this magic while working on F# 3.0 support in MD.

Just to check, you mean FSharpCompiler.fs here? There isn't another
option out there?

> There is updated code for the Services/FSharpCompiler.fs wrapper in
> fsharp/fsharpbinding.

So this grew out of the original fsxplat code used by Laurent for his
prototype and Tomas for the original fsharpbinding?

> This wrapper dynamically binds to either FSharp.Compiler.dll 2.0.0.0 or

> 3.0.0.0... <snip>

Thanks, useful information. So we can pull the relevant sections of
this into the command-line application to bring it up to date.

> For the emacs binding, you could include fixed copies of FSharp.Compiler.dll
> for F# 2.0 and 3.0 and adjust the loading code so it doesn't use the GAC.

Good suggestion.

> For building from emacs you should just use xbuild or makefiles.

Are you referring to the project file format? There are two reasons
why we need to project files:

1. For building. As you say we could just point xbuild at an fsproj
file. Does xbuild support F# now?

2. For knowing what to pass to the autocomplete compiler wrapper to
provide autocomplete across multiple files and projects. For this I
know there is some internal API, or it is also fairly easy to just
read the fsproj xml directly using System.XML.

Using the fsproj files would improve compatibility, but there isn't an
easy way to create or edit such files using emacs unless fsharp-mode
is extended to offer such a capability.

> p.s. There is also another "simpler" source code services API in
> FSharp.Compiler.dll that also lets you compile DLLs and execute scripts. I
> think we need to explore that. The FSharpCompiler.fs wrapper doesn't wrap
> that - and there is a github suggestion to build a more complete compiler
> API - a bigger undertaking but one that could be very useful

Is this the API from vs/service.fs that you were talking about above,
or something else? Wouldn't this result in being tied to a particular
version of F#? I take it this would involve bypassing the
FSharpCompiler.fs wrapper from fsharpbinding or wherever?

Cheers,
Robin

[Tomas Petricek]

Hi Robin,

> > I'll update it to use the latest version of FSharpCompiler (described
> > below) once I figure out how to get the current version of
> > fsharpbinding to compile :-).
> Good luck!

Thanks :-) I'll let you know when I make some progress, but I'd like to try
this today.

> > I see the mention of FSharpBinding.fs and I thought I'd describe what
> > I've learned about this magic while working on F# 3.0 support in MD.
> Just to check, you mean FSharpCompiler.fs here? There isn't another option
out there?

Yes, I think Ben was referring to FsharpCompile.fs here. This is the dynamic
proxy for calling FSharp.Compiler.dll. The latest version is in the
MonoDevelop F# bindings. A slightly outdated version (which I'll update) is
in my FsIntelliSense repository.

> > There is updated code for the Services/FSharpCompiler.fs wrapper in
fsharp/fsharpbinding.
> So this grew out of the original fsxplat code used by Laurent for
> his prototype and Tomas for the original fsharpbinding?

> (...)

> Thanks, useful information. So we can pull the relevant
> sections of this into the command-line application to bring it up to date.

Yes, I worked on the wrapper with Laurent and we used the same thing for the
original MonoDevelop F# plugin and for his Emacs mode for F#. Ben did some
great work to imporve that wrapper & suppor F# 3.0, so I think once I copy
that over to the command line tool, then the command line tool should be a
good way to call F# compiler from editor plugins.

(It might need to be extended to provide additional information that are not
exposed yet, but even the current support for autocompletions and tool tips
would be good starting point.)

Thanks!
Tomas

[Robin Neatherway]

Hi Tomas,

I have now installed F# 3.0, and my usual projects seem to run
correctly, so I'm ready to proceed.

> Thanks :-) I'll let you know when I make some progress, but I'd like to try
> this today.

Cool, I'll wait for you to have a first stab as you already know the
code base. If you find that you don't have time, just let me know and
I'll have a look at it, shouldn't be too difficult without all the
messiness of interacting with Monodevelop.

Cheers,
Robin

[Tomas Petricek]

Hi all,

@Robin - I modified the tool to use the latest wrapper code from
fsharbindings and I was able to run the sample (from the README) on Mono
using latest stable Mono and latest F# (3.0) compiled from the source on
GitHub. I also updated the project to work with VS2012 on Windows, but did
not test that too much. Let me know if it works for you (and if you need
some features, let me know.) It is here:
https://github.com/tpetricek/FSharp.FsIntelliSense

@Ben - I realized I have quite a few version of FsharpCompiler.fs in various
projects, so I'm wondering what would be the best way to merge these? (I
have one in FsIntelliSense and also one in FSharp.Formatting which is used
by www.fssnip.net.) It is not a major thing, but I figured out that all my
versions have slightly different features, so it is a bit versioning
nightmare at the moment.

The two options are merging some of the projects (make fsintellisense a
subproject of fsharpbinding) or make a separate project with extensions for
calling the compiler (which would be used from fsintellisense and
fsharpbinding, etc. and could be extended to cover other features in the
future.)

To make merge them, do you think it would make sense to submit this
changeset to 'fsharpbinding'?
https://github.com/tpetricek/FSharp.FSharpBinding/commit/fcb493547777fc4aedb
ff9141d25e9ee6918e460

This improves the (?) operator to support (very limited) generic methods &
fields. It adds navigation items (not fully tested yet, but I had this code
in another version) and it adds a little utility to format exceptions thrown
by F# compiler (which are otherwise really hard to decode.)

Also, here are some other notes:
1) To remove the link to MonoDevelop, we should use a different namespace
2) As far as I can tell, only "FolderOfDefaultFSharpCore" and "
FsharpCompilerVersion.CurrentRequestedVersion" in "CompilerLocationUtils.fs"
rely on MonoDevelop API. Could these be refactored somewhere else to make
the three files fully independent from MonoDevelop?
3) I did not get the USE_FSHARP_COMPILER_TOKENIZATION directive. It was
commenting out some code in FsharpCompiler.fs (which had some bugs that I
fixed). I don't see any problem with including the code in all builds (even
if it is not used by MonoDevelop integration currently).
4) Maybe we could have some tests :-) hmm. I think the command line tool
provides a good API for testing the wrapper too (at least lightly).
5) Ha, now I see you have nicer way of getting the tag of IDENT token for
tool tips, so I'll change that in fsintellisense too.
6) Looking at the current 'fsharbinding' repository, there are some random
files (Foo.fsx, Test.fsx, test.fsx). Should these be removed?

Thanks!
Tomas

[Eugen Hotwagner]

Hi all,

Just in case it has not been mentioned before. 

Fahad has done a newer version of fsintellisense here: https://github.com/fahadsuhaib/fsharp/tree/master/samples/FSI.Intellisense

Might be useful.

Eugen

[Robin Neatherway]

> @Robin - I modified the tool to use the latest wrapper code from
> fsharbindings and I was able to run the sample (from the README) on Mono
> using latest stable Mono and latest F# (3.0) compiled from the source on
> GitHub. I also updated the project to work with VS2012 on Windows, but did
> not test that too much. Let me know if it works for you (and if you need
> some features, let me know.) It is here:
> https://github.com/tpetricek/FSharp.FsIntelliSense

Thanks, this is working for me with Mono 2.11 and F# 3 from Github.
I'll look at getting the simple "one-file" integration with Emacs
working again first, and then think about how to extend it to larger
projects.

[Ben Winkel]

How about the FSharpBinding.dll is split into two DLLs

    FSharp.CompilerBinding.dll  -- generic component for compiler services etc. over different versions of F# langauge/library etc.
    MonoDevelop.FSharp.dll  -- the MonoDevelop-specific stuff

You could then push your work into FSharp.CompilerBinding.dll and take a dependency on that for the emacs binding.

FSharp.CompilerBinding.dll would still live in in fsharp/fsharpbinding

Maybe the Emacs binding work could actually be moved into that repo. It could then become a general repo for "F# editing support" with several sub-projects and outputs (MonoDevelop, Emacs, Eclipse, ...). That could give unity and critical mass if we start to implement things like refactoring and renaming - the one implementation of renaming would be available to all editors.

[Robin Neatherway]

On Wed, Oct 31, 2012 at 1:46 PM, Ben Winkel <funnel...@gmail.com> wrote:

How about the FSharpBinding.dll is split into two DLLs

    FSharp.CompilerBinding.dll  -- generic component for compiler services etc. over different versions of F# langauge/library etc.
    MonoDevelop.FSharp.dll  -- the MonoDevelop-specific stuff

You could then push your work into FSharp.CompilerBinding.dll and take a dependency on that for the emacs binding.

FSharp.CompilerBinding.dll would still live in in fsharp/fsharpbinding

Maybe the Emacs binding work could actually be moved into that repo. It could then become a general repo for "F# editing support" with several sub-projects and outputs (MonoDevelop, Emacs, Eclipse, ...). That could give unity and critical mass if we start to implement things like refactoring and renaming - the one implementation of renaming would be available to all editors.

I think this would be a very good step.

[Robin Neatherway]

Laurent,

I am looking to use your elisp as a starting point; some questions I have are:

1. Do you mind if I take the latest sourceforge code and move development to github, hopefully later into a repo under github:/fsharp?

2. You used the "esense" package for erlang support. It seems to be just for displaying completions. I am thinking of moving over to the autocomplete package http://cx4a.org/software/auto-complete/, any comments?

3. You also used tooltip-help.el, which I found on EmacsWiki. Do you think this could be adjusted to work with the tooltips built into Emacs instead? This would allow for mouse-over tooltips as in VS, rather than explicitly invoked tooltips (with <F1> currently).

Cheers,

Robin

[Laurent Le Brun]

On Wed, Oct 31, 2012 at 4:09 PM, Robin Neatherway <neath...@gmail.com> wrote:
> I am looking to use your elisp as a starting point; some questions I have
> are:

Did you get it work?

> 1. Do you mind if I take the latest sourceforge code and move development to
> github, hopefully later into a repo under github:/fsharp?

Please do. That makes sense to have everything at one place,
especially since the F# code should be shared with other projects.

> 2. You used the "esense" package for erlang support. It seems to be just for
> displaying completions. I am thinking of moving over to the autocomplete
> package http://cx4a.org/software/auto-complete/, any comments?

Feel free to use it. I don't think I've tried this one, so it may be better.

> 3. You also used tooltip-help.el, which I found on EmacsWiki. Do you think
> this could be adjusted to work with the tooltips built into Emacs instead?
> This would allow for mouse-over tooltips as in VS, rather than explicitly
> invoked tooltips (with <F1> currently).

Same here, I don't think I have tried the builtin tooltips. It sounds
like a good idea.

As you can see, the code is rather messy, I've reused pieces of code
from other projects, there are probably cleaner ways to do it.

--
Laurent

[Robin Neatherway]

On Wed, Oct 31, 2012 at 3:26 PM, Laurent Le Brun <laur...@gmail.com> wrote:
> Did you get it work?

Once I got the extra packages and made a few changes
(replace-in-string doesn't seem to exist anymore), start-intellisense
launches fsintellisense.exe correctly. There are a few rough edges,
but the communication is working at least some of the time as I am
getting completions and errors. I've modified the code to echo the
communication in the process buffer so I can see what is going on.

When I use fsintellisense.exe from the command line, I get some rather
strange behaviour. it just seems to stall:

$ mono bin/fsintellisense.exe
script "Test.fsx"
<<EOF>>
DONE: Script loaded
parse
module Test
let h = "h"
<<EOF>>
DONE: Background parsing started
tip 1 4

At this point I get no output and I can't type anything either. What
platforms are other people using this on?

[Tomas Petricek]

This might as well be some bug in the fsintellisense.exe tool. I cannot
reproduce it consistently, but I think it happended once when I tried it.
I'll see if I can reproduce that again...

In the meantime, you can try specifying timeout for getting the tooltip (you
can also pass timeout in "completion 1 4 1000"):

tip 1 4 1000

This will wait at most 1 second and then either print the tooltip or return
<<EOF>> if the compiler is still checking the code (which is unlikely for
such a small input, but perhaps there is some other bug...).

T.

[Ben Winkel]

ok, Robin, do you think you could bring the emacs code across to fsharp/fsharpbinding?  Put it under emacs/.. in its current shape?  Do it via a pull request from a fork of fsharpbinding.

we can work out the further details from there.

--

[Tomas Petricek]

I agree moving all the code under fsharp/fsharpbinding is a great idea!

I'll split the code into two projects (as Ben suggests) and move the code in
the FsIntelliSense tool under FSharp.FsIntelliSense in the fsharpbindings
repository (unless someone else is already doing that). I still need to take
a look at Fahad's updates to the project...

So the plan is to have:
* FSharp.CompilerBinding.dll - generic component for compiler services
* MonoDevelop.FsharpBinding - implements the MonoDevelop plugin
* FSharp.FsIntelliSense - command line api to the compiler
* Emacs - with emacs mode for F#

Suggestions for names better than FsIntelliSense are welcome, but I think
this is okay :-)

For now, I (pre Mono 3.0) need the obsolete version of a Makefile so I'll
recover that so that I can build & test the code, but removing that
eventually is a good idea. Should I add building of FsIntelliSense to the
master Makefile too?

Thanks,
T.

[Robin Neatherway]

On Wed, Oct 31, 2012 at 9:35 PM, Tomas Petricek <to...@tomasp.net> wrote:
> I agree moving all the code under fsharp/fsharpbinding is a great idea!
>
> I'll split the code into two projects (as Ben suggests) and move the code in
> the FsIntelliSense tool under FSharp.FsIntelliSense in the fsharpbindings
> repository (unless someone else is already doing that). I still need to take
> a look at Fahad's updates to the project...

That would be great, thanks Tomas.

> So the plan is to have:
> * FSharp.CompilerBinding.dll - generic component for compiler services
> * MonoDevelop.FsharpBinding - implements the MonoDevelop plugin
> * FSharp.FsIntelliSense - command line api to the compiler
> * Emacs - with emacs mode for F#
>
> Suggestions for names better than FsIntelliSense are welcome, but I think
> this is okay :-)

Agreed.

> For now, I (pre Mono 3.0) need the obsolete version of a Makefile so I'll
> recover that so that I can build & test the code, but removing that
> eventually is a good idea. Should I add building of FsIntelliSense to the
> master Makefile too?

Certainly add a target. As far as I am concerned we may as well add it
to "all" as well.

I have a question about the intended behaviour of the wrapper.

If I have the following interaction sequence with the command line tool:

$ mono fsintellisense.exe
script test.fsx
let hello = 5
printfn "%d" hel
<<EOF>>
DONE: Script loaded
completion 1 15 10000
AbstractClassAttribute
AllowNullLiteralAttribute
Array
Array2D
<...very long list including hello...>


I am asking for completion following "hel". The wrapper returns all
the top level functions and types. Of course, it is simple to then
filter this based on the context, but I am wondering what the scoping
rules used by the wrapper are. In the example given in the README.md
(https://github.com/rneatherway/FSharp.FsIntelliSense/blob/master/README.md):

script /home/fsharp/test.fsx
type Hello(who) =
member x.Say() =
printfn "Hello %s!" who

let hi = Hello("world")
hi.S
<<EOF>>

the completion request is at a point following a "hi.", and the
returned completions are limited to members of Hello. It seems like I
have possibly answered my own question here, but I would like to
verify that the wrapper will return all those symbols that could
follow the dotted name at the point of the completion request. If
there is no dotted name at the point, then it will return all
top-level symbols.

If this is the case, is there any downside to modifying the wrapper to
perform the context-based filtering? In that case for my first example
it would return only "hello", and for the second it would return only
"Say". Perhaps this would make too inflexible?

Cheers,
Robin

[Ben Winkel]

This change

  https://github.com/fsharp/fsharpbinding/commit/482cc2c2c9bf4a79b16a8389d309c269d096d231

 

removed the use of the global setting for the F# language version preference. This will make it easier to create FSharp.CompilerBinding.dll

 

Yes, add the build of FsIntellisense.exe to the Makefile.

 

 

-- ben

 

On Wed, Oct 31, 2012 at 9:35 PM, Tomas Petricek <to...@tomasp.net> wrote:

T.

[Tomas Petricek]

Hi,

>> This change
>>
https://github.com/fsharp/fsharpbinding/commit/482cc2c2c9bf4a79b16a8389d309c
269d096d231

>> removed the use of the global setting for the F# language version
preference.
>> This will make it easier to create FSharp.CompilerBinding.dll
 

Thanks Ben!

I submitted a pull request that implements the change and also migrates
FsIntelliSense (renamed to fsautocomplete) into the fsharpbinding
repository. I didn not push the changes directly to the repository, because
I'm not using xbuild and so it would be good if someone else tested the code
too.

Aside, I had some troubles getting the *.fsproj files to open in MonoDevelop
and I think you'll have the same trouble after merging my pull request
(sorry!). The problem is that your *.fsproj file contains explicit
references to DLLs in Mac folders (in <HintPath>). This is not used in the
compilation, but MonoDevelop uses that when opening project...

I tried various things, but nothing really worked. (Variables like
$(MonoDevelopRoot) are ignored in <HintPath>.) I did not want to fix this in
the configure script yet, because somebody may have better ideas, but I
guess that might be the only option...

T.

[Tomas Petricek]

Hi,

>> Certainly add a target. As far as I am concerned we may as well add it to
"all" as well.

I added the command line tool to the "all" target and tested that on the
version without xbuild. Although I believe (ehm) that it should work if
you're using xbuild too.

>> If I have the following interaction sequence with the command line tool:

>> (snip)

>> I am asking for completion following "hel". The wrapper returns all the
top

>> level functions and types. (...) In the example given in the README.md

>> the completion request is at a point following a "hi.", and the returned
>> completions are limited to members of Hello.

I think the general idea that when you ask for a completion at some
location, then the service returns a list of all possible identifiers that
could appear at that location. If you already started writing (as in
"hel<HERE>" or "hi.S<HERE>") then the list is not automatically filtered
based on the prefix ("hel" and "S", respectively).

I think F# 2.0 just distinguished dot and without-dot, but F# 3.0
distinguishies other contexts (try "System.<HERE>" vs. "open
System.<HERE>"). If you want to know the details, see "
GetDeclItemsForNamesAtPosition" in "service.fs" :-).

>> is there any downside to modifying the wrapper to perform the

>> context-based filtering? (...) Perhaps this would make too inflexible?

I think we probably want to have both options - for example, if you have
"h.S<HERE>" in Visual Studio then:
1) Ctrl+J shows the entire list (Equals, GetHashCode, ...)
2) Ctrl+Space filters the list using basically something like "completions
|> List.filter (fun c -> c.Contains(prefix))" so it shows "Say" and
"ToString" (!)
3) Your suggestion would be something like "completions |> List.filter (fun
c -> c.StartsWith(prefix))"

The behaviour (2) is a bit odd, but it is quite useful with some type
providers, because you do not have to know the name exactly (i.e. you just
need to know that the property name mentions "debt"), so I've been using
that sometimes.

Anyway, implementing (2) or (3) or both on the F# side (in the autocomplete
tool) and making it available using some option sounds like a good thing,
because otherwise it would have to be duplicated in all editors. It already
knows about the context, so it should be easy.

The only question is, what behaviour do we want? Somehow I'd feel that (3)
is more desirable for emacs where you probably don't want to display the
graphical menu that often...

T.

[Robin Neatherway]

Hi,

> I added the command line tool to the "all" target and tested that on the
> version without xbuild. Although I believe (ehm) that it should work if
> you're using xbuild too.

Great, this builds for me too. I just inserted MONO_BIN, FSBIN and FSC
into Makefile.no-xbuild as I don't have monodevelop installed anywhere
as the configure script wants me to.

I think this is a problem actually: it would be nice to be able to
build the non-Monodevelop parts of this project without Monodevelop.

Thanks for the rest of your comments. I see your point. I agree also
that for emacs what you have has option '3' seems to be the best place
to start.

Cheers,
Robin

[Dario Bertini]

Small introduction:

Hi, I've been dabbling with F# since April/May... at the time I setup (not without difficulties) the MonoDevelop addin

last week, I realized that with the update to Ubuntu 12.10 (and the new version of MonoDevelop) the addin, unsuprisingly, broke

I decided that, to play around with F#, probably it would've been easier just to use a small and simple syntax highlighter with emacs + the repl

On Wednesday, October 31, 2012 4:26:54 PM UTC+1, Laurent Le Brun wrote:

> 1. Do you mind if I take the latest sourceforge code and move development to 

> github, hopefully later into a repo under github:/fsharp?

Please do. That makes sense to have everything at one place,
especially since the F# code should be shared with other projects.

Is it ok to assume hence that any new development should happen there and not on sourceforge?

I'm asking, since googling for "emacs fsharp" brings up the sourceforge page first, and the emacsmirror second... with the fsharpbinding page nowhere to be seen

Since you're the owner of the sourceforge project, could you change its description (and possibly website?) to refer the people to the correct place?

 

> 2. You used the "esense" package for erlang support. It seems to be just for
> displaying completions. I am thinking of moving over to the autocomplete
> package http://cx4a.org/software/auto-complete/, any comments?

Feel free to use it. I don't think I've tried this one, so it may be better.

> 3. You also used tooltip-help.el, which I found on EmacsWiki. Do you think
> this could be adjusted to work with the tooltips built into Emacs instead?
> This would allow for mouse-over tooltips as in VS, rather than explicitly
> invoked tooltips (with <F1> currently).

Same here, I don't think I have tried the builtin tooltips. It sounds
like a good idea.

As you can see, the code is rather messy, I've reused pieces of code
from other projects, there are probably cleaner ways to do it.

Thanks for your work, anyhow :)

Since fsharp-mode is the only thing that I use in emacs that's unavailable in one of the online repositories, today I started looking into how to upload it on MELPA

http://melpa.milkbox.net/

I added the necessary file to fsharp-mode, wrote a recipe, asked around and now I just sent a pull request on github

https://github.com/fsharp/fsharpbinding/pull/69

the recipe does not include the intellisense integration since it's experimental, and (at least for now) needs esense and tooltip-help, neither of which are available on any of the emacs package archives it seems

 

[Laurent Le Brun]

On Mon, Dec 17, 2012 at 8:13 PM, Dario Bertini <berd...@gmail.com> wrote:
> On Wednesday, October 31, 2012 4:26:54 PM UTC+1, Laurent Le Brun wrote:
>> Please do. That makes sense to have everything at one place,
>> especially since the F# code should be shared with other projects.
>
> Is it ok to assume hence that any new development should happen there and
> not on sourceforge?

Yes.
The page on Github should provide a download link.

> Since you're the owner of the sourceforge project, could you change its
> description (and possibly website?) to refer the people to the correct
> place?

I've added a note. Thanks!

And thanks for the Melpa integration!

--
Laurent

[Ben Winkel]

 

Re MonoDevelop - do you now have MD 3.1?  (and out of curiosity how did you get it - a build or a package?)

 

A binding for MD 3.1  is not yet published (bindings for MD 3.0.3, 3.0.4, 3.0.5 and 3.0.6 are published) as MD 3.1 is not yet available on OSX or Windows.

--

[Robin Neatherway]

> I added the necessary file to fsharp-mode, wrote a recipe, asked around and
> now I just sent a pull request on github
> https://github.com/fsharp/fsharpbinding/pull/69

Great! Thanks for doing this. It should definitely help uptake.

> the recipe does not include the intellisense integration since it's
> experimental, and (at least for now) needs esense and tooltip-help, neither
> of which are available on any of the emacs package archives it seems

Work has been a bit slow since I dislocated my shoulder, but I hope to
have an update on this soon.

[Robin Neatherway]

Regarding the MELPA package, do you know what version is installed
when people use the package manager in Emacs? Is it the latest version
from fsharp/fsharpbinding, or is there a fork in the MELPA repository?

On Mon, Dec 17, 2012 at 7:13 PM, Dario Bertini <berd...@gmail.com> wrote:

[Dario Bertini]

On Mon, Dec 17, 2012 at 9:59 PM, Ben Winkel <funnel...@gmail.com> wrote:
> Re MonoDevelop - do you now have MD 3.1? (and out of curiosity how did you
> get it - a build or a package?)

3.0.3, it's the version from the ubuntu repositories (for 12.04 it was 2.8.6)

On Tue, Dec 18, 2012 at 3:36 PM, Robin Neatherway
<robin.ne...@gmail.com> wrote:
> Regarding the MELPA package, do you know what version is installed
> when people use the package manager in Emacs? Is it the latest version
> from fsharp/fsharpbinding, or is there a fork in the MELPA repository?

it should be the latest, MELPA downloads the changes and rebuilds
about every 2 hours it seems (but for mayor changes, like a bump in
the version number or if you decide to ship the new intellisense, the
recipe should be updated)