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

Gvim under Linux: Quirky ligatures and no texture healing #244

Open
mscheper opened this issue Aug 6, 2024 · 2 comments
Open

Gvim under Linux: Quirky ligatures and no texture healing #244

mscheper opened this issue Aug 6, 2024 · 2 comments

Comments

@mscheper
Copy link

mscheper commented Aug 6, 2024

Now that #17 is fixed (thank you!), I'm trying Monaspace out in Gvim again. The font appears, but texture healing isn't working, and when I try to enable ligatures, it's quirky.

Software versions:

  • Linux Mint 21.3 Cinnamon
  • Gvim 8.2.2121
  • Monaspace v1.101

Gvim settings:

set guifont=Monaspace\ Neon
" The following line causes the quirky ligatures
set guiligatures=!\"#$%&()*+-./:<=>?@[]^_{\|~}
" Originally I had the following line as well, but since this setting only applies to Windows, it's irrelevant
set renderoptions=type:directx

The results look like the example on the Monaspace website with Texture healing unticked.

The attached screenshot is with guiligatures set; note that the slashes (/) at the beginning of the comments are offset to the left and not fully rendered. Interestingly, this doesn't happen when the block cursor is over it, so it might be an issue with Gvim or whatever it uses to render the character, but it would be helpful to know whether I'm setting this up correctly. Let me know if there are any other settings that I could try, or applications other than Gvim that you would expect to work. Thanks.

Screenshot from 2024-08-06 15-11-02

@mscheper
Copy link
Author

mscheper commented Aug 9, 2024

The slashes looking different under the cursor is a known bug with Gvim.

@manuelschiller
Copy link

manuelschiller commented Dec 6, 2024

Hi, I'm the one who came up with the original ligature patch for gVim (that for a while I maintained separately and then got adapted,cleaned up substantially, and then included by vim developers). The reason why this does not work as intended is that gVim builds a glyph cache to bypass the shaping stage of the rendering (to be fast). The way I understand it, the texture healing happens through a trick during the shaping stage (i.e. the font has some special glyphs to swap in for particular character combinations). Setting guiligatures tells gVim which characters are not rendered via the glyph cache, but undergo the full shaping process. With your set of characters in guiligatures, most character combinations that texture healing could work on will never run through the full shaping process, and thus get the default, non-texture-healed version of the character rendered.
Could you try and see if the following in your vimrc makes any difference, please?

set guiligatures=!\"$%&\'()*+,-./:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{\|}~

Also, I think you should not expect advanced features like glyph healing or ligatures to work across changes in syntax highlighting due to the way drawing characters works inside gvim... (As I understand it, that has to do with the fact that there is no way to run the glyph shaping, and apply attributes like colour, italic, bold, or underline after the glyph shaping process. Consider the characters "->" which often get substituted with a special glyph for languages like C or C++. This works fine if the "-" and the ">" are drawn with the same attributes, because they usually enter the glyph shaping together. When they have different attributes, they are drawn separately, though, and there is also no way to draw the special glyph that they use for "->" with one set of attributes for the first half and another for the second half... If it's just different colours, somebody determined enough might be able to push through changes to the upstream libraries used to render text to screen, but if it's other attributes like boldness or italics, there is just no way to do this because the substituted glyph halves would have to come from different font files, and there is no way to make sure things match up where they would join...)

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

No branches or pull requests

2 participants