4

In the web browser Lynx I have managed to make non-ASCII character display correctly with the setting

CHARACTER_SET:UNICODE (UTF-8)

in /etc/lynx-cur/lynx.cfg. I also tried ASSUME_CHARSET, it makes no difference. Typing non-ASCII characters in input fields, however, does not work properly. For example, when I copy 狐 into the form field it displays correctly. Then when I press space, however, the insertion point is moved to the beginning of the line. If I do this with Äpfel, it also displays correctly when I paste it. Upon writing it, the Ä displays correctly but when I type in the remaining letters the insertion point is first moved to the far left and then no characters are displayed.

What setting do I need? My locale is all UTF-8. I use Lynx 2.8.9dev.1 on Debian 8.7. All other applications, Emacs included, work flawlessly with non-ASCII characters.

Improve this question
4
  • 1
    It works for me in Lynx 2.8.8rel.2, though I notice I'm using ASSUME_CHARSET rather than CHARACTER_SET. Tested with Japanese keyboard entry to be sure the entered characters don't also appear in ISO-8859-1 Commented Apr 27, 2017 at 14:59
  • Would it be possible to download / compile / otherwise test version 2.8.8rel.2, to make sure it wasn't a bug introduced in the newer version? If not, then I can build the version you are running (later) and see if I can reproduce the issue Commented Apr 27, 2017 at 18:49
  • 1
    Let us continue this discussion in chat. Commented Apr 27, 2017 at 21:32
  • I can reproduce this bug on Debian jessie. Maybe you can use links or w3m as a workaround. Commented Apr 27, 2017 at 22:09

2 Answers 2

Reset to default
2

I have lynx version 2.8.9rel.1 (08 Jul 2018) on Manjaro 18. After installing lynx, I tested the page https://zh.wikipedia.org/wiki/Lynx and noticed that Chinese characters were not displayed correctly. Then I added the line 

 CHARACTER_SET:utf-8

to the file /etc/lynx.cfg.

Note that the value is utf-8, as listed in the MIME name column in the cfg file, not UNICODE (UTF-8) from the "string for 'O'ptions Menu" column. After this, the Chinese characters on the above-mentioned page were displayed correctly. Searching for "Äpfel" or "狐", as suggested in the chat room also worked fine.

I don't know if the bugs mentioned by Thomas Dickey are relevant; using the correct value in the cfg file is what solved the issue for me.

Improve this answer
1

It's coincidental, a bug which was fixed recently:

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

Debian #841155 was reported last fall, but the problem was in the initial version of cell2char, added in 2.8.7dev.10 mentioned here:

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

Briefly, Lynx uses curses to display characters, and to ensure that it knows the width of a multibyte character on the screen, it draws the text in a hidden window, counting cells.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.