D12238: Use libc's wcwidth() instead of own function

[Mariusz Glebocki]

mglb added a comment.


  In D12238#264434 <https://phabricator.kde.org/D12238#264434>, @hindenburg wrote:
  
  > Also, I'm a little concerned that we're going to start having to request what version of libc users's have in bug reports. And then have to research how that version uses wcwidth.
  
  
  You are right here. I have wcwidth maps from several glibcs, so I am able to just grep a code point and verify if it has different width in some version. Sadly, this is not easily downloadable from some reliable source, so it is not an option to recommend.
  On the other hand, were there other bugs than "character width is wrong" or "cursor disappears on character/backspaces too much" (where it is obvious the width is wrong for the user), related to character width?
  
  BTW. Why there is no "Please attach `konsole --show-info-for-a-bug-report` output to the bug" and respective switch in Konsole, and custom additional info defined by a program in "report bug" feature? Could help in some cases, not only with this.
  
  > Where as now, we know everyone uses konsole_wcwidth.
  
  Sure, but we'll get less bugs than with konsole_wcwidth - people with newer libc won't have them, people with older version will get about as much as with konsole_wcwidth. Also, using system's wcwidth fixes bugs like "cursor in bash moves wrong" (392171) and similar problems with programs using system's wcwidth, for everyone.
  
  The ultimate (and complex) solution I was thinking about would be something like:
  
  - width maps specified in files; user can create or download new ones
  - possibility to specify default map in profile (e.g. system's wcwidth-based, or generated straight from Unicode files)
  - possibility to specify separate map for app-screen programs (vim-based map for vim, tig-based for tig, etc)
  
  This would solve problems with custom implementations, different libc, user preferences (including "Unicode is wrong, I want it this way" or improved powerline-like features). But due to complexity it probably won't appear soon.

REPOSITORY
  R319 Konsole

REVISION DETAIL
  https://phabricator.kde.org/D12238

To: mglb, #konsole
Cc: hindenburg, #konsole, herrold, ngraham, maximilianocuria
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/konsole-devel/attachments/20180518/f3cae676/attachment.html>