search

jming422 / fira-code-mode

Emacs minor mode for Fira Code ligatures using prettify-symbols
GNU General Public License v3.0
103 stars 11 forks source link

fira-code-mode conflicts with variable-pitch-mode #24

Closed oldaccountdeadname closed 2 years ago

oldaccountdeadname commented 2 years ago

In org-mode, I'm using variable-pitch-mode to use a non-monospace font for prose, but Fira in some other contexts (headers, code samples, &c). Because of this, I have fira-code-mode enabled in org-mode buffers, but most of my text isn't actually in Fira Code. This causes problems when I use some ligatured characters, i.e., if I were to type out the literal --- in non-fira prose. See the below, where I've typed the literal This is an --- example, but the rendering offsets the --- characters backwards into an. I can only repro with fira-code-mode enabled.

2022-03-17-110529_180x60_scrot

This is definitely an odd use case, and there's no need to support it! Feel free to unceremoniously close this issue if you don't feel like this is worth the complexity to patch up. fira-code-mode works great as is everywhere remotely normal :)

jming422 commented 2 years ago

That is a fun use case I haven't seen before, and yeah it doesn't surprise me that fira-code-mode isn't behaving properly in that context. Since it's based on Emacs's builtin prettify-symbols-mode, you can probably do what you want by customizing prettify-symbols-compose-predicate in your org-mode buffers. This variable contains a function responsible for telling prettify-symbols-mode whether or not to compose matched symbols into ligatures -- if you altered it to return nil when the symbol is part of variable pitch text that would probably do it.

Since your use case is pretty specific, I don't know if there's much to be done inside the package itself that would be generally useful, but you're welcome to contribute documentation of your findings so that others interested in this customization can follow your lead!

This is definitely an odd use case, and there's no need to support it! Feel free to unceremoniously close this issue if you don't feel like this is worth the complexity to patch up. fira-code-mode works great as is everywhere remotely normal :)

This is very kind of you to say, I appreciate it 😄 I think I will close this issue not because I don't think it's good, but because I think it should be customizable already without additional features from fira-code-mode. I'm not sure exactly how that customization would work though, so feel free to post to this issue if you find a solution and feel motivated to share it; I think it'd be a good candidate for the Customization section of the README.

Side note, weird ligature widths is one of the shortcomings of prettify-symbols-mode, which Emacs' upcoming builtin support for font-based ligatures is supposed to help with. I've been testing out support for native font ligatures using Emacs 28 + Doom Emacs' ligatures module and so far it has worked excellently for me. If you were to use a setup like this one based on a newer version of Emacs with composition-function-table, then you may have better luck, since the ligature shape and width is determined by the font shaping engine instead of being hardcoded into somebody's (my) elisp code. But also I don't know how composition-function-table will fare in a buffer with multiple fonts, so YMMV with that I suppose.