I am fine leaving this for September btw, would also be interesting to get some user feedback on this.

If our goal is to align with native hover characteristics then these updates make sense but then it also creates inconsistencies with our hovers in the editor (which appear above by default). One of the main issues with native hovers is that they take a really long time to appear, so long that users don't wait around for the tooltip to appear and can miss some context. In the studies we've done nearly everyone moves too quickly to see this appear. So making our custom hovers match the native ones adds to this issue.

I am personally more in favor of having hovers appear quicker so that users can be aware of the description of items. I also like the idea of adding logic so this appears instantly if you are moving from one hover to another.

@misolori note that the hover from @bpasero's original issue are very simple and just repeat information, so there isn't really a great need to make them discoverable. In fact it's preferable to not display most of the time.

It should also show the full path as showing the text when the sidebar is too narrow is the main purpose of it, I mentioned this in another issue I think.

Yes, my main concern is hovers that repeat the same information that is under the mouse. They should not appear any faster than native hovers. I am fine that rich-custom-hovers have different rules applied to them (including their position on the screen) given they really provide additional value.

I think long term we should really just have one hover and not a custom and a native hover. It would likely be confusing for users to see 2 different styles for the same thing and I must admit that the "native" hovers on Linux and Windows really do NOT look any native for the OS. Only the macOS hover matches the native looks.

I agree we should go towards the single style. For the explorer if it's just adding cut off text, I really love what Windows Explorer does:

For folks following the issue: custom hovers in the tree now show below the cursor and slightly offset to the right. Please try it out and provide further feedback!

@alexr00 yeah it is better, but something I still see is that the hover seems to have a larger font compared to the text below:

I think it should never be larger, maybe same size? This is running web btw with zoom 125%, maybe it is related.

Per discussion about custom hover, we should opt in to custom hover at the resource label or icon label level (currently we opt in at the tree level, which is too high). Given that decision, we will go back to only showing custom hovers in the tree when the tooltip is markdown. Next milestone we will opt in to custom hovers at a deeper level than the tree.

I am an extension dev (GitHub Repository Manager):

So, this was added in 1.51, right? It changed the hover font, right? Is this the markdown implementation?

In my tree item hover, I had a multiline text of 2 columns, and I was manually spacing (with spaces, " ") the second column to have a table-like look. This was done in Linux, and when I tested in Windows, the spacing was wrong and ugly, as it was OS font system dependent. I would someday also manually set the spacing for the Windows, for the default font, as this seemed to be the only way to do it.

Now, the multiple spacing is gone, have being replaced by just 1 space:

.

With the new update, can I have the table-like view that I want cross-platform?

@SrBrahma markdown is like HTML in that is merged whitespace into a single whitespace characters. You could try using experiment with using a non breaking space ( ), otherwise table support would be a new feature request as I don't believe the |---| table format will work (but may be wrong here).

Does it accept HTML tables?

The table format will not work (at least not until #100741 is finalized. Once that's finalized you should be able to use markdown tables). I just tested   and it does work. However, I think this could be considered a VS Code bug since we say we take a string, then we don't treat it like a string. Bug: #110464