-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
feat(ligatures): use ligature.el for Emacs28+ #5082
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
Conversation
|
Added As discussed, it’s pretty hard to handle inheritance of derived modes, so I think the best way to do it is to allow users to override the only configuration that writes to "high priority" modes through |
|
Maybe the Not sure if that’s the better API, but I guess it unclutters the namespace |
To fix ligatures, at least until I get around to merging #5082
This comment has been minimized.
This comment has been minimized.
To fix ligatures, at least until I get around to merging doomemacs#5082
c70c38b to
82cc04a
Compare
|
(pong ; don't stale me bot) I don't remember the blocker, it was something around the API of |
0d84fc6 to
cc45900
Compare
cc45900 to
5ee089f
Compare
b176d34 to
9cc7c3e
Compare
0baa044 to
ff32dd9
Compare
5f647f4 to
63cb3d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just a few minor changes and I think it's good to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Include ligature.el in a new set-font-ligatures! function, so that "normal" (read: "font-based") ligatures can also be controlled on a per-major mode basis from a user function in configuration. This commit also drops support for Emacs 27 to reduce the maintenance burden. BREAKING CHANGE: font ligatures for Harfbuzz/Coretext composition table-based ligations are no longer controlled with `+ligatures-composition-alist`, but is handled with `+ligatures-prog-mode-list` and `+ligatures-all-modes-list` for most common cases. See the README for the mode-specific methods BREAKING CHANGE: the `:ui ligatures` module will not work anymore with Emacs 27 or older. Also, there is no need to keep patched fonts (for Fira, Hasklig, Iosevka) if you use the module. Update Emacs if you want to keep using ligatures, or disable the module (`doom doctor` will tell you if your current version of Emacs stopped working with the module)
dd0ebe0 to
dd78b71
Compare
I just squashed everything, I mostly left the commits like that to remember and revert parts of it if necessary. I don't think it makes a lot of sense to let this be multiple commits on master. |
|
LGTM! Thanks again for your help! |
Old lexical variable reference caused an error. Ref: doomemacs#7433 Amend: doomemacs#5082 Amend: 46d7404
Old lexical variable reference caused an error. Ref: doomemacs#7433 Amend: doomemacs#5082 Amend: 46d7404
Old lexical variable reference caused an error. Ref: doomemacs#7433 Amend: doomemacs#5082 Amend: 46d7404
As discussed briefly on Discord + Discourse, use https://github.com/mickeynp/ligature.el to handle the composition table for ligatures if using Emacs28+ with Harfbuzz.
This gives an easier API to handle per-user/per-mode configuration (potentially dealing with #4922 ), and all potential fixes can be targeted upstream instead of maintaining the code here (See #5053 ).
All example configuration values is coming from suggestions in upstream package, not much has been changed to enable discussion :
defvaras is ?:langmodules ? (If so, this PR will not make it, better have other contributions to their respective modules)defvarkeep track of all the ligatures available for each font, in a+fira/+iosevka...way ? (If so, this PR will not make the per font change, but I'll try to find a minimal set for thedefvar)defvaras well ? (looking at you,markdown-modeandorg-mode)Currently the decision is "no", and instead let users customize ligatures in text-modes with
set-ligatures!defvaras well ?Currently done, with a
nildefault valuePS: thanks @mickeynp for that package, it's been a good relief when we found out about it