Terminal: Admite restablecer los colores a través de OSC 104, 110, 111 ...

Creado en 26 nov. 2019  ·  3Comentarios  ·  Fuente: microsoft/terminal

Descripción de la nueva función / mejora

Estas son las contrapartes de OSC 4, 10, 11 para restablecer el color predeterminado. (Y continúe la línea con 117, 119 si se implementan 17, 19 , etc.)

Detalles de implementación técnica propuesta (opcional)

En VTE + GNOME Terminal descubrimos que lo mejor es si las secuencias OSC 4, 10, 11 tienen prioridad sobre la configuración del archivo UI / config. Es decir, para cada ranura de color, si su valor se define a través de OSC 4, 10, 11, se usa ese y se ignora el de la configuración. Si no se ha definido un valor a través de OSC 4, 10, 11 o se ha restablecido a través de OSC 104, 110, 111, se utiliza el valor especificado en la configuración del emulador de terminal. De esta forma, volver a aplicar los mismos ajustes es una operación idempotente. (Anteriormente, las dos fuentes estaban peleando entre sí, y ambas sobrescribían el valor en la misma ranura. De esa manera, volver a aplicar la configuración del usuario (por ejemplo, "alterar" un color al mismo valor) invalidaría un OSC anterior, lo cual era malo. )

Area-VT Help Wanted Issue-Task Product-Conhost

Comentario más útil

Hablando por mí mismo, esto es bastante bajo en mi lista de prioridades, porque creo que va a ser un poco molesto. Debe implementarse dos veces, porque la paleta de colores es una de esas cosas que conhost y Windows Terminal deben manejar por separado. Y en el lado del host, realmente no hay un concepto de "paleta predeterminada" para restablecer, porque los colores iniciales pueden provenir de una variedad de fuentes (por ejemplo, enlaces de acceso directo y entradas de registro), y la fuente puede cambiar en tiempo de ejecución.

También tengo planes de refactorizar parte del código de administración de la paleta, y no estoy interesado en agregar más funciones de paleta hasta que la refactorización esté fuera del camino. No es que la refactorización sea necesariamente un requisito previo para esta función, pero personalmente preferiría limpiar eso primero.

Entonces, básicamente, parece mucho trabajo para una característica bastante oscura, y sospecho que a poca gente le importará. Pero ese es solo mi punto de vista. Es posible que alguien más considere esto como una prioridad y decida asumirlo antes.

Todos 3 comentarios

Acabo de rebotar en esto. Estoy usando un script con OSC 10 y 11 para cambiar de Solarized Dark a Solarized Light en sesiones de Administrador de PowerShell. Sin embargo, editar mi configuración hace que todas esas sesiones tengan sus colores restablecidos, excepto por un montón de cosas que parecen mantener el esquema de color desde el momento en que se escribió (en PowerShell, supongo que esto es PS-Readline en el trabajo).

Estoy particularmente interesado en el comportamiento de capas de configuración, pero sin OSC 104/110/111, no poder aplicar cambios de configuración es probablemente una regresión de UX.

¿Existe alguna preocupación particular con el comportamiento propuesto, por ejemplo, estandarización / concordancia? ¿O es solo un caso de implementar el código relevante en este repositorio?

O (basado en que el hito es una versión de Windows) ¿realmente requiere un trabajo interno de MS primero para admitir el restablecimiento de los colores?

Hablando por mí mismo, esto es bastante bajo en mi lista de prioridades, porque creo que va a ser un poco molesto. Debe implementarse dos veces, porque la paleta de colores es una de esas cosas que conhost y Windows Terminal deben manejar por separado. Y en el lado del host, realmente no hay un concepto de "paleta predeterminada" para restablecer, porque los colores iniciales pueden provenir de una variedad de fuentes (por ejemplo, enlaces de acceso directo y entradas de registro), y la fuente puede cambiar en tiempo de ejecución.

También tengo planes de refactorizar parte del código de administración de la paleta, y no estoy interesado en agregar más funciones de paleta hasta que la refactorización esté fuera del camino. No es que la refactorización sea necesariamente un requisito previo para esta función, pero personalmente preferiría limpiar eso primero.

Entonces, básicamente, parece mucho trabajo para una característica bastante oscura, y sospecho que a poca gente le importará. Pero ese es solo mi punto de vista. Es posible que alguien más considere esto como una prioridad y decida asumirlo antes.

Tiene sentido. No es de ninguna manera un bloqueador para mí, así que estoy feliz de esperar a que aterrice cualquier refactorización planificada (y tal vez el # 942), antes de comenzar a tratar de recoger la fruta madura.

¿Fue útil esta página
0 / 5 - 0 calificaciones