bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38485: Customizing glyph widths


From: Clément Pit-Claudel
Subject: bug#38485: Customizing glyph widths
Date: Tue, 3 Dec 2019 23:22:35 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1

Hi all,

As recently discussed on emacs-devel (), it would be great to have a way to 
customize the way Emacs glyph widths. Here are the concrete use cases that I 
know of:

* Ensuring that glyphs from variable-pitch fonts line up with monospace text.  
A common problem with prettify-symbols-mode is that the current programming 
font doesn't have all necessary symbols, so they get picked from a different 
(possibly non-monospace) font with a different character width, which breaks 
alignment.  My current solution to this is to edit my font files directly 
(https://github.com/cpitclaudel/monospacifier).

* Ensuring that wide characters, such as fullwidth CJK characters, properly 
line up with surrounding monospace text, my making them occupy the width of two 
spaces of the default font, rather than their own width (two spaces of their 
own font).

One way to get the latter to work is to use composition to center each 
character over two spaces, but this is slow, inefficient, and it doesn't handle 
the former case where we sometimes want Emacs to fit a wider character into a 
narrower space.

Interestingly, both of these cases are handled quite nicely in emacs -nw, 
because there the display is purely grid-like.  I would like to have a way to 
do such grid-like display in graphical Emacs sessions as well, where each 
character occupies an exact multiple of the base character width, regardless of 
which font it comes from.  As I wrote on emacs-devel "Deciding what this 
multiple should be for each character could be done in various ways; for my 
purposes (and for OP's case as well, I think), it would be enough to use one 
cell for halfwidth characters, two for fullwidth characters, and add a few 
exceptions for things like TAB and zero-width spaces (I'm using the terms 
fullwidth and halfwidth in the sense of https://www.unicode.org/reports/tr11/)."

For my use case, it would be enough to have this available as a minor mode, but 
Yuan Fu mentioned the following on emacs-devel: "I’d like to see it as a face 
attribute instead of a mode. (Because I want to align my org table). Maybe 
there could be a face attribute (:grid WIDTH) that instructs the display engine 
to pad each glyph to have width that is a multiple of WIDTH in pixel, and if 
WIDTH is t, default to “base character width”?  I remembered that 
‘window-width’ gives width in char widths and had a look at its source. It 
knows the character width from FRAME_COLUMN_WIDTH; the comment says the value 
currently equals to the average width of the default font of the frame. I think 
this value can be used as the “base character width”."

Now that I think of it, though, I could see the use for a text property.  For 
example, prettify-symbols-mode could have an option to make each n-characters 
prettification n-characters wide, so that composing ~~> into ⟿ would produce a 
wide arrow occupying the exact same amount of space as the original uncomposed 
characters.

One last note: one common complaint at the moment about prettify-symbols-mode 
is that it breaks indentation: if I prettify -> into →, the latter is 
one-character wide and thus any subsequent line that lines up with the → is 
one-character too far to the left when viewed without compositions (e.g. in a 
web browser).  It would be wonderful if → could be centered into a 
two-spaced-wide cell and could count as occupying two columns (like TAB counts 
as occupying tab-width columns).

Cheers,
Clément.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]