I haven't had time to look into the libedit stuff on Windows, but my understanding is that lldb on Windows has never been using libedit to begin with.  If that's the case, then we can probably continue not using it as that will eliminate the risk of any breaks, and python's builtin console control handler on Windows is not that bad.  It might be worth trying to port this implementation to Windows at some point, but if we're not using it currently (and I don't think we are), I don't see any reason to block this change because of Windows, as long as the change keeps it disabled for Windows.<br><div><br></div><div>On the Linux front, the times where I have had to work on Linux (testing patches etc) when you go into the embedded interpreter by typing "script", everything is totally broken, and you can't use anything that is not a simple ascii character.  No arrows, no control codes, nothing.  Do you know if this patch fixes that on Linux (or at least assuming the issues you pointed out are addressed, will it fix that)?</div><br><div class="gmail_quote">On Tue Oct 28 2014 at 12:45:54 PM Shawn Best <<a href="mailto:sbest@blueshiftinc.com">sbest@blueshiftinc.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is a significant Editline rewrite, adding a bunch of<br>
improvements.  It has been well tested on OSx, but not yet upstreamed.<br>
I have spent some time reviewing the proposed patch and working through<br>
issues to get it running on linux.  To see the patch and accompanying<br>
discussion, refer to: <a href="http://reviews.llvm.org/D5835" target="_blank">http://reviews.llvm.org/D5835</a>    The main issues<br>
that came up are related to handling wide characters and differences<br>
between platforms.<br>
<br>
Internally, lldb uses std::string which is an array of 8 bit chars, that<br>
can either be 7 bit ascii, or utf8 encoded wide characters. Libedit uses<br>
either char, or wchar_t which is a 32 bit char on linux.<br>
<br>
<codecvt> : the patch uses a c++ 11 class std::codecvt_utf8, this is a<br>
facet implementation that will do utf8 to wchar convervsion.  It is part<br>
of c++ 11 standard, but not yet supported in gcc.  I can use #ifdef to<br>
temporarily write equivalent functionality in that case while we wait<br>
for gcc to catch up.<br>
<br>
libedit : libedit is a prerequisite that a new linux/lldb user installs<br>
( sudo apt-get install libedit-dev ).  A few years ago, libedit added<br>
versions of its functions that work on wchar_t. Unfortunately, this<br>
option is not built by default, and not present in the Ubuntu<br>
distribution.  To get around this, I see a few options:<br>
<br>
- take libedit source files (or subset) and add to the lldb project.  We<br>
could either build a .so file, or just statically link the .cpp files.<br>
<br>
- rework the Editline rewrite, so it either uses standard 8 bit chars,<br>
or wchar_t/utf8 depending on the platform.  This would be conditionally<br>
built depending on the platform.<br>
<br>
- modify Ubuntu, so 'sudo apt-get install dev-libedit' installs a<br>
version that has been built with wide character support enabled.<br>
<br>
- introduce custom step for new linux lldb users, where they download<br>
libedit source and build and install a wchar version<br>
<br>
The last 2 options don't seem that great.<br>
<br>
I expect there will be problems on Windows, which I think uses utf16<br>
coding.  The file EditLineWin.cpp, contains prototypes for most of the<br>
structures and functions needed, but they look stubbed out.<br>
<br>
Any thoughts?<br>
<br>
Shawn.<br>
______________________________<u></u>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
</blockquote></div>