Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Compiling with ncurses instead of ncursesw breaks alignment/repaint #1240

Open
mqudsi opened this issue Oct 20, 2022 · 4 comments
Open

Compiling with ncurses instead of ncursesw breaks alignment/repaint #1240

mqudsi opened this issue Oct 20, 2022 · 4 comments

Comments

@mqudsi
Copy link
Contributor

mqudsi commented Oct 20, 2022 •
edited
Loading

Compiling tig (from master) with libncurses-dev but no libncursesw5-dev installed causes tig to experience some alignment issues and repaint problems that do not happen with libncursesw5-dev installed/used instead.

Here's how it looks with the following configuration:

...
configure: WARNING: The found ncurses library does not support wide-char.
configure: WARNING: This means that tig will not correctly render UTF-8.
...

giving

tig version 2.5.7
ncursesw version 6.1.20180127 # this is wrong?
readline version 7.0
PCRE2 version 10.31 2018-02-12
tig.mp4

And here's how it looks compiled with libncursesw5-dev correctly installed instead:

tig version 2.5.7
ncursesw version 6.1.20180127
readline version 7.0
PCRE2 version 10.31 2018-02-12
tig2.mp4

Behavior observed under both Kitty and conhost (Windows cmd). Behavior not reproducible in some other terminal emulators.

I don't think UTF-8 is a factor, at least it shouldn't be as I don't think I see any non-ASCII characters in the output on screen at a glance. If tig is using Unicode/non-ASCII symbols for display/formatting, then it shouldn't if no libncursesw was detected (in which case wide character support would only be used for git messages or file contents containing Unicode characters).
mqudsi added a commit to mqudsi/tig that referenced this issue Oct 20, 2022
@mqudsi
Correctly report which version of libncurses was linked
82e37fd 
Later versions of ncurses (20111030 and up) support NCURSES_WIDECHAR even when
compiling with libncurses instead of libncursesw.

Have tig correctly report whether it was linked against libncursesw or
libncurses based off the same defines we set in the build script and use to
determine which headers to include.

(See jonas#1240 as an example of where `tig --version` incorrectly reports `ncursesw`
instead of `ncurses`).
@mqudsi mqudsi mentioned this issue Oct 20, 2022
Merged
@krobelus
Copy link
Contributor

@mqudsi No idea what's the cause of this issue but it's nice that you're also using Tig :)
I use it for all my code archaeology and code review needs.
I wanna work on it some more, add new UI features etc. but the code can be quite dense.

@mqudsi
Copy link
Contributor Author

mqudsi commented Oct 21, 2022

Hey, hey @krobelus. Nice to bump into you here too - I had to double-check I had the right repository when I ran tig and saw your name come up here as well!

I use tig to see relationships between branches and - most importantly - to navigate backwards in git blame history. The ergonomics aren't the greatest (I'm annoyed by how paging in the left and right hand panes necessarily has different bindings), but it gets the job done.

WRT to the behavior described in this bug: it's old and goes back to 2018. Not sure if bisecting will help, but if I have some time I can give that a try.

mqudsi added a commit to mqudsi/tig that referenced this issue Nov 20, 2022
@mqudsi
Correctly report which version of libncurses was linked
5636769 
Later versions of ncurses (20111030 and up) support NCURSES_WIDECHAR even when
compiling with libncurses instead of libncursesw.

Have tig correctly report whether it was linked against libncursesw or
libncurses based off the same defines we set in the build script and use to
determine which headers to include.

Per the build system, either of HAVE_NCURSESW_H or HAVE_NCURSESW_CURSES_H may
indicate the presence of ncursesw, so both are checked.

(See jonas#1240 as an example of where `tig --version` incorrectly reports `ncursesw`
instead of `ncurses`).
koutcher pushed a commit that referenced this issue Nov 20, 2022
@mqudsi
Correctly report which version of libncurses was linked (#1241)
d5e3fc3 
Later versions of ncurses (20111030 and up) support NCURSES_WIDECHAR even when
compiling with libncurses instead of libncursesw.

Have tig correctly report whether it was linked against libncursesw or
libncurses based off the same defines we set in the build script and use to
determine which headers to include.

Per the build system, either of HAVE_NCURSESW_H or HAVE_NCURSESW_CURSES_H may
indicate the presence of ncursesw, so both are checked.

(See #1240 as an example of where `tig --version` incorrectly reports `ncursesw`
instead of `ncurses`).
@koutcher koutcher closed this as completed Nov 1, 2023
@mqudsi
Copy link
Contributor Author

mqudsi commented Nov 1, 2023

@koutcher is there a commit that fixes this?

@koutcher
Copy link
Collaborator

koutcher commented Nov 2, 2023

@mqudsi, sorry I was mistaken by your PR being merged. Note that if the problem happens only with some terminals the problem is unlikely to be in Tig, it rather be in the terminfo description for this terminal. You can try to add a private terminfo entry in ~/.terminfo using infocmp and tic. The terminfo entry for putty in CentOS 6 was really broken, it worked much better with the one from CentOS 7. I don't know about kitty.

@koutcher koutcher reopened this Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mqudsi @krobelus @koutcher