Alternative editor support

[smithjessk]

I'm looking at the last announcement and am interested in tackling alternative editor support.

To make sure I understand the pipeline, if utop is started with -emacs (or -editor, or whatever the option will be), then it reads. parses, and evaluates the next line. It will wrap the output in the format mentioned on the mailing list ([@@@ outcome and so on). Is this interpretation correct?

Would I still call redirect "stdout" Unix.stdout as is done on line 825?

Thanks!

[ghost]

Sorry for the delay, I don't have much time to work on utop these days. TBH, I'm not entirely sure of the answer, I haven't looked at utop in a long time. I'm actually looking for a new maintainer.

Regarding this feature, I got this idea while working on toplevel expectation tests, i.e. this project toplevel_expect_test. A much simpler approach would be to add an alternative syntax to toplevel_expect_test so that it uses attributes instead of extensions. The only downside of this approach is that it is a bit slow to get an answer, as you have to reinterpret the whole file everytime, however it is much simpler to implement and it might not be too bad with a native toplevel.

[rgrinberg]

How would this approach work with redefining types for example? One think that you can in the toplevel is do something like type foo = int twice and it will work.

[ghost]

That shouldn't be an issue, you can already redefine a type with toplevel_expect_test. However, the point of this feature is to get completion with merlin for free, since the buffer can be seen as a plain ml file and defining a type twice would break that.