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.

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

Calculate the width of each displayed character #185

Merged
merged 2 commits into from
Apr 19, 2017
Merged

Calculate the width of each displayed character #185

merged 2 commits into from
Apr 19, 2017

Conversation

mptre
Copy link
Owner

@mptre mptre commented Apr 16, 2017

In an attempt to fix #184 caused by lines including Unicode characters
that occupy more than one column.

While at it, fix another bug related to the column counter when a line
contains more than one escape sequence.

Reviews and testing would be much appreciated I haven't discovered any
regression nor performance decrease running this diff so far.

/cc @calleerlandsson @mike-burns @teoljungberg.

Copy link
Contributor

@teoljungberg teoljungberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a test we can add for this change? Or is the testing setup we have now non-applicable for a change such as this?

pick.c Outdated
@@ -667,19 +667,23 @@ tty_restore(void)
}

void
print_line(const char *string, size_t length, int so, ssize_t ulso, ssize_t uleo)
print_line(const char *str, size_t len, int so, ssize_t ulso, ssize_t uleo)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I, for one, am of the view to write out as many acronyms as possible. But since we have ssize_t unt so weiter already, I'd say this falls in line with that style better.

@mptre
Copy link
Owner Author

mptre commented Apr 17, 2017

Is there a test we can add for this change? Or is the testing setup we have now non-applicable for a change such as this?

Unfortunately no. Since this change only concerns the displayed
TTY-output, it's not testable.

I, for one, am of the view to write out as many acronyms as possible. But since we have ssize_t unt so weiter already, I'd say this falls in line with that style better.

Agree, just renamed the arguments. Thanks!

Copy link
Collaborator

@calleluks calleluks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this @mptre, I really appreciate it!

I added some questions inline in the diff.

I did find a regression but haven't had time to figure out exactly why it's happening. Steps to reproduce:

  1. echo "🤔" | ./pick
  2. The standout spills over to the next line by one column. (see first screenshot below)
  3. Type a non-printable character (for example arrow keys)
  4. All lines (query and choice) are pushed down by one line (see second screenshot below)

I'm currently running bash 4.4.5 on macOS 10.12.4 with LC_CTYPE=UTF-8.

screen shot 2017-04-18 at 09 50 39

screen shot 2017-04-18 at 09 53 00

configure.ac Outdated
case "${host_os}" in
linux*) build_linux=yes ;;
esac
AM_CONDITIONAL([LINUX], [test "$build_linux" = "yes"])
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is $build_linux used solely to define LINUX so that it can be picked up in Makefile.am or is it used elsewhere?

configure.ac Outdated
AC_CANONICAL_HOST
build_linux=no
case "${host_os}" in
linux*) build_linux=yes ;;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't used AC_CANONICAL_HOST before and didn't find any documentation detailing the formatting of host_os. Is linux* a reliable pattern for catching all Linux-based OSs?

Makefile.am Outdated
@@ -2,6 +2,10 @@ AUTOMAKE_OPTIONS=foreign

AM_CFLAGS=-pedantic -Wall -Werror -Wextra

if LINUX
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could defining _XOPEN_SOURCE on non-linux platforms cause problems? If not, what do you think of always defining it? That way we could avoid the complexities of testing for the host os.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replying to all comments above here. Unfortunately no, defining it on
*BSD makes BSD-specific functions like pledge and reallocarray
unavailable.

Maybe @mike-burns could shed some insight on how-to solve this?

The OS detection is taken from here 1 2.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks for the links! I'm happy to try this and correct course if we run into issues with some distro.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why, from a quick skim of the repo, pledge disappears when defining _XOPEN_SOURCE. But I do see this in glibc: https://github.com/bminor/glibc/blob/963394a22b38c4ec92b6875a6c06d3b15d5c0d21/include/features.h#L186-L208

So maybe: skip the OS check (which should be a glibc check ... somehow?) and instead do:

AM_CPPFLAGS+=-D_GNU_SOURCE

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works, thanks!

pick.c Outdated
/* If uleo is greater than columns the underline attribute will spill
* over on the next line unless all attributes are exited. */
/*
* If uleo is greater than columns the underline attribute will spill
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this comment say exit_underline instead of uleo that the parameter names have been changed?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, fixed!

* mbtowc(3) returns 0 is not handled here.
*/
if ((nbytes = mbtowc(&wc, &str[i], MB_CUR_MAX)) == -1) {
mbtowc(NULL, NULL, MB_CUR_MAX);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this for resetting internal state of mbtowc?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct

@mptre
Copy link
Owner Author

mptre commented Apr 18, 2017

I did find a regression but haven't had time to figure out exactly why it's happening. Steps to reproduce:

Can't reproduce on OpenBSD but I will try it on macOS this evening.

@calleluks
Copy link
Collaborator

Thanks @mptre. Let me know if I can help you in any way!

In an attempt to fix a bug caused by lines including Unicode characters
that occupy more than one column.

While at it, fix another bug related to the column counter when a line
contains more than one escape sequence.
Required by posix_openpt(3) and wcwidth(3) on Linux.
@mptre
Copy link
Owner Author

mptre commented Apr 18, 2017

Turns out the passing that specific emoji to wcwidth(3) returns 0 on
macOS. This is fortunately not true for all emojis. I don't think we
should bother handling this edge-case.

OK to merge?

@calleluks
Copy link
Collaborator

Interesting. Searching for fixes, I found a lot of tickets and issues discussing this problem and a lot of homegrown solutions special casing certain characters. I'm of the opinion that pick(1) should solve these problems.

Looks good to merge.

@mptre mptre merged commit ffb4ca4 into master Apr 19, 2017
@mptre mptre deleted the width branch April 19, 2017 08:22
@mptre
Copy link
Owner Author

mptre commented Apr 19, 2017

Interesting. Searching for fixes, I found a lot of tickets and issues discussing this problem and a lot of homegrown solutions special casing certain characters. I'm of the opinion that pick(1) should solve these problems.

Can you create a separate issue and share your findings there?

Looks good to merge.

Done! Thanks for the feedback. Time to release?

@calleluks
Copy link
Collaborator

Sure thing!

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

Successfully merging this pull request may close these issues.

Texts are not aligned and position change while I scroll down...
4 participants