<div dir="ltr">So, this is how the Windows version works and if you can tell me that this applies to Linux as well, I can hopefully whip up a patch over the weekend.<div><br></div><div>If the prompt string being output is UTF-8, tcsh is still putting each byte into a 32-bit int when WIDE_CHAR is set.</div><div><br></div><div>Therefore, it may actually be 2 Chars (or 3, or 4) in the prompt that are consumed for displaying an emoji or whatever. </div><div>However, the code in ed.refresh.c (RefreshPromptpart) is written to assume each Char is an independent byte.</div><div><br></div><div>So, in addition to wcwidth to find the length of the output, NLSWidthMB should also report how many Chars of the input string it consumed to represent  the emoji.  (line 318)</div><div><br></div><div>We should then increment cp by "+= consumed" in the above function while looping through the buffer, instead of by just 1. (line 320)</div><div><br></div><div>Does that sound right or am I missing something ?</div><div><br></div><div>thanks,</div><div>-amol</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 20, 2024 at 7:38 AM Kimmo Suominen <<a href="mailto:kim@netbsd.org">kim@netbsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 20, 2024 at 10:46:49AM +0200, H.Merijn Brand wrote:<br>
> With multibyte promptchars and a complicated prompt like<br>
> <br>
>  promptchars 🐧🔐<br>
>  prompt      xyz%{\e[47;34m0392\e[0m%} %U%m:%u%{\e[1m%}%/ %h %{\e[0;38;2;255;24;0m%}%#%{\e[0m%}<br>
> <br>
> Positioning inside the line when editing still frequently messes up. A<br>
> control-R fixes that, but I guess it should be smooth<br>
<br>
I think the issue is highlighted by this question I made:<br>
<br>
On Fri, 5 Apr 2024 12:47:05 +0300, Kimmo Suominen <<a href="mailto:kim@netbsd.org" target="_blank">kim@netbsd.org</a>> wrote:  <br>
> Why does it only apply to NLSCLASS_ILLEGAL2?  <br>
<br>
I think the whole logic there across the NLSCLASS_ILLEGALn cases is<br>
incorrect.<br>
<br>
> Do we have something already that correctly provides the rendering<br>
> width of the character?  Here is a Stack Overflow answer that points<br>
> to using wcwidth(3) and wcswidth(3):<br>
> <br>
>     <a href="https://stackoverflow.com/a/9145712/1511370" rel="noreferrer" target="_blank">https://stackoverflow.com/a/9145712/1511370</a><br>
> <br>
>     <a href="https://man.netbsd.org/wcwidth.3" rel="noreferrer" target="_blank">https://man.netbsd.org/wcwidth.3</a><br>
>     <a href="https://man.netbsd.org/wcswidth.3" rel="noreferrer" target="_blank">https://man.netbsd.org/wcswidth.3</a><br>
<br>
I think the correct implementation needs to include the detection of the<br>
rendering width of the characters.<br>
<br>
Kind regards,<br>
+ Kimmo<br>
<br>
-- <br>
Tcsh mailing list<br>
<a href="mailto:Tcsh@astron.com" target="_blank">Tcsh@astron.com</a><br>
<a href="https://mailman.astron.com/mailman/listinfo/tcsh" rel="noreferrer" target="_blank">https://mailman.astron.com/mailman/listinfo/tcsh</a><br>
</blockquote></div>