Repository navigation
Symbol list unexpectedly contains things like <function> #51332
Description
There are some things that seem a bit weird shown in the symbol list. I think it makes sense to have them in Outline though, so maybe there should be some way to provide data that is to be used in the Outline without it showing here:
Activity
mjbvz commentedon Jun 7, 2018
Johannes Rieken (@jrieken) As Danny Tuppeny (@DanTup) notes, we want these in the outline view but not in the symbol results. Is this possible?
DanTup commentedon Jun 7, 2018
If hiding isn't an option, maybe being able to register an outline provider to supply slightly different data would also work. I guess it depends how much you want to allow the symbol list and outline tree to diverge.
DanTup commentedon Jul 9, 2018
Any thoughts on whether it's likely we'll get an option to handle this? I'm currently torn between using the Outline tree versus my own custom tree for Flutter Outline - both have compromises so I'm trying to pick the least-bad one.
DanTup commentedon Feb 11, 2019
Johannes Rieken (@jrieken) Matt Bierner (@mjbvz) I don't suppose this has been discussed? In Flutter we'd also like to show some items in the tree/breadcrumb without them showing up in the symbol list. They're similar to functions here - in the tree/breadcrumb they make sense because there is context, but in the symbol list which is flat, they're just useless as you end up with loads of items that display the same (and, like
<function>they're not really what the user would expect to show here).DanTup commentedon Jun 13, 2019
Johannes Rieken (@jrieken) Matt Bierner (@mjbvz) would you accept a contribution to handle this in some way? We have a big feature that people have wanted for years which we can implement in two ways:
Fixing this ones seems the simplest (and best for users).
jrieken commentedon Jun 13, 2019
If your feature isn't outline then you should use a custom tree. That's all I can say with the little information we have but the idea is to have strict API and uniform UX so that outline looks and feels the same for all languages
DanTup commentedon Jun 13, 2019
Johannes Rieken (@jrieken) sorry, I should've included some context. My need is very much outline - it's very similar to what TypeScript is doing here with anonymous functions but with Widgets (with a flag to enable/disable), see https://user-images.githubusercontent.com/906564/36736340-45fd7c56-1bd0-11e8-99b0-4683785b49d9.png (the nodes with the Flutter icons are the Widgets - though I think IntelliJ's view is much busier than it could be). However since you might have multiple widgets of the same type inside a Build method they don't work in a flat list.
I'm thinking of building/shipping it behind a preview flag (people have been waiting a long time for it) and letting people just pick whether they'd prefer the feature and a symbol list with dupes, or not.
Building it with a custom tree has more issues, like:
Don't collapse nodes on clicking (TreeDataProvider: allow selecting a TreeItem without affecting its collapsibleState #34130)Tree loses focus on click (so can't navigate on keyboard) - it's possible this one is fixed, I don't have the branch currently working to re-testIt'd feel much more natural to not have a "second outline" though and have it as an opt-in flag for the standard outline.
DanTup commentedon Jun 13, 2019
I got my custom-tree branch up and running again since some of the issues I noted have been fixed, however the second outline feels bad - since it doesn't have any of the functionality like collapse all, sorting, follow cursor. It feels weird to re-implement all this Outline functionality in its own tree.
I'll finish off the version that uses the native tree, and maybe just ship with this limitation. If people want the tree but don't like the messy symbol list, I can always point them here to add 👍 s.
DanTup commentedon Jun 13, 2019
Adding the widgets to the outline does look weird in the symbol view (it's also slightly weird in Outline because we can't have custom - or blank - icons).
That said, I wonder if the real fix is to not show the symbol list as a flat list, but a tree? The current behaviour already bad if there are duplicates, for ex (a contrived example, but not uncommon if your language encourages multiple classes per file):
Since VS Code already has filterable trees, for ex in the breadcrumb, wouldn't it be better to use a tree here?
jrieken commentedon Jun 19, 2019
No plans - quick pick is there to quickly select an items, not to get the full picture, e.g. as static outline does.
Did you consider contributing two outline providers? One for dart sources and one for flutter widgets? The outline will then show them both independently and you can be more specific in both
DanTup commentedon Jun 19, 2019
I hadn't, though I just did some testing.. This still results in a weird doc symbol list (in fact it's even weirder because there are additional dupes). I also don't think that solves the general issue about data that works in a tree but not flat - I see this in TypeScript a lot too and I can't fix it there. Here's another example:
In a large file, the chances of seeing this increase because you're more likely to have nested callbacks where the main function name is lost. Maybe another way to improve it would be to include all ancestor labels concatenated instead of only the immediate parents name?
jrieken commentedon Oct 2, 2019
Close as TypeScript has fixed this in the meantime
DanTup commentedon Oct 2, 2019
Johannes Rieken (@jrieken) do you have any info on what the TS fix is? In the latest insiders (using "VS Code's version" of typescript) I still see this in the document symbol list:
DanTup commentedon Oct 9, 2019
Matt Bierner (@mattbierner) do you know the answer to the above?
mjbvz commentedon Oct 9, 2019
Johannes Rieken (@jrieken) I don't think we've done anything recently. We only show
<function>entries if they are the ancestor of another symbolDanTup commentedon Nov 11, 2019
I don't understand what the status of this is... It's closed, but as far as I can tell there is no good solution - if you want to show items in the tree that are ambiguous without the tree structure, the UX of the document symbol list is poor 😞