New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adapt emacs mode to generate .annot from .cmt files #5812
Comments
Comment author: cago I started writing a tool[1] that finds type of a value from its location. I intended to use it for something else, but if it can be used for that too, feel free to contribute, it's not yet finished. [1] https://github.com/OCamlPro/typerex/tree/typerex2/tools/ocp-type-from-loc |
Comment author: @gasche Çagdas, I don't think this design would work for the Emacs mode. The idea of the .annot file was to present location-indexed information in a simple format that dumb elisp code could process easily. In a way you can see the (cmt -> annot) translation as a generic "exposing simple information to text-based consumers" step designed for ease of post-processing (while the cmt format itself is designed for flexibility and exhaustivity of collected information). Your code is in OCaml (meaning more work to call it from Emacs) and re-parses the whole typedtree structure each time you want to get information -- which I guess doesn't take that much less time than creating a location-indexed structure once and for all. In my experience, if you request location-based type information for some location in the code, you're quite likely to do other similar requests in the same source file (that you're trying to understand/debug/analyze/whatever), so one re-indexing rather than several re-traversal should be profitable. Now, we could think of storing location-indexed information in the .cmt as well, but I think that Alain's idea of letting consumers request that computation on demand is important; if it was stored in the .cmt from OCaml-side, it should be computed and stored only on demand, and exposed with an easy interface (hopefully as simple as querying the current .annot file) for painful-to-program editors to use. |
Comment author: @alainfrisch I think it makes a lot of sense to have a dedicated tool to query the .cmt file, to be called from emacs (hence with a simple textual input/output interface). This would allow to report much more things than the current .annot file, with all the logic being implemented in OCaml. Also, it would actually simplify the logic on the emacs lisp side, since it wouldn't have to parse the whole .annot file. Generating the .annot file can take quite a bit of time (well, it's still probably ok for interactive use), because it generates a lot of redundant textual output. Just loading the .cmt file and looking for specific information should be rather quick (and the tool can always create some stored indexed cache of the .cmt file if needed). |
Comment author: @yakobowski From what I understood, OCamlspotter's emacs mode does essentially this (querying results from ocamlspot, which parses .cmt files, and displaying them in Emacs). It should be possible to find some inspiration there. |
Comment author: @gasche After giving some more thought, it should be possible to look at a specific location in a Typedtree without doing a linear search, by assuming that locations are correctly nested intervals and pruning the search accordingly, getting an essentially logarithmic behavior (in the parts of the AST that are well-balanced, eg. not Texp_sequence). With such an implementation, caching would probably be unnecessary. But yes, I think having a simple interface is important. PS: if Jun's implementation is already better than what we have, and now that it is easy to provide separately from the core compiler internals, could the standard distribution consider shipping it with the emacs mode? That could be more features for less work that re-implementing .annot file generation. |
Comment author: @alainfrisch
You'd still need to load the entire .cmt file in memory, which is also linear in the total size of the unit, and probably slower than traversing the whole data structure to find the relevant node. But all that should be really fast anyway. |
Comment author: @alainfrisch
Now we have https://github.com/LexiFi/cmt_annot so let's close this ticket. |
Comment author: @yakobowski Sure, but actually I think "use Merlin" is an even better advice. |
Comment author: @alainfrisch Sure, although there is variety of contexts in which Merlin cannot be used (e.g. when working on forks of OCaml, since porting Merlin to such port is currently quite challenging while a .cmt-based tool might work out of the box). |
Original bug ID: 5812
Reporter: @alainfrisch
Assigned to: @alainfrisch
Status: resolved (set by @alainfrisch on 2017-02-24T14:52:48Z)
Resolution: not a bug
Priority: normal
Severity: minor
Target version: undecided
Category: ~DO NOT USE (was: OCaml general)
Related to: #4369 #6134
Monitored by: @gasche @jmeber
Bug description
It would be useful to adapt the OCaml emacs mode so that the .annot file is generated from the .cmt file on demand (when the .annot does not exist or is less recent than the .cmt file), using the read_cmt tool (to be installed). Currently, one has to compile with -annot, which takes a significant amount of the total compilation time.
In the longer term, one can imagine having the emacs mode call a tool which directly queries the .cmt file without generating an .annot file at all, but this probably requires much more work.
The text was updated successfully, but these errors were encountered: