Hold on, upstream patched this in a different way... will be comparing the two and testing.

Upstream commit: llvm-mirror/lldb@9ad9480

Both patches seem to fix usage of libedit, arrow keys/tab-completion are working (as compared to current lldb).

Unfortunately I'm not sure which patch is appropriate, neither seem to handle input containing utf8.

Dummy little program with some unicode symbols for testing with:

class ooɟ {
public:
__attribute__((noinline))
  void こんにちは() {}
};

__attribute__((noinline))
void test() {
  ooɟ f;
  f.こんにちは();
}
int main() {
  test();
}

Tested using my patch (basically same as voidlinux's patch[1]), upstream's patch, both....cross two libedit versions-- our current libedit and newest version that enables unicode by default....

• All configurations resolve the arrow-keys/tab-completion/etc problems
• Setting WCHAR=1 (our/void patch): unicode strings pasted as input display as escaped strings.
• Upstream patch: unicode strings pasted as input have non-ascii characters stripped/dropped AFAICT
• Both patches: behavior matches WCHAR=1 AFAICT.

Changing libedit version does not seem to have any impact on tested behavior.

[1] void's issue on this: https://github.com/voidlinux/void-packages/issues/6073

I vote we use the patch I originally proposed and ignore upstream's patch for now:

• Without libedit (current situation), arrow keys, history, tab-completion .. all of these features don't work. These seem pretty important!
• The upstream patch causes unicode characters to silently disappear which seems worse IMO; I'd rather see escaped characters that scream "I'm not being handled properly".
• libedit features seem significantly more input than attempting to accommodate usage of commands containing unicode.
  • In all configurations I can't seem to get lldb to tab-complete non-ascii symbols or to set breakpoints on them, so this experience might be broken regardless.

I would say we prefer upstream patches, but your argument makes sense.