Skip to content
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

The emacs function "Show types at point" does not show the type of methods #4369

Closed
vicuna opened this issue Aug 26, 2007 · 10 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Aug 26, 2007

Original bug ID: 4369
Reporter: @yakobowski
Assigned to: @alainfrisch
Status: closed (set by @alainfrisch on 2017-04-10T13:14:00Z)
Resolution: won't fix
Priority: normal
Severity: minor
Version: 3.10.0
Category: emacs mode
Related to: #5812

Bug description

(Almost) everything is in the title: one gets "Point is not within a typechecked expression or pattern" when trying to get the type of a method.

@vicuna
Copy link
Author

vicuna commented Sep 14, 2012

Comment author: @damiendoligez

We just need to adapt caml-types.el to the new -bin-annot way of doing things, and the problem will disappear by magic.

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

Comment author: @gasche

I would warmly recommend using Merlin to anyone interested in accurate type information for an incomplete Emacs buffer.

https://github.com/the-lambda-church/merlin/

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

Comment author: @yakobowski

I agree completely, and I switched to Merlin a long time ago. But this issue is not Merlin's best selling point: querying the type of a method highlights the method properly, but shows the type of the entire method prefixed by the type of the class. The result is nearly unreadable when the class is big.

(Still, there must have been progress on this recently. I distinctly remember trying this a few months back, and it was not working at all.)

@vicuna
Copy link
Author

vicuna commented Apr 19, 2016

Comment author: @nojb

Even though merlin is great, it is not lightweight and it has many dependencies which make it not to easy to use in Windows and other less usual situations. So I think there still is a need for a light tool like caml-types.el for those of us who cannot readily make the jump to merlin.

@vicuna
Copy link
Author

vicuna commented Apr 19, 2016

Comment author: @gasche

Yep but, judging by the history of this PR, "those of us" will have to submit patches.

@vicuna
Copy link
Author

vicuna commented Apr 19, 2016

Comment author: @nojb

I am actually interested in helping update caml-types.el to use cmt files. The only issue is one of methodology: do we read the information from cmt file each time we want to look up a type (guided by the location) or do we try to produce a textual, annot-like, representation of the whole file once and then cache that on the emacs side for performance?

I have a proof of concept of the first strategy and is quite usable, but slightly slower (at least on Windows) than the current caml-types.el which caches the whole .annot file after reading.

Implementing the second strategy may be as easy as capturing the output of tools/read_cmt in lieu of reading the .annot file.

Any opinions ?

@vicuna
Copy link
Author

vicuna commented Apr 19, 2016

Comment author: @gasche

Out of curiosity, how is the deserialization of .cmt information implemented?

@vicuna
Copy link
Author

vicuna commented Apr 19, 2016

Comment author: @nojb

It is done with a little tool written in OCaml. As far as I can see this is the only option if we do not want to write a general Marshal decoder in elisp...

@vicuna
Copy link
Author

vicuna commented Apr 19, 2016

Comment author: @gasche

I don't have a particular opinion on your question. I would recommend proposing things for integration even if they are not optimal for performance. Visible change is the best way to get steam, and support from others.

@vicuna
Copy link
Author

vicuna commented Apr 10, 2017

Comment author: @alainfrisch

For the records, the tool was proposed for inclusion here: #569

It doesn't seem anyone cares enough with fixing the .annot files themselves, so I'm closing this ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants