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

Lines only stretch half-way when locale is Chinese #25

Open
Pu-Anlai opened this issue Sep 25, 2019 · 10 comments
Open

Lines only stretch half-way when locale is Chinese #25

Pu-Anlai opened this issue Sep 25, 2019 · 10 comments

Comments

@Pu-Anlai
Copy link

This is probably the same issue as #24, but since that one's closed, I thought I open a new one.
As it turns out this is caused by running within a Chinese locale. You can reproduce this behaviour by running env LC_CTYPE=zh_CN.utf-8 emacs.
I guess this could have something to do with double-width characters? Just a guess, though.

@purcell
Copy link
Owner

purcell commented Sep 25, 2019

Is it just in a terminal, or also in a GUI frame?

@Pu-Anlai
Copy link
Author

Yeah, the effect is the same.

I dug around a bit in page-break-lines' source and found out that page-break-lines-char has a different width depending on the locale.
(char-width page-break-lines-char) evaluates to 2 if I set LC_TYPE to Chinese, otherwise to 1. From what I understand, the width of the window is divided by this value. So that might be why the line is cut in half.

@purcell
Copy link
Owner

purcell commented Sep 25, 2019

Hmm, that's frustrating: it means char-width isn't really working correctly for that character. That code was introduced in #13, to fix a related problem. I'm not yet sure how best to make both scenarios work. I guess it would be possible to allow users to override the computed width, but that seems very hacky.

@Ailrun
Copy link

Ailrun commented Aug 26, 2020

I can reproduce this under Korean language environment too.

@purcell
Copy link
Owner

purcell commented Aug 26, 2020

That code originally came from @knu, and the rationale was this:

When page-break-lines-char is a wide character, each page break turns to
two lines. Unfortunately this is the case for the default value
(U+2500) in the East-Asian (CJK) language environments, because the
charater is rendered as wide character there.

I can't tell if the behaviour in the Chinese locale is an Emacs bug, or expected, but it seems like with the current code there's no obvious way for it to be correct everywhere.

@knu
Copy link
Contributor

knu commented Aug 27, 2020

Does (use-default-char-width-table) help? Emacs determines char-width-table to use from the language environment it is on, and the default in CJK locales is to (use-cjk-char-width-table), either implied by set-language-environment or the LANG environment variable.

@Ailrun
Copy link

Ailrun commented Aug 27, 2020

@knu It works at least for the separator. Do you know what problem may occur if I use default char width table with CJK languages?

@knu
Copy link
Contributor

knu commented Aug 27, 2020

Altering the char-width-table just for the separator could be a safe option for you, but if you try out the default table for awhile and don't see any trouble, you probably don't need the CJK behavior which CJK users need when dealing with characters from legacy encodings or traditionally used fonts.

@Ailrun
Copy link

Ailrun commented Aug 27, 2020

Could you tell me how I can alter the table only for the separators?

@knu
Copy link
Contributor

knu commented Aug 27, 2020

char-width-table is a char-table, so you can manipulate it with the generic char-table functions.

I haven't tested this at all, but I think you could do it this way:

(let ((table (make-char-table nil)))                   ;; make a new empty table
  (set-char-table-parent table char-width-table)       ;; make it inherit from the current char-width-table
  (set-char-table-range table page-break-lines-char 1) ;; let the width of page-break-lines-char be 1
  (setq char-width-table table))                       ;; use the new table as char-width-table

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

No branches or pull requests

4 participants