Je viens de rebondir sur ça. J'utilise un script avec OSC 10 et 11 pour passer de Solarized Dark à Solarized Light dans les sessions Administrator PowerShell. Cependant, la modification de ma configuration entraîne alors la réinitialisation des couleurs de toutes ces sessions, à l'exception d'un tas de choses qui semblent conserver le schéma de couleurs à partir du moment où il a été écrit (sous PowerShell, je suppose que c'est PS-Readline au travail).

Je suis particulièrement intéressé par le comportement de la superposition de la configuration, mais sans OSC 104/110/111, l'impossibilité d'appliquer les modifications de configuration est probablement une régression UX.

Y a-t-il des préoccupations particulières concernant le comportement proposé, par exemple la normalisation/l'uniformité ? Ou s'agit-il simplement d'implémenter le code pertinent dans ce référentiel ?

Ou (sur la base du jalon étant une version de Windows) cela nécessite-t-il d'abord un travail interne à MS pour prendre en charge la réinitialisation des couleurs ?

Pour ma part, c'est assez bas dans ma liste de priorités, parce que je pense que ça va être un peu pénible. Il doit être implémenté deux fois, car la palette de couleurs est l'une de ces choses qui doit être gérée séparément par conhost et Windows Terminal. Et du côté conhost, il n'y a vraiment pas de concept de "palette par défaut" à réinitialiser, car les couleurs initiales peuvent provenir de diverses sources (par exemple, des liens de raccourci et des entrées de registre), et la source peut changer au moment de l'exécution.

J'ai également l'intention de refactoriser une partie du code de gestion des palettes, et je ne souhaite pas ajouter d'autres fonctionnalités de palette tant que cette refactorisation n'est pas terminée. Non pas que la refactorisation soit nécessairement une condition préalable à cette fonctionnalité, mais je préférerais personnellement que cela soit nettoyé en premier.

Donc, fondamentalement, cela semble être beaucoup de travail pour une fonctionnalité assez obscure, et je soupçonne que peu de gens se soucieront. Mais ce n'est que mon point de vue. Il est possible que quelqu'un d'autre considère cela comme une priorité et décide de s'en occuper plus tôt.

Logique. Ce n'est en aucun cas un bloqueur pour moi, donc je suis heureux d'attendre que tout refactoring planifié atterrisse (et peut-être #942), avant de commencer à essayer de cueillir des fruits à portée de main.