If a LSP textDocument/hover method response field result.contents looks like this:
[
{
"language": "typescript",
"value": "type Foo = any"
},
"Description here."
]
The first content item will render in the editor hover tooltip, but not the second markdown string:
See this detailed Deno extension investigation of this Nova bug causing type JSDoc descriptions to not display on hover:
It looks like Nova isnāt set up to render multiple returned content blocks. I will file this in our tracker to investigate!
@Logan what prioritisation does this bug have in your tracker; because it seems like a low hanging fruit. It doesnāt just affect Deno plugin users, as far as I can tell the plain TypeScript plugins also have the same issue. I havenāt been using Nova for the past few months because of it and I canāt recommend Nova for anyone professionally working with JavaScript or TypeScript until itās fixed. Every Nova update since reporting this bug has been a big disappointment; no-one I know cares about vim mode or any of the other features that have been worked on, but for all of us things like not having intellisense descriptions is a dealbreaker.
I sacrificed $9,500 AUD worth of contract work to spend weeks working on the Nova Deno plugin; I feel like my contributions towards making Nova a viable professional editor are in vein and not valued by Panic who are clearly not reciprocating the free labour and detailed feedback I have put into this.
Itās so close yet so far; there are only a few dealbreaker Nova bugs (see this list for the Nova Deno plugin: Issues Ā· jaydenseric/nova-deno Ā· GitHub) and if Panic were to take the contributions and opinions of professional JavaScript engineers seriously (multiple of us plugin authors are experiencing and reporting the same LSP bugs) Nova would be a viable professional tool for millions of web devs that expect more from a $99 USD + tax editor than a notepad for tweaking CSS.
I notice a lot of the Nova plugin authors had a huge initial wave of enthusiasm, published a lot of work and were active in these forums, then lost hope and went back to VS Code (or in my case, VSCodium). Please, please, listen to your professional users that are offering priceless feedback and are willing to contribute tens of thousands of dollars worth of free labor to our collective success.
I feel this frustration, I really do. I want to be clear that I recognize Logan has done an admirable amount of work and has created something incredible that I really want to succeed. It does feel like Panic has under-invested in Nova, though, and I am therefore questioning whether I should continue investing in Nova either.
We really appreciate the notes!
The only challenge with low hanging fruit is that, sure, itās easy to pick, but if thereās a lot of it ā and higher-hanging fruit that people are much hungrier for ā what do you pick first? Wow, really stretching that metaphor overall, sorry, but my point is: Logan has an infinite list of things to do, and prioritizing is always a challenge, especially when itās an issue with a single report.
But! The good news is that feedback and reminders like this are always appreciated and help us prioritize what should be looked at next. So, thank you so much, and weāll look at this soon.
(As for under-investing in Nova in general, personally I just canāt reconcile that sentiment when looking at the release notes. But we understand why it might feel that way when a pet bug isnāt addressed quickly. Weāll strive to be even faster in the future.)
Most importantly: we truly appreciate what you bring to Nova. Thank you!
One. Developer. Doing almost all of it. Not surprising his to do list is infinite.
When multiple āpet bugsā like not having code fixes/boilerplate written for you or repeated language server crashes for off-by-one indexing from not following the spec ā things that feel like major breaks in functionality ā go unaddressed for MONTHS, the problem feels like it extends beyond triage.
But letās say the problem is simply triage. Itās possible that your current triage system is flawed because it sounds like you put a lot of weight on number of reports. What you might be missing is that when a user experiences problems like those above they likely assume the issue is an incompetent extension developer and donāt report the issue to Panic. I know that was my assumption before I tried making my own language extension. Our āsingle reportā represents many more users.
Well, to be fair, itās more the ātext editorā part ā making a text editor means having an infinite to-do list, no matter how big you are. There is no end to the work that we can put into Nova ā even if there were ten engineers, or if there are hundreds (thousands?) like Microsoft has for VS Code.
The good news is: thatās what makes Nova a fun app to build!
I totally agree. We do our best to keep this in mind, just like how feature requests from hundreds of people likely represent thousands of people. And I appreciate the reminder!
Something that would put a huge smile on my face would be a āLSP updateā for Nova. I admittedly donāt know the first thing about prioritising features for a text editor, but maintaining the royal road to the many ecosystems with language servers seems like it has a good bang:buck ratio.
To me it feels like Nova is so close, and itās that last 2% that marks the threshold between āthis feels greatā and āmaybe I should just use VScodeā¦ (sad face)ā.
I donāt regret the time Iāve put into my own Deno LSP extension, but Iād think twice about putting more in. Iām probably not alone in that.
Panic likely have something much more comprehensive than this, but for my own curiosity I assembled a little list of all the LSP issues I could find on this forum. Seeing them all lined up this made me think that really great LSP experience might not be too far away?
Hey Sam,
Thank you for compiling this.
I would very much like to focus on a wide-spread set of Language Server improvements soon. I canāt for certain say when, but I am trying to prioritize it soon. I need to do a double-back on the entire implementation and make some changes and clean up for issues like these. I agree that I donāt believe it will require too much to get there.
Just as an update to all the folks following this thread: It is my intention to have fixed many of the bugs mentioned here in the upcoming Nova 9 release, as well as some of the enhancement requests.
Specifically, these should be resolved from Samās list:
textDocument/didSave not being sent - have to do it manually (textDocument/didSave notification not being sent - #5 by mike.bronner)
textDocument/codeAction range error on last line (LSP: textDocument/codeAction CodeActionParams with wrong Range - #2 by drew )
textDocument/didChange range error on last line (LSP: textDocument/codeAction CodeActionParams with wrong Range - #2 by drew )
textDocument/completion (Bug with textDocument/completion )
Rendering multiple returned content blocks Nova doesnāt display all editor hover content
onRequest (LanguageClient onRequest isnāt being called - #3 by robb-j )
registerCapability (specifically, for configuration) (LSP import action error )
If anyone is not on the Nova 9 beta already (its primary focus is Debugging, so you may not have seen the announcement) and would like to try out the changes to our Language Server support, let me know and I will add you to our next beta release.
I do intend to investigate the rest of the items mentioned here, but some of the remaining enhancement request are a bit more involved for this release, such as:
As always, thank you all for your patience and assistance with making Nova better. I always appreciate it.
Did configuring documentChanges make the v9 cut? It should be switching a config value from true ā false, but I havenāt been able to test my theory.
Iād like to try the beta ā how do we request access?
I believe support has been added for documentChanges with Nova 9, so while that property remains true, itās accurate now.
Just send me your email address (either here or via DM in Discourse) and I can add you to the list.
