Nova doesn't display all editor hover content

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!

1 Like

@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:"Nova+bug") 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?

Not implemented




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:

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 truefalse, 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.