Editline Rewrite : issues surround wide character handling on different platforms

Libedit internally uses wchar_t to handle wide characters. For the types of things libedit does, I think a wchar_t is better suited than an array of utf8 coded bytes. The translations in question are for getting data in and out of libedit.

This means that support for extended characters in the command line history will be dependent on having <codecvt> support and a libedit built with wchar-t support, which, AFAIK, is only OSX.

Currently, I am reworking the patch, so it works with either libedit's char or wchar_t functions. This is a compile time decision.

If we want wide character support on other platforms down the road, it would make sense to bring the libedit functions into lldb. We can add a custom wchar to utf8 translations if gcc still does not support <codecvt>.

We shouldn’t. And this appears to have broken building on LInux. We need to revert this immediately.

Thanks.

-eric

This change has not been checked in. The current broken build on linux is due to a different checkin which included the same header file.

So “I’ve committed a similar change with the same problem”? :slight_smile:

It looks like it’s being fixed. Do try to be more careful, there is an lldb buildbot that’s been broken since this change went in:

http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang

Thanks.

-eric

No, none of my commits have this problem. The change that broke the build had nothing to do with me. I believe it was r220894 - Start adopting the StringPrinter API.

OK. Sorry about the misdirect, I’m still catching up after vacation and this thread looked like the culprit.

Thanks.

-eric