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

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

bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face


From: martin rudalics
Subject: bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong
Date: Fri, 30 Dec 2022 10:51:37 +0100

> Oh, BTW, I have menu-bar, scroll-bar and tool-bar all disabled. The fringes 
should be on, though.

Then try setting the fringes to one 'frame-char-width' each or set them
to zero.

>> No idea.  You could try to step through normal_char_ascent_descent (best
>> when called from get_font_ascent_descent) for each of these fonts and
>> find out whether and how they differ.
>
> I'm reasonably certain it's the same font.
[...]
> If you think it will help, I can still try stepping through the functions you 
mentioned, but no earlier than tomorrow.

Please do that.  'describe-face' is one thing.  What the display engine
thinks of a font might be another.

>> So we at least have the improvement that the frame does not change size
>> for repeated, apparently idempotent, invocations.  Right?
>
> For some frame widths it does not. For others (for ranges of widths) -- it 
does.

I see.

> Resizing with the mouse works without any apparent glitches. The
> corner of the frame follows the mouse almost exactly, within the
> margin of a char's height/width (when resizing is not pixelwise).

It should do that in terms of whatever we ask for in the width and
height increments - after all, those mouse operations are under full
control of the WM.  Whatever size the WM gives us, we comply.  Take
these two assignments in xg_wm_set_size_hint:

  size_hints.width_inc /= scale;
  size_hints.height_inc /= scale;

Instead of the "/= scale"s put some assignments with arbitrary constants
there, say

  size_hints.width_inc = 51;
  size_hints.height_inc = 7;

You should see that mouse dragging will resize the frame by exactly what
you've put there.  BTW: Try with these two lines commented out and tell
me whether mouse dragging becomes _perceptibly_ worse.  Removing them
could be a substantial relieve in the future.

The problems start after Emacs takes the values it has been told by the
WM and tries to retrofit them into its own lines/columns framework.
When you next ask Emacs programmatically to resize the frame in terms of
the values it stored there, all those rounding and scaling errors that
piled up fire back.  Resizing frames is a continuous dialogue between
Emacs and the WM.  If one of them refuses to listen to the other, users
will suffer.

Thanks, martin





reply via email to

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