Syntax-colour analyzer signatures with bold type names (#2164) - #3812
Merged
Conversation
The Analyze panel showed each signature as a flat string, so the type names that carry the key information were hard to spot in long Used-By / Uses lists. Render analyzer entity rows as syntax-highlighted rich text with the type-name spans emboldened (issue #2164). Replace Language.GetRichTextTooltip(entity) with a general GetRichText(entity, conversionFlags, boldTypeNames): the hover tooltip is one caller, the analyzer pane another. C# colours the signature via CSharpHighlightingTokenWriter and bolds the type-name colour spans; IL renders its disassembled header (its signature form), already lexically highlighted; the base produces plain text. The IL method/type/field header is semantically the same artifact as the C# signature, so it shares the one method. Rendering is opt-in: nodes that want rich labels implement IRichTextNode, and the single shared SharpTreeView cell renders its runs via the new RichNodeText attached behaviour, falling back to the plain Text otherwise. SharpTreeNode.Text stays the authoritative plain string, so search, copy and keyboard navigation are unchanged; analyzer entity nodes derive Text from the same RichText so the two never diverge. Fixes #2164 Assisted-by: Claude:claude-opus-4-8:Claude Code
The analyzer signature colours depend on the active theme, and the formatting on the active language, but the highlighted RichText was built once and cached. Toggling the theme or switching the decompiler language therefore left existing analyzer results showing the old colours / syntax. Key the node's RichText cache on the (theme, language) pair so it rebuilds when either changes, and have the rich-text cell re-render rich rows on both ThemeManager.ThemeChanged and the language settings' PropertyChanged (cleaned up on Node change and on detach, like the existing subscriptions). Assisted-by: Claude:claude-opus-4-8:Claude Code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2164.
The Analyze panel rendered each signature as a flat string, so the type names that carry the key information were hard to spot in long Used By / Uses lists. This renders analyzer entity rows as syntax-highlighted rich text with the type-name spans emboldened.
How
Language.GetRichTextTooltip(entity)becomes a generalGetRichText(entity, conversionFlags, boldTypeNames). The hover tooltip is one caller, the analyzer pane another. C# colours the signature viaCSharpHighlightingTokenWriterand bolds the type-name colour spans; IL renders its disassembled header (its signature form, already lexically highlighted); the base produces plain text. The IL method/type/field header is semantically the same artifact as the C# signature, so it shares the one method.IRichTextNode; the single sharedSharpTreeViewcell renders their runs via a newRichNodeTextattached behaviour, falling back to the plainTextotherwise. So no other tree is affected.SharpTreeNode.Textstays the authoritative plain string, so search, copy and keyboard navigation are unchanged; analyzer entity nodes derive theirTextfrom the sameRichTextso the two never diverge.RichTextis cached per(theme, language)and the cell re-renders rich rows onThemeChangedand on language-settings changes, so existing analyzer results recolour on a theme toggle and reformat when the decompiler language is switched.Tests
New headless
AnalyzerRichTextTestscover the bold-type-name span and the plain-Textcontract; the fullILSpy.Testssuite (888) passes unchanged, confirming the shared cell-template change does not regress the other trees / search / copy / navigation.This PR was prepared with the assistance of an AI agent.