Menu
▾
▴
#265 Add editline support for UTF-8
Gnuplot could use readline unfortunatly pacakge like debian could not package it with readline.
They exist a readline alternative named http://www.thrysoee.dk/editline/ under BSD licence. Could you use it
Already supported:
./configure --with-readline=bsd
Note, however, that editline is not capable of handling UTF-8 texts. This is severely limiting to many users.
Not anymore true using last libedit utf8 is supported
> Not anymore true using last libedit utf8 is supported
Heh. I see you mean "supported as of 3 days ago in the upstream source" :-)
That's great news, but now we need to find up whether the UTF-8 integration is transparent or whether additional code changes will be needed on the gnuplot end.
We will eventually also need to see whether we can test during autoconfigure to see if a given libedit library installed on the system does or does not support this new capability. But I guess that has to wait until the new version is picked up by the various distro package collections.
Are you in a position to test the latest editline with gnuplot, building both from source? Even a one-line report like "it works" or "produces the following error messages during build" would be very useful.
So now I have built and tested the updated libedit....
It doesn't work. Feeding it a UTF8 string causes a segfault.
So far as I can make out, it does not even try to support UTF8. Instead it supports MS-style wide characters (16-bit fixed width), which is not very useful in a UTF8 environment.
If I've got this wrong (and I hope I do) please help out with the intended mechanism for using it.
Use:
configure --enable-widec
BTW could you report your segfault upstream ?
>> configure --enable-widec
I did that, of course. But widec is not a UTF-8 encoding format. It is, as I said, fixed-width 16-bit.
I believe you should report upstream. I have understood that utf87 char are converted to whar_t
Bastien
The request for UTF-8 support has been lodged against upstream for several years now.
I suppose it's nice that it now supports widechar (ISO-10646); that's a benefit for systems that use it. My impression is that means mainly Windows and Solaris.
I see no mention of UTF encodings in the editline source code. I think there is a typo or misunderstanding in the description that you saw. It would in any case do us no good to convert UTF-8 on input to widechar, because the internal gnuplot code and the support libraries (at least on linux) do not use widechar. We really do want the UTF-8 byte sequence passed through without any conversion.
It seems that no direct conversion is possible.
However if wide char is enable the calling program could use the w version of function like for instance el_wgets
So it is the second option, they have created a new interface.
Conversion to that we want could be easy it i only matter to convert wide char back to utf8.
Bastien