From: Simon Cruanes <simon.cruanes.2007@m4x.org>
To: caml-list@inria.fr
Subject: Re: [Caml-list] [ANN] Beta-release of Merlin
Date: Thu, 21 Feb 2013 10:31:24 +0100 [thread overview]
Message-ID: <5125E96C.2010002@m4x.org> (raw)
In-Reply-To: <CAPFanBE50071PpJkM03gu3q6PeTYqrFk=JLakLoCn1OzpiGErQ@mail.gmail.com>
I started using Merlin a few days ago, on vim, and I must say it's a
pleasure to have direct access to completion/type checking/type
querying. Per-project configuration is really simple (just define a list
of source directories, build directories, and ocamlfind-able packages);
then completion and type-checking work seamlessly even with external
code. Maybe that's no big deal for emacs users, but on vim I think this
is quite a big improvement.
It's already very useful for me, so I'd like to thank the authors :)
Cheers,
Simon
On 02/21/2013 10:20 AM, Gabriel Scherer wrote:
> I looked into Merlin in the last few days, so here is a bit more
> information if you, like me, are interested in design information about
> projects before deciding whether to use (and potentially contribute to)
> them.
>
> Interface-wise: using Merlin (at least on emacs) feels a lot like
> ProofGeneral (or CoqIde): there is a "checked zone" from the start of
> the buffer to the first error, and reliable type information is
> available in all this checked zone. The interface is rather simple and
> easy to use.
>
> (If you're considering porting Merlin to another editor: merlin is an
> OCaml program that inputs and outputs JSON queries, so it seems rather
> easy to port to any editor having plugin support in any language with
> JSON support. Given its youth, you should however expect Merlin's
> protocol to evolve over the next development period, so editor plugin
> developers would need to follow Merlin's internal changes for now.)
>
> The major difference between Merlin and -annot-based tools such as
> Ocamlspotter or Typerex2 is that Merlin does the work of parsing OCaml
> sentences into chunks and sending them incrementally to the
> type-checker, instead of sending the whole buffer at once and using the
> output. This means that Merlin is much more robust with respect to files
> that have errors and cannot be compiled as a whole: you'll get reliable
> type information from the start of the file upto the first error (and
> some resilience heuristic to have more after). The OCaml type-checker is
> in fact able to provide some typing information even for incorrect
> programs, so -annot-based tools do support some of those features, but
> in a less reliable and more coarse-grained way.
> The design trade-off is that Merlin has to copy/adapt more logic from
> the compiler: it embeds an OCaml parser derived from the compiler's one
> (you won't get parsing bugs as with regexpy elisp modes), and currently
> also copies and slightly modifies the type-checker (I hope this can be
> changed in the future, possibly by adding some flexibility to the
> type-checker regarding eg. production of warnings). This means more
> maintenance work to port Merlin to future OCaml versions. On the other
> hand, it's probably not reasonable to expect the compiler type-checker
> to be re-engineered for optimal incrementality support, so having an
> external implementation of incrementality that piggybacks on the batch
> typer interface makes sense.
>
> My personal intuition is that Merlin's design is a good long-term choice
> for an editor service (as opposed to code-analysis services). You want
> tools such as ocamldoc, dead code analysis, or everything concerned with
> analysis of an existing correct codebase to be based on -bin-annot and
> work on the typedtrees directly (without local support for parsing and
> typing programs). You want tools designed to work on incomplete programs
> in the process of being created to embed incrementality logic (insofar
> as it hasn't been pushed into the compiler), understanding partial files
> and local modifications to cleverly control the parsing&typing process
> with reactivity in mind. The One True Editor Mode will merge both
> aspects, working on .cmt of already-compiled dependencies on one side,
> and partial/incremental information in edition buffers on the other.
> Merlin can evolve in this way, as its type-directed analyses (those
> performed in the "checked zone") work directly on the typedtree, so
> could work with .cmt files.
>
> On Thu, Feb 21, 2013 at 12:10 AM, Frédéric Bour
> <frederic.bour@lakaban.net <mailto:frederic.bour@lakaban.net>> wrote:
>
> We are very pleased to announce the beta release of Merlin. Merlin
> is a tool
> which provides smart completion, among other things, in your
> favorite editor.
> As of today, Vim and Emacs are supported.
>
> See it at work:
> https://github.com/def-lkb/__merlin#screenshots
> <https://github.com/def-lkb/merlin#screenshots>
>
> Its features include:
> - completion of values, constructorsand modules based on local scope
> - retrieving type of identifiers and/or expressions under cursor
> - integration of findlib to manage buildpath
> - highlighting of syntax errors, type errors and warnings inside the
> editor
> - to a certain amount, resilience to syntax and type errors
>
> It works only with Ocaml 4.00.1 (may works with newer versions).
>
> If you happen to have an opam installation with the right version
> (opam switch 4.00.1), you can try it right away with:
>
> $ opam remote add kiwi http://kiwi.iuwt.fr/~asmanur/__opam/.git
> <http://kiwi.iuwt.fr/~asmanur/opam/.git>
> <http://kiwi.iuwt.fr/%__7Easmanur/opam/.git
> <http://kiwi.iuwt.fr/%7Easmanur/opam/.git>>
> $ opam install merlin
>
> Then to get started and set-up your editor:
> - https://github.com/def-lkb/__merlin#setting-up-vim
> <https://github.com/def-lkb/merlin#setting-up-vim>
> - https://github.com/def-lkb/__merlin#emacs-interface
> <https://github.com/def-lkb/merlin#emacs-interface>
>
> Check it out at: https://github.com/def-lkb/__merlin
> <https://github.com/def-lkb/merlin>
>
> The current version still needs to be tested under various systems and
> configurations, your feedback iswelcome.
>
>
> --
> Caml-list mailing list. Subscription management and archives:
> https://sympa.inria.fr/sympa/__arc/caml-list
> <https://sympa.inria.fr/sympa/arc/caml-list>
> Beginner's list: http://groups.yahoo.com/group/__ocaml_beginners
> <http://groups.yahoo.com/group/ocaml_beginners>
> Bug reports: http://caml.inria.fr/bin/caml-__bugs
> <http://caml.inria.fr/bin/caml-bugs>
>
>
prev parent reply other threads:[~2013-02-21 9:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 23:10 Frédéric Bour
2013-02-21 9:20 ` Gabriel Scherer
2013-02-21 9:31 ` Simon Cruanes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5125E96C.2010002@m4x.org \
--to=simon.cruanes.2007@m4x.org \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox