Open martin-fleck-at opened 4 months ago
@martin-fleck-at , I think you are right that this approach would agree better with VS Code settings and their visualization. And we should aim for "fixing" this. However, despite this extension being relatively young, we could cause some disrupt as you outlined. Do you know if there are any means to support such "migrations"? Like defining aliases for the same settings not visible in the GUI?
I don't think there is a lot of support when it comes to migration, at least nothing I could find. A common approach is to simply deprecate the old settings with a deprecationMessage
, migrate them to the new settings in-code and remove them at some point. Personally, I'd even argue that this is a VS Code issue because I cannot imagine that this is the desired behavior for displaying the titles especially if it diverges from the regular tree without the search. I couldn't find an existing issue, should we maybe create one and see how they react?
Description When searching for a setting, the category is shown as
Memory-inspector
as we usememory-inspector
to define our properties in thepackage.json
:By changing it to![image](https://github.com/eclipse-cdt-cloud/vscode-memory-inspector/assets/19170971/e333d4da-ef92-4b7a-8403-a9fc5cf31406)
memoryInspector
we would get the expectedMemory Inspector
label:Unfortunately, that means that existing custom settings would be invalidated. Please note that the label in the tree on the left side is shown correctly due to the
title
property.