On Tue, Oct 28, 2014 at 02:53:28PM +0100, Dmitrij D. Czarkoff wrote:
> Silvan Jegen said:
> > I do agree that this is the right approach. There is however another
> > instance of a wcwidth call on line st.c:3443 that should be handled as
> > well (maybe with abs in that particular case?).
>
> As I
> Silvan Jegen said:
>> I do agree that this is the right approach. There is however another
>> instance of a wcwidth call on line st.c:3443 that should be handled as
>> well (maybe with abs in that particular case?).
>
> As I get it, by the time wcwidth() is called there, all codepoints libc
> is
On Tue, 28 Oct 2014 11:11:03 -0300
dequis wrote:
> In practice, this only makes things worse by not displaying characters
> that are perfectly supported by fontconfig and xft, but not by libc.
> But... whatever.
It's your own fault when you use the broken glibc. File a bug-report
and wait for th
On 28 October 2014 08:54, Dmitrij D. Czarkoff wrote:
> Helpful when new Unicode codepoints are not recognized by libc.
In practice, this only makes things worse by not displaying characters
that are perfectly supported by fontconfig and xft, but not by libc.
But... whatever.
Silvan Jegen said:
> I do agree that this is the right approach. There is however another
> instance of a wcwidth call on line st.c:3443 that should be handled as
> well (maybe with abs in that particular case?).
As I get it, by the time wcwidth() is called there, all codepoints libc
is unaware of
On Tue, Oct 28, 2014 at 12:54 PM, Dmitrij D. Czarkoff
wrote:
> Helpful when new Unicode codepoints are not recognized by libc.
I do agree that this is the right approach. There is however another
instance of a wcwidth call on line st.c:3443 that should be handled as
well (maybe with abs in that p
Helpful when new Unicode codepoints are not recognized by libc.
---
st.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/st.c b/st.c
index 23dd7f1..ad52280 100644
--- a/st.c
+++ b/st.c
@@ -2576,7 +2576,10 @@ tputc(char *c, int len) {
unicodep = ascii = *c;
