For the first point, you are right. We start by a common (but very useful) feature. Since OCaml allows an infinite level of nesting (and different kind of structure item) it was still a bit of a challenge, mostly for finding the right UX.

For the second point we delay the aeration convention to the formatter (ocamlformat). It can be configure in a different way :)

Thanks for your feedback!

Nop, for the moment, we try to not "infer user usages"! But if you extract an expression with variable, there will be, obviously, not be repeated:

    let tau =
      let pi = 3.14 in 
      pi + pi

if we extract `pi + pi` it will lead (if you do not give any concrete name) to the following code:

    let fun_name1 pi = 
       pi + pi

    let tau = 
       let pi = 3.14 in 
       fun_name1 pi

Most refactoring engines don't automatically replace all identical expressions by default since it can change semantics (especially with side effects), but they typically offer a separate "introduce and replace all occurrences" option that you can explicitly choose.

LLM generated variable names would be nice!

We try to invest equal time between the OCaml platform (on VSCode) and OCaml-eglot (for Emacs). In fact, I find the VSCode extension to be rich (and generally iso-features with Emacs mode).

However, I (as maintainer of OCaml-eglot) find Emacs easier to extend (the VSCode extension is surprisingly complex when you stray from the beaten path), which seemed perfect for incubating an experimental feature. Furthermore, as mentioned at the end of the article, the feature can also be invoked from a code action, which makes it de facto callable from VSCode once the various PRs have been merged :)

My experience is that everything goes into Merlin, which is Ocaml tool for analysis and refactoring, and is then added to editor from there.

Here significant work was done to properly bridge the gap between Merlin and the LSP server so it should work fine in VSCode.

Generally speaking, the Ocaml community seems to spend a lot of time getting VSCode to work.

F# started as an Ocaml port to the CLR. In the end, they decided to port a subset of the language so you get mostly the same syntax, no parametrised modules which is a big part of Ocaml but in exchange you can call libraries from other languages using the CLR. Of course, that comes with the issue of being a second class citizen in the .Net family, albeit a very nice second class citizen.

F# have drifted a bit further since but not that much. It’s a nice language but it’s not really comparable to Ocaml at this point. At least, I don’t see many cases where people would have to chose one or the other. I think people know if they want the CLR or not.