Skip to content
This repository has been archived by the owner on Oct 13, 2021. It is now read-only.

weird example rendering #85

Open
blazingsiyan opened this issue Dec 22, 2017 · 10 comments
Open

weird example rendering #85

blazingsiyan opened this issue Dec 22, 2017 · 10 comments
Labels

Comments

@blazingsiyan
Copy link

Hi, I am trying to use tui-go
but I cannot reproduce the example screenshot on my mbp
I just go get -u -v github.com/marcusolsson/tui-go
and go run example/chat/main.go
then get this
image

any suggestion?
I have tried different terminals(terminal.App, iterm2, vscode terminal),
different shells(bash, zsh) and
different fonts(menlo, mocano, .etc)...

go version: go1.9.2 darwin/amd64
tui-go: dc279e8

@blazingsiyan blazingsiyan changed the title weired example rendering weird example rendering Dec 22, 2017
@marcusolsson
Copy link
Owner

I have tried combinations of the different configurations you mentioned, but I'm not able to reproduce your screenshot. Are you seeing the same issues with the other examples? Is your screenshot what you get directly on start, or after resizing?

@blazingsiyan
Copy link
Author

yup, directly on start, and the scenario can be found in other examples
image

I have also tried termui mentioned in the article, the rendering is working fine to me

@cceckman
Copy link
Contributor

Driveby: would https://asciinema.org be helpful in conveying reproductions / captures?

@cceckman
Copy link
Contributor

@doubajam : What's your locale?

I note that runewidth starts turning up different values based on the system locale, namely, if IsEastAsian comes up true. Maybe the rendering of borders is treating them as wide characters when in an East Asian locale?

@blazingsiyan
Copy link
Author

@cceckman
oh right, my system locale is Chinese!
I am new to go, but it seems not too hard to deal with different runewidth
thanks~

@cceckman
Copy link
Contributor

cceckman commented Jan 4, 2018

Can you reproduce this with tui-go 0.3.0? There was some improved handling of rune widths in the word wrap, but I don't think bug bordering has changed, so it may still be an issue.

And- can you dump the output of the locale command? That will help us reproduce the issue and then debug.

Thanks for bringing this up!

@blazingsiyan
Copy link
Author

I can reproduce on e15c085
my locale is

$ locale
LANG="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_CTYPE="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_ALL=

@cceckman
Copy link
Contributor

cceckman commented Jan 5, 2018

Thanks! I can definitely reproduce using those locale settings, while it works as expected under my own - see screencap at https://asciinema.org/a/155655 for how I reproduced.

I'm guessing Box's draw-border stanza is stepping farther than it should when drawing borders when in an East Asian locale. No idea why that would be, but that's a starting point.

@cceckman
Copy link
Contributor

cceckman commented Jan 5, 2018

OK, quick trace through indicates this may be an issue with tcell or its use.

The stack is painter.DrawRect -> surface.SetCell -> screen.SetCell, which is a tcell call: https://godoc.org/github.com/gdamore/tcell#Screen

To quote there,

    // SetCell is an older API, and will be removed.  Please use
    // SetContent instead; SetCell is implemented in terms of SetContent.
    SetCell(x int, y int, style Style, ch ...rune)

What about SetContent, then?

    // SetContent sets the contents of the given cell location.  If
    // the coordinates are out of range, then the operation is ignored.
    //
    // The first rune is the primary non-zero width rune.  The array
    // that follows is a possible list of combining characters to append,
    // and will usually be nil (no combining characters.)
    //
    // The results are not displayd until Show() or Sync() is called.
    //
    // Note that wide (East Asian full width) runes occupy two cells,
    // and attempts to place character at next cell to the right will have
    // undefined effects.  Wide runes that are printed in the
    // last column will be replaced with a single width space on output.
    SetContent(x int, y int, mainc rune, combc []rune, style Style)

So- for the runes used to draw borders, how wide does tcell / runewidth think they are when in an E. Asian locale? I'm guessing "wide". :-)

@Tnze
Copy link

Tnze commented Aug 30, 2019

So what can we do for fixing it?

┌ ─ ─ ─ ─ ─ ─ ─ ┐ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
│ HANNELS       │                                             
│ eneral        │                                             
│ andom         │                                             
│               │                                             
│ IRECT MESSAGES│                                             
│ lackbot       │                                             
│               │                                             
│               │                                             
│               │                                             
│               │                                             
│               │                                             
│               │ 14:41 <john> hi, what's up?                 
│               │ 14:43 <jane> not much                       
│               │ 21:09 <john> The border rendering..         
│               │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
│               │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
│               │                                             
└ ─ ─ ─ ─ ─ ─ ─ ┘ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants