Add setting to render code lenses as a phantom

[Rapptz]

This also adds a setting to disable the rendering entirely.

In order to satisfy those who like their code lenses as an annotation I kept the setting as-is rather than replacing them. I did change the default setting to use a phantom since that representation is probably more common for those coming from VSCode.

I've tested this code and it works, but I'm unsure if there are any state related bugs. One thing I noticed is that the code lenses only show up when the file is reopened. This felt undesirable to me, however I did not know where exactly to fix it. In a normal plugin lifecycle I would hook into on_load_async, on_activated_async, and (potentially) on_post_save_async. There was the _register_async helper function which would have felt like an appropriate place to send the code lenses request, but I was unsure if the state was properly set there or if this was even desirable. Personally, reopening the file to get code lenses is a bad experience.

Code lenses with the phantom setting are rendered similarly to VSCode, as seen below:

Sublime Text	VSCode

[predragnikolic]

IMO, the phantoms looks nice! Really Nice! 👍

I did a quick test run with the LSP-elm server
and noticed a few issues, which lead me to believe that there is still some polishing to do in the UX.

Like for example:

1. if I insert new lines, the code lens will on the same line (than inserted back to where it should be)
2. if I delete a line before a code lens, the code lens will be deleted (than inserted back in) - I think that this is ST behavior and that we cannot prevent the deletion of phantoms.
   

there is a problem where one code lens appears multiple times.

notice the exposed | 4 references | 4 references

notice the exposed | 7 references | 7 references | 7 references | 7 references

[Rapptz]

I've fixed the review comments.

if I insert new lines, the code lens will on the same line (than inserted back to where it should be)

Ideally, the code lens would be re-calculated when there are modifications. I'd personally use on_modified_async for this with the 300ms delay to prevent spamming. I'm not sure if this would be the approach I should take though. There are other nits I want to fix like the one I mentioned in the starting PR comment above. Fundamentally, I don't know when I'm "ready" to start sending requests to the server.

if I delete a line before a code lens, the code lens will be deleted (than inserted back in) - I think that this is ST behavior and that we cannot prevent the deletion of phantoms.

I think this one's in the same vein as the one above, which is to re-calculate code lenses on modification. I'm not entirely sure if it fixes it but I'm willing to try.

there is a problem where one code lens appears multiple times.

I've seen this one before myself! I don't know what causes it other than maybe the server sending duplicates (unlikely?) or some state not being cleared properly. I think I need LSP server logs to figure it out but I'd love to get it fixed as well.

[Rapptz]

I've force pushed the changesets to rebase from the previous refactoring and it's ready for review again.

[rchl]

There is unused resolved_code_lens method in CodeLensView.

And the unresolved_visible_code_lens should end with *lenses IMO.

[rwols]

The major problem I have with this is that phantoms are not attached to their actual region they represent. This causes all kinds of problems when modifying the buffer, for instance:

Schermopname.2021-06-26.om.12.15.03.mov

Use sublime.LAYOUT_BELOW and attach to the region it's meant to be attached to. We will have to wait for sublimehq/sublime_text#4469, if ever implemented.

[Rapptz]

This does not look pleasing.

I'm fine with changing it to the bottom but only if the region follows the same indentation rules as the code, i.e. the region is expanded to the line and indented, sort of like LAYOUT_BLOCK but not really.

For example:

RNRRaGXypX.mp4

[TerminalFi]

This is starting to look really clean. Hopefully we get a sublime.LAYOUT_ABOVE option for phantoms here in the near future and then this can become user configurable

[rwols]

Phantoms:

Annotations:

Seems to work OK now.