[GH-ISSUE #144] panic: line style LineStyleLight line part linePartHAndUp is a rune ┴ with width 2, all parts must be half-width runes (width of one)

kerem commented

2026-03-03 16:22:16 +03:00

Owner

Originally created by @pathbox on GitHub (Feb 20, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/144

Hi,
I run the code from https://github.com/mum4k/termdash/blob/master/widgets/gauge/gaugedemo/gaugedemo.go in my Mac, but it panic:

panic: line style LineStyleLight line part linePartHAndUp is a rune ┴ with width 2, all parts must be half-width runes (width of one)

goroutine 1 [running]:
github.com/mum4k/termdash/draw.init.0()
	/Users/pathbox/gowork/src/github.com/mum4k/termdash/draw/line_style.go:76 +0x294
exit status 2

I don't know the reason

It can't run in macOS(10.14.3) ?

I try another demo, the same question is happened,too.

I find the source code is:

func init() {
	for ls, parts := range lineStyleChars {
		for part, r := range parts {
			if got := runewidth.RuneWidth(r); got > 1 {
				panic(fmt.Errorf("line style %v line part %v is a rune %c with width %v, all parts must be half-width runes (width of one)", ls, part, r, got))
			}
		}
	}
}

It seems that it is about rune width of the hAndUp '┴', I don't know how to solve it

Originally created by @pathbox on GitHub (Feb 20, 2019). Original GitHub issue: https://github.com/mum4k/termdash/issues/144 Hi, I run the code from `https://github.com/mum4k/termdash/blob/master/widgets/gauge/gaugedemo/gaugedemo.go` in my Mac, but it panic: ``` panic: line style LineStyleLight line part linePartHAndUp is a rune ┴ with width 2, all parts must be half-width runes (width of one) goroutine 1 [running]: github.com/mum4k/termdash/draw.init.0() /Users/pathbox/gowork/src/github.com/mum4k/termdash/draw/line_style.go:76 +0x294 exit status 2 ``` I don't know the reason It can't run in macOS(10.14.3) ? I try another demo, the same question is happened,too. I find the source code is: ``` func init() { for ls, parts := range lineStyleChars { for part, r := range parts { if got := runewidth.RuneWidth(r); got > 1 { panic(fmt.Errorf("line style %v line part %v is a rune %c with width %v, all parts must be half-width runes (width of one)", ls, part, r, got)) } } } } ``` It seems that it is about rune width of the `hAndUp '┴'`, I don't know how to solve it

kerem

2026-03-03 16:22:16 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-03 16:22:17 +03:00

Author

Owner

@mum4k commented on GitHub (Feb 20, 2019):

Hi, thank you for the bug report. I can confirm that this indeed does work on MacOS, since that is my primary OS.

In order to troubleshoot - could you provide a few more information about your environment? Specifically:

What terminal application do you use on MacOS?
Can you copy&pate the output of the following command from the terminal application?

env | egrep "LANG|CTYPE"

@mum4k commented on GitHub (Feb 20, 2019): Hi, thank you for the bug report. I can confirm that this indeed does work on MacOS, since that is my primary OS. In order to troubleshoot - could you provide a few more information about your environment? Specifically: 1. What terminal application do you use on MacOS? 1. Can you copy&pate the output of the following command from the terminal application? ``` env | egrep "LANG|CTYPE" ```

kerem commented

2026-03-03 16:22:17 +03:00

Author

Owner

@pathbox commented on GitHub (Feb 20, 2019):

@mum4k
terminal application is zsh+ITerm

env | egrep "LANG|CTYPE" is:

LANG=zh_CN.UTF-8
LC_CTYPE=zh_CN.UTF-8

what is your env | egrep "LANG|CTYPE" ?

@pathbox commented on GitHub (Feb 20, 2019): @mum4k terminal application is zsh+ITerm env | egrep "LANG|CTYPE" is: ``` LANG=zh_CN.UTF-8 LC_CTYPE=zh_CN.UTF-8 ``` what is your `env | egrep "LANG|CTYPE"` ?

kerem commented

2026-03-03 16:22:17 +03:00

Author

Owner

@mum4k commented on GitHub (Feb 20, 2019):

Thank you. Termdash only supports the UTF-8 locale. Characters in other locales might map to different width based on context which resulted in the reported error. Although we should probably improve the error...

To confirm - could you try setting these to en_US.UTF-8 and retry?

That is:

export LANG=en_US
export LC_CTYPE=en_US.UTF-8

And run any of the demos? Please let me know if that helps.

@mum4k commented on GitHub (Feb 20, 2019): Thank you. Termdash only supports the UTF-8 locale. Characters in other locales might map to different width based on context which resulted in the reported error. Although we should probably improve the error... To confirm - could you try setting these to en_US.UTF-8 and retry? That is: ``` export LANG=en_US export LC_CTYPE=en_US.UTF-8 ``` And run any of the demos? Please let me know if that helps.

kerem commented

2026-03-03 16:22:17 +03:00

Author

Owner

@pathbox commented on GitHub (Feb 21, 2019):

@mum4k Yes, you are right. I do this:

export LANG=en_US
export LC_CTYPE=en_US.UTF-8

then it works.

Do you have the solution about this question? Or you can do some warning in the README

Thank you very much

@pathbox commented on GitHub (Feb 21, 2019): @mum4k Yes, you are right. I do this: ``` export LANG=en_US export LC_CTYPE=en_US.UTF-8 ``` then it works. Do you have the solution about this question? Or you can do some warning in the README Thank you very much

kerem commented

2026-03-03 16:22:17 +03:00

Author

Owner

@mum4k commented on GitHub (Feb 21, 2019):

Thank you for confirming this. I think I have a solution. Termdash uses certain characters for drawing (like the line character in the panic) which can have "ambiguous" width in some East-Asian locales.(http://www.unicode.org/reports/tr11/).

This means that the number of cells they occupy depends on the context (the surrounding characters). The library we use to determine the width defensively reports a width of two for these characters since it cannot be sure.

From what I read today - considering that we know the full context of these characters I think it is safe to override the ambiguity and assume they will have a width of one cell even in East-Asian. That might be safe, because we place and know all the other characters around them (lines, boxes, pixels).

I will keep this bug open until I push the fix. If you have the time, I would appreciate if you could test it afterwards.

@mum4k commented on GitHub (Feb 21, 2019): Thank you for confirming this. I think I have a solution. Termdash uses certain characters for drawing (like the line character in the panic) which can have "ambiguous" width in some East-Asian locales.(http://www.unicode.org/reports/tr11/). This means that the number of cells they occupy depends on the context (the surrounding characters). The library we use to determine the width defensively reports a width of two for these characters since it cannot be sure. From what I read today - considering that we know the full context of these characters I think it is safe to override the ambiguity and assume they will have a width of one cell even in East-Asian. That might be safe, because we place and know all the other characters around them (lines, boxes, pixels). I will keep this bug open until I push the fix. If you have the time, I would appreciate if you could test it afterwards.

kerem commented

2026-03-03 16:22:17 +03:00

Author

Owner

@pathbox commented on GitHub (Feb 22, 2019):

I am glad to test it afterwards

@pathbox commented on GitHub (Feb 22, 2019): I am glad to test it afterwards

kerem commented

2026-03-03 16:22:17 +03:00

Author

Owner

@mum4k commented on GitHub (Feb 22, 2019):

Thank you again for the bug report. I have pushed the fix into the devel branch. It isn't released into master yet, but I would appreciate if you could try building from the devel branch.

Can you confirm if it starts without the workaround? You shouldn't need to change the locale anymore.

@mum4k commented on GitHub (Feb 22, 2019): Thank you again for the bug report. I have pushed the fix into the [devel branch](https://github.com/mum4k/termdash/tree/devel). It isn't released into master yet, but I would appreciate if you could try building from the devel branch. Can you confirm if it starts without the workaround? You shouldn't need to change the locale anymore.

kerem commented

2026-03-03 16:22:18 +03:00

Author

Owner

@pathbox commented on GitHub (Feb 27, 2019):

Hi，I try the devel branch ， it panic：

gaugedemo.go:13:2: cannot find package "github.com/mum4k/termdash/draw" in any of:
	/usr/local/go/src/github.com/mum4k/termdash/draw (from $GOROOT)

the draw folder is missing

@pathbox commented on GitHub (Feb 27, 2019): Hi，I try the devel branch ， it panic： ``` gaugedemo.go:13:2: cannot find package "github.com/mum4k/termdash/draw" in any of: /usr/local/go/src/github.com/mum4k/termdash/draw (from $GOROOT) ``` the `draw` folder is missing

kerem commented

2026-03-03 16:22:18 +03:00

Author

Owner

@mum4k commented on GitHub (Feb 27, 2019):

Thank you for finding the time and testing this. Is it possible that you made some local edits to the gaugedemo? I am asking because looking at the gaugedemo, it actually doesn't import "draw" anymore.

github.com/mum4k/termdash@275d95ad41/widgets/gauge/gaugedemo/gaugedemo.go (L23-L29)

Can you also make sure you are synced to the latest commit on the devel branch? I have recently moved the draw package into the internal subdirectory.

It would help me if you could try running an unmodified version of the gaugedemo.

@mum4k commented on GitHub (Feb 27, 2019): Thank you for finding the time and testing this. Is it possible that you made some local edits to the gaugedemo? I am asking because looking at the gaugedemo, it actually doesn't import "draw" anymore. https://github.com/mum4k/termdash/blob/275d95ad418b6ecca8817de4b013b440fc9abbe6/widgets/gauge/gaugedemo/gaugedemo.go#L23-L29 Can you also make sure you are synced to the latest commit on the devel branch? I have recently moved the draw package into the internal subdirectory. It would help me if you could try running an unmodified version of the gaugedemo.

kerem commented

2026-03-03 16:22:18 +03:00

Author

Owner

@pathbox commented on GitHub (Feb 27, 2019):

Yeah, and I test the code, it works fine, you fix it, it is good~

@pathbox commented on GitHub (Feb 27, 2019): Yeah, and I test the code, it works fine, you fix it, it is good~

kerem commented

2026-03-03 16:22:18 +03:00

Author

Owner

@mum4k commented on GitHub (Feb 27, 2019):

Thank you very much for confirming.

@mum4k commented on GitHub (Feb 27, 2019): Thank you very much for confirming.

kerem referenced this issue

2026-03-03 16:23:15 +03:00

[PR #90] [MERGED] Added LineStyleRound #196

Rows
Columns

[GH-ISSUE #144] panic: line style LineStyleLight line part linePartHAndUp is a rune ┴ with width 2, all parts must be half-width runes (width of one) #90