Thank you for the info and for checking the Linux build. I unfortunately do not
know much about locale issues on Linux, but I tested your change with mine on
OS X and it worked for all the inputs I tried.
Neal
> On Jul 11, 2021, at 2:11 AM, Jan Kratochvil wrote:
>
> On Sat, 10 Jul 2021 10:51
On Sun, 11 Jul 2021 14:49:25 +0200, Raphael “Teemperor” Isemann via lldb-dev
wrote:
> LLDB also provides a custom callback for libedit to read characters from the
> command line (which mariadb probably doesn’t), so maybe we implemented that
> incorrectly.
Missing setlocale(), filed it as:
Maybe mariadb is not using libedit in emacs mode?
LLDB also provides a custom callback for libedit to read characters from the
command line (which mariadb probably doesn’t), so maybe we implemented that
incorrectly.
- Raphael
> On 11 Jul 2021, at 13:45, Jan Kratochvil wrote:
>
> On Sun, 11 J
On Sun, 11 Jul 2021 13:07:26 +0200, Raphael “Teemperor” Isemann wrote:
> What libedit version/port is Fedora using?
> [1] https://thrysoee.dk/editline/
Source RPM : libedit-3.1-37.20210522cvs.fc34.src.rpm
URL : https://www.thrysoee.dk/editline/
> I think the usual Linux port[1] is suffe
What libedit version/port is Fedora using? I think the usual Linux port[1] is
suffering from two issues: One is that most unicode characters with code points
<= 256 are mapped to ‘unassigned’ instead of ‘insert character’ which prevents
them from being entered. Why the other characters are just
On Sun, 11 Jul 2021 11:11:02 +0200, Jan Kratochvil via lldb-dev wrote:
> OTOH the wide character does not work there and even not on Fedora 34 x86_64:
> typing: žščř
> (lldb) \U+017E\U+0161\U+010D\U+0159
> error: 'žščř' is not a valid command.
> typing: áéíóůúý
> (lldb) \U+016F
> error: 'ů' is not
On Sat, 10 Jul 2021 10:51:34 +0200, Neal Sidhwaney via lldb-dev wrote:
> Anyone else think this could be useful? Or, conversely, does anyone see
> something that I missed that requires the conditional compilation to remain
> in?
Oldest platform Red Hat builds LLDB on is RHEL-7 (and its copies) and
Hello,
I was thinking of removing the conditional compilation to use libedit’s WCHAR
support on non-Windows platforms. The conditional preprocessor logic is
definitely the correct way to support both wide & narrow character APIs, but
editline has enabled the wide API’s by default for some time
