Skip to content

Conversation

@H445
Copy link
Collaborator

@H445 H445 commented Dec 21, 2025

Added right click context menu to symbol library and functionality to delete a symbol.

Update: EditableSymbolProject.cs - Add/expose new MarkCodeExternallyModified to force reload/recompile from other classes
Update: SymbolAnalysis.cs - Add single-symbol analysis using TryGetSymbolInfo
Update: SymbolLibrary.cs - Add right click context for DeleteSymbolDialog
Update: SymbolUiJson.cs - Skip orphaned child UIs whose symbol child no longer exists (just deleted)

image
image image image image

H445 added 5 commits December 20, 2025 21:01
Update: EditableSymbolProject.cs - expose new MarkCodeExternallyModified to force reload
Update: SymbolAnalysis.cs - Add single-symbol analysis using TryGetSymbolInfo
Update: SymbolLibrary.cs - Add UI for DeleteSymbolDialog
Update: SymbolUiJson.cs - Skip orphaned child UIs whose symbol child no longer exists
@H445 H445 marked this pull request as ready for review December 21, 2025 03:51
@H445 H445 marked this pull request as draft December 21, 2025 16:51
@H445 H445 marked this pull request as ready for review December 21, 2025 17:09
@H445 H445 requested a review from pixtur December 21, 2025 18:38
Copy link
Collaborator

@pixtur pixtur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow. That PR is some serious work! Awesome.

I think it's 90% there but there are some style changes, that should be aligned.

The only real issues are:

  1. avoiding hard coded dependencies and references like that list of packages.
  2. being really aware of GC allocations (it's not a real issue here, but in the context of TiXL it's crucial for performance)
  3. using TryGetXX with [NotNullWhen(true)] if possible
  4. Using doc comments either with or just /** comment **/

Only 1 is critical. Because some day somebody will add another package or rename a package and things will break without a clear reason.

}

// Include projects containing depending symbols (force-delete case)
if (dependingSymbols is { Count: > 0 })
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh? If nullable is enabled, that dependingSymbols should never be null. Why not just test for dependingSymbols.Count > 0 ?

Are you using Rider? I think it would have also highlighted this line.

Copy link
Collaborator Author

@H445 H445 Dec 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dependingSymbols can be null, if it is null it will skip trying to do affectedProjectIds.Add for dependent graphs. (since there are none)

foreach (var id in info.DependingSymbols)
{
if (allSymbols.TryGetValue(id, out var symbolUi))
if (allSymbols.TryGetValue(id, out var symbol))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch!

Comment on lines 226 to 230
IsLibOperator = isLib,
IsTypeOperator = isType,
IsExampleOperator = isExample,
IsT3Operator = isT3,
IsSkillOperator = isSkill,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't like this, because:

  • this implementation implies that a symbol could be in In Lib, Skill, T3 and other package at the same time. If at all, this should be an enum to avoid this.
  • But actually, we just want to store a reference to the ops package. Add a single "packageName" string.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking, there might be a Skill + Example later on?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see below response

Comment on lines 236 to 253
private static void GetNamespaceFlags(
Symbol symbol,
out string rootSegment,
out bool isLib,
out bool isType,
out bool isExample,
out bool isT3,
out bool isSkill)
{
var ns = symbol.Namespace ?? string.Empty;
rootSegment = ns.Split('.')[0];

isLib = rootSegment.Equals("Lib", StringComparison.Ordinal);
isType = rootSegment.Equals("Types", StringComparison.Ordinal);
isExample = rootSegment.Equals("Examples", StringComparison.Ordinal);
isT3 = rootSegment.Equals("t3", StringComparison.OrdinalIgnoreCase);
isSkill = rootSegment.Equals("Skills", StringComparison.Ordinal);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙄

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this was a little too much of a "hack" - I was avoiding modifying LibraryFiltering - which relied on isLib - This is now fixed using an OperatorClassification / TryGetOperatorType

@H445 H445 marked this pull request as draft December 23, 2025 01:24
@H445 H445 requested a review from pixtur December 27, 2025 20:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants