Hello again,
I attempted to update my laptop (a Macbook Pro) with my latest config
changes, and hit this issue while trying to load fontaine:
Error (use-package): fontaine/:config: Invalid function: (properties (append (alist-get preset fontaine-presets) (alist-get t fontaine-presets)))
Running the `fontaine-set-preset` call by hand with C-x C-e after
toggling on the debugger gets this:
Debugger entered--Lisp error: (invalid-function (properties (append (alist-get preset fontaine-presets) (alist-get t fontaine-presets))))
(properties (append (alist-get preset fontaine-presets) (alist-get t fontaine-presets)))()
fontaine--apply-default-preset(normal nil)
fontaine-set-preset(normal)
eval((fontaine-set-preset 'normal) t)
My config hasn't changed a great deal since I last posted:
(use-package fontaine
:if window-system
:init
(setq fontaine-presets
'((t
:default-family "Iosevka Term"
:variable-pitch-family "Iosevka Etoile")
(normal :default-height 120)
(small :default-height 100)
(big :default-height 160)
(presentation :default-height 200)))
:config
(fontaine-set-preset 'normal)
(bind-key "C-c f" #'fontaine-set-preset))
The most likely to be relevant differences are that this is emacs 27.2
on MacOS, rather than 28.1 on NixOS (I get my emacs from nixpkgs and the
macport build hasn't been updated to 28.1 yet.)
It's a little baffling to me, as `properties` is indeed not a function;
it should be a let binding here.
There doesn't seem to be a significant difference between `if-let`
between 27.2 and 28.1. The only one I can see is in the debug
declaration, where the order is swapped, and in 28.2 this bug is
referenced regarding that swap:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48489
I can't see that having much impact on the functionality of `if-let`
though.
-- Ted Reed
> From: Ted Reed <treed@zenithia.net>> Date: Tue, 10 May 2022 02:08:01 -0700>> Hello again,
Hello Ted,
> I attempted to update my laptop (a Macbook Pro) with my latest config> changes, and hit this issue while trying to load fontaine:>> Error (use-package): fontaine/:config: Invalid function: (properties (append (alist-get preset fontaine-presets) (alist-get t fontaine-presets)))>> Running the `fontaine-set-preset` call by hand with C-x C-e after> toggling on the debugger gets this:>> Debugger entered--Lisp error: (invalid-function (properties (append (alist-get preset fontaine-presets) (alist-get t fontaine-presets))))> (properties (append (alist-get preset fontaine-presets) (alist-get t fontaine-presets)))()> fontaine--apply-default-preset(normal nil)> fontaine-set-preset(normal)> eval((fontaine-set-preset 'normal) t)
I tried it with Emacs 27 and 29: it worked in both cases. What I did:
* Launch Emacs using 'emacs -Q' on the command-line.
* In the scratch buffer, added and evaluated:
(require 'fontaine "/path/to/fontaine.el")
* Tried 'M-x fontaine-set-preset RET large', or evaluated
(fontaine-set-preset 'large)
* This assumes the "Iosevka" font is installed. It produced the desired
result.
Can you reproduce those steps? If yes, then I suspect your problem is
caused by a mismatch between old byte compiled files and newer code.
If so, delete the fontaine package and install it again.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> I tried it with Emacs 27 and 29: it worked in both cases. What I did:>> * Launch Emacs using 'emacs -Q' on the command-line.>> * In the scratch buffer, added and evaluated:> (require 'fontaine "/path/to/fontaine.el")>> * Tried 'M-x fontaine-set-preset RET large', or evaluated> (fontaine-set-preset 'large)>> * This assumes the "Iosevka" font is installed. It produced the desired> result.>> Can you reproduce those steps? If yes, then I suspect your problem is> caused by a mismatch between old byte compiled files and newer code.> If so, delete the fontaine package and install it again.
Doing as you describe does indeed work (although font-scaling is
apparently different on Mac; I need to use `big` to get roughly what
`normal` is on my NixOS VM; might end up writing a small util function
to multiply the height on Mac).
I did then delete the .elc files and then validated that the new ones
have an mtime appropriate to the new compilation, but the issue
persists.
Given that, I assume it must be something in my config that causes
`if-let` to fail in this way.
I moved the `use-package` invocation as early as possible, directly
after initializing straight.el, and the issue still persists. So I tried
replacing my config with:
(when window-system
(setq fontaine-presets
'((t
:default-family "Iosevka Term"
:variable-pitch-family "Iosevka Etoile")
(normal :default-height 120)
(small :default-height 100)
(big :default-height 160)
(presentation :default-height 200)))
(require 'fontaine "/Users/treed/.new-emacs-local.d/straight/build/fontaine/fontaine.el")
(fontaine-set-preset 'normal)
(bind-key "C-c f" #'fontaine-set-preset))
And *this* works fine. So it must be something with either use-package
or straight.el which I've never seen before.
In this config, it is still using the same directory and therefore
likely the same .elc files as with use-package, so my guess is that it's
more likely use-package.
Thanks for looking at this; I'll continue to dig and if I figure it out,
I'll update the list just in case anyone else runs into this.
-- Ted Reed
> From: Ted Reed <treed@zenithia.net>> Date: Tue, 10 May 2022 13:43:08 -0700>> In this config, it is still using the same directory and therefore> likely the same .elc files as with use-package, so my guess is that it's> more likely use-package.
I think it still is due to fontaine. Specifically the fact that we make
an implicit assumption that if-let and friends are known/available at
compile time.
I pushed a change right now (commit fbd3a14) which adds the following:
(eval-when-compile (require 'subr-x))
Can you test it?
> Doing as you describe does indeed work (although font-scaling is> apparently different on Mac; I need to use `big` to get roughly what> `normal` is on my NixOS VM; might end up writing a small util function> to multiply the height on Mac).
I'm afraid I can't be of help here. Though I would like to know what
the underlying issue is---we could document it in the manual if it is a
common occurrence.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
> I think it still is due to fontaine. Specifically the fact that we make> an implicit assumption that if-let and friends are known/available at> compile time.>> I pushed a change right now (commit fbd3a14) which adds the following:>> (eval-when-compile (require 'subr-x))>> Can you test it?
Yes, this fixed it! Thank you!
In my digging I found that it was indeed related to straight.el;
`straight-use-package` would still cause the issue outside of
`use-package` itself. I hadn't gotten much further than that yet.
It's strange to me that this behaved differently across
platforms/versions but with otherwise identical configurations, but I'm
glad to have it fixed.
> I'm afraid I can't be of help here. Though I would like to know what> the underlying issue is---we could document it in the manual if it is a> common occurrence.
My suspicion is that it has to do with scaling, and that it's actually
my NixOS environment that's at fault. I run it in a VM on Windows, and
use X410 as my X server, purely to get a real emacs on Windows. (And
have since also started using it to manage my other VMs and the like.)
When I converted from :size to :default-height, I found that a simple
multiplying by ten didn't get me the same size. Which is to say that 16
size and 160 height were not the same. I had to set :default-height to
120 to approximate the same size on the NixOS side.
On Mac, however 160 appears to be roughly the same as size 16.
The particularly weird thing though is that setting :size 16 worked on
both platforms, which suggests that there's some difference possible
between the two properties and how they're interpreted.
I currently have this to compensate for the difference:
(defun treed/scale-height (value)
(if (eq window-system 'mac)
(round (* value 1.33))
value))
Which then is used to wrap the heights passed to fontaine.
I'm going to do a little research and see if I can change X410's
scaling, or determine how and when :default-height and :size can behave
differently.
-- Ted Reed
> From: Ted Reed <treed@zenithia.net>> Date: Wed, 11 May 2022 00:12:30 -0700>>> Protesilaos Stavrou <info@protesilaos.com> writes:>>> I think it still is due to fontaine. Specifically the fact that we make>> an implicit assumption that if-let and friends are known/available at>> compile time.>>>> I pushed a change right now (commit fbd3a14) which adds the following:>>>> (eval-when-compile (require 'subr-x))>>>> Can you test it?>> Yes, this fixed it! Thank you!
You are welcome!
> In my digging I found that it was indeed related to straight.el;> `straight-use-package` would still cause the issue outside of> `use-package` itself. I hadn't gotten much further than that yet.>> It's strange to me that this behaved differently across> platforms/versions but with otherwise identical configurations, but I'm> glad to have it fixed.
I do not know the internals of those tools. My working hypothesis is
that one would get from "somewhere" the reification (or related) of
if-let while the other would not.
>> I'm afraid I can't be of help here. Though I would like to know what>> the underlying issue is---we could document it in the manual if it is a>> common occurrence.>> My suspicion is that it has to do with scaling, and that it's actually> my NixOS environment that's at fault. I run it in a VM on Windows, and> use X410 as my X server, purely to get a real emacs on Windows. (And> have since also started using it to manage my other VMs and the like.)
Oh, I see.
> When I converted from :size to :default-height, I found that a simple> multiplying by ten didn't get me the same size. Which is to say that 16> size and 160 height were not the same. I had to set :default-height to> 120 to approximate the same size on the NixOS side.>> On Mac, however 160 appears to be roughly the same as size 16.
Interesting! Depending on your findings, this might be worth reporting
as an Emacs bug.
> The particularly weird thing though is that setting :size 16 worked on> both platforms, which suggests that there's some difference possible> between the two properties and how they're interpreted.
Indeed.
> I currently have this to compensate for the difference:>> (defun treed/scale-height (value)> (if (eq window-system 'mac)> (round (* value 1.33))> value))>> Which then is used to wrap the heights passed to fontaine.
We could support the :size instead of the :height.
Perhaps we can say express something like "if :size use that, else use
the :height"? And also warn the user "when in doubt, use the height" (or
something to that effect)?
My concern is this might add more complexity/caveats to the
configuration. I am willing to do it, though only if it is necessary
and/or genuinely useful.
What do you think?
> I'm going to do a little research and see if I can change X410's> scaling, or determine how and when :default-height and :size can behave> differently.
Yes, this would be useful knowledge.
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> When I converted from :size to :default-height, I found that a simple>> multiplying by ten didn't get me the same size. Which is to say that 16>> size and 160 height were not the same. I had to set :default-height to>> 120 to approximate the same size on the NixOS side.>>>> On Mac, however 160 appears to be roughly the same as size 16.>> Interesting! Depending on your findings, this might be worth reporting> as an Emacs bug.
After a little digging, I have found that I was misunderstanding :size;
it turns out that integers are accepted as raw pixel values, and floats
are points, such that 16.0 and 16 are (or at least can be, depending on
DPI) different.
:size 16.0 on my VM is indeed equal to :height 160, but :size 16 is
:height 120. On my laptop, these values are 160 and 161 respectively, so
nearly equal, explaining why the direct conversion from 16 to 160
worked.
Having used raw pixel values also explains why the sizes were previously
consistent across machines.
As far as I can tell, the scaling issue is because the VM or my X server
is confused about the physical size of my monitor, in ways that my
laptop environment is not. I've attempted to figure out how to correct
it, by using GDK env vars, and by setting display-mm-dimensions-alist,
but neither of these have worked.
I found an auctex bug report where someone mentioned that functions
related to display-mm-dimensions-alist are ignored in builds that
support gdk, and that xorg by default lies about the DPI and always says
96, which is what I'm seeing. Unsure if X410 relies on xorg or simply
copies its behavior. I can say that the Windows host doesn't seem to be
able to detect the physical monitor size, even after I installed the
manufacturer's driver. X410 may simply not know and fall back to the old
standard of 96.
> We could support the :size instead of the :height.>> Perhaps we can say express something like "if :size use that, else use> the :height"? And also warn the user "when in doubt, use the height" (or> something to that effect)?>> My concern is this might add more complexity/caveats to the> configuration. I am willing to do it, though only if it is necessary> and/or genuinely useful.>> What do you think?
I agree that supporting multiple paths is to be avoided if possible for
simplicity's sake.
I have a work-around currently, so perhaps it would be best to wait and
see if anyone else runs into this issue. My environment is somewhat
unique to me and this may simply be an artifact of how strange it is.
In order to make my work-around a little more portable to different
machines, I may instead of detecting the platform have it use an env-var
for scaling, which I can set on the one VM and leave everything else to
use raw values.
-- Ted Reed
> From: Ted Reed <treed@zenithia.net>> Date: Wed, 11 May 2022 14:29:43 -0700>>> Protesilaos Stavrou <info@protesilaos.com> writes:>>>> When I converted from :size to :default-height, I found that a simple>>> multiplying by ten didn't get me the same size. Which is to say that 16>>> size and 160 height were not the same. I had to set :default-height to>>> 120 to approximate the same size on the NixOS side.>>>>>> On Mac, however 160 appears to be roughly the same as size 16.>>>> Interesting! Depending on your findings, this might be worth reporting>> as an Emacs bug.>> After a little digging, I have found that I was misunderstanding :size;> it turns out that integers are accepted as raw pixel values, and floats> are points, such that 16.0 and 16 are (or at least can be, depending on> DPI) different.
I was aware of the :font face attribute, but not the :size. It is not
mentioned in the manual. Evaluate:
(info "(elisp) Face Attributes")
> :size 16.0 on my VM is indeed equal to :height 160, but :size 16 is> :height 120. On my laptop, these values are 160 and 161 respectively, so> nearly equal, explaining why the direct conversion from 16 to 160> worked.>> Having used raw pixel values also explains why the sizes were previously> consistent across machines.
Good to know.
>> [... 15 lines elided]>>> We could support the :size instead of the :height.>>>> Perhaps we can say express something like "if :size use that, else use>> the :height"? And also warn the user "when in doubt, use the height" (or>> something to that effect)?>>>> My concern is this might add more complexity/caveats to the>> configuration. I am willing to do it, though only if it is necessary>> and/or genuinely useful.>>>> What do you think?>> I agree that supporting multiple paths is to be avoided if possible for> simplicity's sake.>> I have a work-around currently, so perhaps it would be best to wait and> see if anyone else runs into this issue. My environment is somewhat> unique to me and this may simply be an artifact of how strange it is.>> In order to make my work-around a little more portable to different> machines, I may instead of detecting the platform have it use an env-var> for scaling, which I can set on the one VM and leave everything else to> use raw values.
Very well! Let's stick to what we have for now and wait to hear from
others. Thanks again for the feedback!
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
> I was aware of the :font face attribute, but not the :size. It is not> mentioned in the manual. Evaluate:>> (info "(elisp) Face Attributes")
Oh, this is in the context of `font-spec`. Here's what I had before
fontaine:
(setq treed-normal-mono-font (font-spec :family "Iosevka Term" :size 16)
treed-big-mono-font (font-spec :family "Iosevka Term" :size 24)
treed-normal-variable-font (font-spec :family "Iosevka Etoile" :size 16)
treed-big-variable-font (font-spec :family "Iosevka Etoile" :size 24)
treed-current-font 'normal)
(set-face-font 'default treed-normal-mono-font)
(set-face-font 'fixed-pitch treed-normal-mono-font)
(set-face-font 'variable-pitch treed-normal-variable-font)
(defun treed-toggle-big-font ()
(interactive)
(if (eq treed-current-font 'normal)
(progn
(set-face-font 'default treed-big-mono-font)
(set-face-font 'fixed-pitch treed-big-mono-font)
(set-face-font 'variable-pitch treed-big-variable-font)
(setq treed-current-font 'big))
(progn
(set-face-font 'default treed-normal-mono-font)
(set-face-font 'fixed-pitch treed-normal-mono-font)
(set-face-font 'variable-pitch treed-normal-variable-font)
(setq treed-current-font 'normal))))
Probably could have been cleaned up some; it was created over a few
iterations. I think if I'd ever gotten around to having a third option I
probably would have ended up with an approach similar to fontaine,
especially since I've learned about `completing-read` since then.
I originally took the idea from a feature Doom Emacs has. When I went
back to my own configuration, I had a period of copying or
reimplementing the features I missed from it.
(info "(elisp) Low-Level Font") has the details on `font-spec`.
Honestly, I had no idea :height existed before fontaine. When I learned
how to set fonts, the above is what I found so it's what I've been using.
> Very well! Let's stick to what we have for now and wait to hear from> others. Thanks again for the feedback!
Of course! I'll try to remember to update this thread if I ever figure
out how to fix the scaling for real, but I'll probably just live with
having a font scaling factor for now.
-- Ted Reed