☰

Entrada UTF-8 en Lynx

tag-icon • tag-icon unicode lynx
Entrada UTF-8 en Lynx

En el navegador web Lynx, logré que los caracteres no ASCII se muestren correctamente con la configuración

CHARACTER_SET:UNICODE (UTF-8)

en /etc/lynx-cur/lynx.cfg. También lo intenté ASSUME_CHARSET, no hace ninguna diferencia. Sin embargo, escribir caracteres que no sean ASCII en los campos de entrada no funciona correctamente. Por ejemplo, cuando copio 狐en el campo del formulario, se muestra correctamente. Luego, cuando presiono la barra espaciadora, el punto de inserción se mueve al principio de la línea. Si hago esto con Äpfel, también se muestra correctamente cuando lo pego. Al escribirlo, la Ä se muestra correctamente, pero cuando escribo las letras restantes, el punto de inserción primero se mueve hacia el extremo izquierdo y luego no se muestra ningún carácter.

¿Qué configuración necesito? Mi configuración regional es toda UTF-8. Utilizo Lynx 2.8.9dev.1 en Debian 8.7. Todas las demás aplicaciones, incluido Emacs, funcionan perfectamente con caracteres que no son ASCII.

Respuesta1

Tengo la versión 2.8.9rel.1 de Lynx (08 de julio de 2018) en Manjaro 18. Después de instalar Lynx, probé la página.https://zh.wikipedia.org/wiki/Lynxy noté que los caracteres chinos no se mostraban correctamente. Luego agregué la línea

 CHARACTER_SET:utf-8

al archivo /etc/lynx.cfg.

Tenga en cuenta que el valor es utf-8, como se indica en la columna de nombre MIME en el archivo cfg, no UNICODE (UTF-8)en la columna "cadena para 'Menú de opciones'". Después de esto, los caracteres chinos en la página mencionada anteriormente se mostraron correctamente. Buscando "Äpfel" o "狐", como se sugiere en elsala de chattambién funcionó bien.

No sé si los errores mencionados por Thomas Dickey son relevantes; usar el valor correcto en el archivo cfg es lo que me resolvió el problema.

Respuesta2

Es una coincidencia, un error que fue solucionado.recientemente:

2017-04-29 (2.8.9dev.13)
* amend fix for Debian #841155, adding check for special case where the
  expected number of cells is zero (report by Larry Hynes) -TD

2017-04-28 (2.8.9dev.12)
* correct logic in cell2char(), which gave up too early in determining the
  number of cells needed for a multibyte string in the editable text-fields
  (Debian #841155) -TD

#841155se informó el otoño pasado, pero el problema estaba en la versión inicial de cell2char, agregada en2.8.7dev.10mencionado aquí:

* rewrite LYRefreshEdit(), to display multibyte/multicolumn characters properly
  when using wide-character curses -TD

Brevemente, Lynx usa maldiciones para mostrar caracteres y, para asegurarse de conocer el ancho de un carácter multibyte en la pantalla, dibuja el texto en una ventana oculta y cuenta las celdas.

información relacionada