I have no idea, that’s for Windows users to tell me. I suspect it should work in cygwin, but for the rest I don’t know and I suspect it does not. I never found reliable information on how things are supposed to work for terminals on Windows and I’m still puzzled about the dozens of OCaml ports for Windows.
In any case if anyone’s knows what making a native Window port means and is interested in doing so, the system dependencies are entirely contained here (one function for setting the terminal in raw mode, one function to read stdin byte-by-byte and one function to get the SIGWINCH signal number).
I think it’s rather unimpressive in fact :–) I didn’t think implementing a readline was that easy. Spoiler: linenoise was mentioned a few weeks ago on the caml-list, I just printed its source and read it during my idle time to find out there was little magic in all that. This lead me to revive a project about toplevel readline patching I had started a few years ago.
There are a few hints here. I’d be keen to work with merlin authors on this — the work can actually be done pretty independently of Down I think — but I bet they are already pretty busy. It would also be nice to have people working on the ocaml upstream issues (which would benefit other projects like ocamlfind, utop and omod).
Good question I personally stopped using repls and shells from emacs, but my interest was revived by this question. I’m a bit unsure what it means in practice though. I kind of timed out on Down for now and don’t have too much time invest in it. If you know what your question entails exactly feel free to add more details about what should be done there — this might improve the chances I go about it (making PRs are another option of course but make sure to discuss things with me before).
I was thinking on more in depth integration with the comint-mode (the mode on which the ocaml mode is based). It has some ansi capabilities (enabled with the ansi-color-for-comint-mode-on). So I was able to get colorful message from down (after I have enabled ansi):
# Unix.putenv "TERM" "clever";;
- : unit = ()
# #use "down.top";;
Warning: Down v0.0.1 disabled. Failed to set stdin in raw mode.
where Warning was printed in color (probably maroon).
But here we hit the real problem, is that down.top needs the raw input, which you can’t get from Emacs. Of course, implementing full integration will require a lot of work (and elisp coding), but down can at least coexist with emacs, e.g., all the outputs will work fine, as well as session management (which probably is not terminal dependent).
Indeed you should be able to use this in your session above. When Down is disabled it just means that ocaml's readline patching did not occur, your are back to ocaml, the rest of the Down API remains available though.
Another thing to mention is that there’s absolutely no magic in sessions these are simply plain .ml files stored at a particular location and made available to you via a short name. So for example utop (which does seem to have emacs integration) could certainly easily support them aswell.
Oh, that’s cool, probably the message should be changed a little bit. Because, I was totally under impression that it is totally disabled.
However, my first attempt to use sessions in Emacs has failed (probably you still need to be able to read from the terminal, idk). But I believe it is already out of the scope of discuss, so I will create an issue
Thanks for this project @dbuenzli, I tried it and it feels fresh and modern. On the Dune side, we are planning to generalise dune utop so that it can benefit down users as well. It will work by loading a file in the toplevel via #use rather than calling a dune command.