Ich habe das gerade abgeprallt. Ich verwende ein Skript mit OSC 10 und 11, um in Administrator PowerShell-Sitzungen von Solarized Dark zu Solarized Light zu wechseln. Das Bearbeiten meiner Konfiguration führt jedoch dazu, dass die Farben all dieser Sitzungen zurückgesetzt werden, mit Ausnahme einiger Dinge, die das Farbschema aus dem Zeitpunkt des Schreibens beibehalten (unter PowerShell ist dies vermutlich PS-Readline bei der Arbeit).

Ich interessiere mich besonders für das Verhalten der Konfigurationsschichtung, aber ohne OSC 104/110/111 ist es wahrscheinlich eine UX-Regression, keine Konfigurationsänderungen anwenden zu können.

Gibt es besondere Bedenken bezüglich des vorgeschlagenen Verhaltens, zB Standardisierung/Gemeinsamkeit? Oder geht es nur darum, den entsprechenden Code in diesem Repo zu implementieren?

Oder (basierend auf dem Meilenstein, der ein Windows-Release ist) erfordert es tatsächlich zuerst MS-interne Arbeit, um das Zurücksetzen der Farben zu unterstützen?

Ich spreche nur für mich selbst, das steht ganz unten auf meiner Prioritätenliste, weil ich denke, dass es ein bisschen schmerzhaft sein wird. Es muss zweimal implementiert werden, da die Farbpalette eines der Dinge ist, die von conhost und Windows Terminal getrennt behandelt werden müssen. Und auf der Conhost-Seite gibt es wirklich kein Konzept für eine "Standardpalette", auf die man zurücksetzen kann, da die anfänglichen Farben aus einer Vielzahl von Quellen stammen können (zB Verknüpfungen und Registrierungseinträge) und sich die Quelle zur Laufzeit ändern kann.

Ich habe auch Pläne, einen Teil des Palettenverwaltungscodes umzugestalten, und ich bin nicht daran interessiert, weitere Palettenfunktionen hinzuzufügen, bis diese Umgestaltung aus dem Weg geräumt ist. Das Refactoring ist nicht unbedingt eine Voraussetzung für diese Funktion, aber ich persönlich würde es vorziehen, das zuerst zu bereinigen.

Im Grunde scheint es also eine Menge Arbeit für ein ziemlich obskures Feature zu sein, und ich vermute, dass sich nur wenige Leute darum kümmern werden. Aber das ist nur mein Standpunkt. Es ist möglich, dass jemand anderes dies als vorrangig betrachtet und sich entscheidet, es früher zu übernehmen.

Macht Sinn. Es ist in keiner Weise ein Blocker für mich, also warte ich gerne auf geplante Refactorings (und vielleicht #942), bevor ich versuche, niedrig hängende Früchte zu pflücken.