bug#56357: Request for font size adaptation that fits window

bug#56357: Request for font size adaptation that fits window

[carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]


I am basically an old fart who cannot read small fonts anymore.  Could you think of a way to automatically maximise the font size.  

Suppose a user uses a 13 pt font size.  Let there be some space between the longest line in the buffer and the edge of the window.  It would be super if the font size could be automatically increased, such that the difference between the longest line and the window size in minimised.

Many thanks for reading this.

[-- Attachment #2: Type: text/html, Size: 724 bytes --]

bug#56357: Request for font size adaptation that fits window

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I am basically an old fart who cannot read small fonts anymore. 
  > Could you think of a way to automatically maximise the font size. 

You're not the only person who has this problem.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#56357: Request for font size adaptation that fits window

[Lars Ingebrigtsen]

carlmarcos@tutanota.com writes:

> Suppose a user uses a 13 pt font size.  Let there be some space
> between the longest line in the buffer and the edge of the window.  It
> would be super if the font size could be automatically increased, such
> that the difference between the longest line and the window size in
> minimised.

I think that sounds like a useful feature, and I'm kinda surprised that
it doesn't exist yet.  Or does it?  Anybody know?

To implement this, I guess the obvious thing would be to have a global
minor mode that'd listen to frame size changes, and then adjust the font
size up/down to reach the desired number of characters in a frame?  So
we'd have a user option font-size-adjust-target (defaulting to 80)
and a font-size-adjust-mode?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56357: Request for font size adaptation that fits window

[Eli Zaretskii]

> Cc: 56357@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 04 Jul 2022 13:01:20 +0200
> 
> carlmarcos@tutanota.com writes:
> 
> > Suppose a user uses a 13 pt font size.  Let there be some space
> > between the longest line in the buffer and the edge of the window.  It
> > would be super if the font size could be automatically increased, such
> > that the difference between the longest line and the window size in
> > minimised.
> 
> I think that sounds like a useful feature, and I'm kinda surprised that
> it doesn't exist yet.  Or does it?  Anybody know?
> 
> To implement this, I guess the obvious thing would be to have a global
> minor mode that'd listen to frame size changes, and then adjust the font
> size up/down to reach the desired number of characters in a frame?  So
> we'd have a user option font-size-adjust-target (defaulting to 80)
> and a font-size-adjust-mode?

That's not what the feature request asked for, AFAIU: it wanted
dynamic resizing, and it wanted the size to depend on the "longest
line" (not clear if "longest in the window" or "longest in the
buffer").

With your proposal, how would you determine the target value?  If it's
just an arbitrary value (80 sounds like an arbitrary one to me), then
the recently-added global-text-scale-adjust-resizes-frames variable
does the same, just from the other end: the user enlarges the font and
the frame follows suit.  And since our default frame width is already
set for 80 characters, it sounds like we already have the feature you
envisioned, no?

bug#56357: Request for font size adaptation that fits window

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> With your proposal, how would you determine the target value?  If it's
> just an arbitrary value (80 sounds like an arbitrary one to me), then
> the recently-added global-text-scale-adjust-resizes-frames variable
> does the same, just from the other end: the user enlarges the font and
> the frame follows suit.  And since our default frame width is already
> set for 80 characters, it sounds like we already have the feature you
> envisioned, no?

I think the user wants to be able to drag a frame to be bigger and get
the font to be resized to have the same number of columns, so it's not
the same feature at all.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56357: Request for font size adaptation that fits window

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: carlmarcos@tutanota.com,  56357@debbugs.gnu.org
> Date: Mon, 04 Jul 2022 15:54:44 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > With your proposal, how would you determine the target value?  If it's
> > just an arbitrary value (80 sounds like an arbitrary one to me), then
> > the recently-added global-text-scale-adjust-resizes-frames variable
> > does the same, just from the other end: the user enlarges the font and
> > the frame follows suit.  And since our default frame width is already
> > set for 80 characters, it sounds like we already have the feature you
> > envisioned, no?
> 
> I think the user wants to be able to drag a frame to be bigger and get
> the font to be resized to have the same number of columns, so it's not
> the same feature at all.

I'm asking why it matters how you "drag the frame": whether by
actually dragging its edge or by C-M-wheel-up.  The results is the
same, no?

And that actually gives an idea: make dragging the frame call the same
function that C-M-wheel-up does.

bug#56357: Request for font size adaptation that fits window

[Drew Adams]

> > Suppose a user uses a 13 pt font size.  Let there be some space
> > between the longest line in the buffer and the edge of the window.
> > It would be super if the font size could be automatically increased,
> > such that the difference between the longest line and the window 
> > size in minimised.
> 
> I think that sounds like a useful feature, and I'm kinda surprised that
> it doesn't exist yet.  Or does it?  Anybody know?
> 
> To implement this, I guess the obvious thing would be to have a global
> minor mode that'd listen to frame size changes, and then adjust the
> font size up/down to reach the desired number of characters in a frame?
> So we'd have a user option font-size-adjust-target (defaulting to 80)
> and a font-size-adjust-mode?

Not sure, but I have a feeling this feature might be
related to what you're thinking about / looking for.
It doesn't sound like it's exactly what this report
has requested.  But it sounds like it's related and
it might even address the underlying need/problem.

My library `face-remap+.el' introduces option
`text-scale-resize-window', which automatically resizes
the selected window (horizontally, vertically, or both)
when text is resized.  This means that when you resize
text the way the window fits the text remains relatively
constant.  Shrinking the text in one window shrinks that
window, giving more space to adjacent windows.

IOW, it keeps whatever relation currently exists between
the apparent text size and the window size.  That also
means that it lets you take advantage of the space freed
up by resizing (text-scaling) to a smaller font.

I offered this feature to Emacs dev _long_ ago (as soon
as text-scaling was added to Emacs).  It was summarily
rejected, with a no-one-would-ever-want-to-do-that
dismissal.  But personally, I wouldn't use text scaling
without such a feature.

I see, and saw, no reason not to give users the choice,
as opposed to hard-coding the behavior so as to always
waste screen real estate with added blank space when
text is shrunk.

The code is trivial - a tweak to `text-scale-increase'
to respect the new user option.  The code is here:

https://www.emacswiki.org/emacs/download/face-remap%2b.el

bug#56357: Request for font size adaptation that fits window

[carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]



-- 
 Sent with Tutanota, enjoy secure & ad-free emails. 



Jul 4, 2022, 11:42 by eliz@gnu.org:

>> Cc: 56357@debbugs.gnu.org
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Mon, 04 Jul 2022 13:01:20 +0200
>>
>> carlmarcos@tutanota.com writes:
>>
>> > Suppose a user uses a 13 pt font size.  Let there be some space
>> > between the longest line in the buffer and the edge of the window.  It
>> > would be super if the font size could be automatically increased, such
>> > that the difference between the longest line and the window size in
>> > minimised.
>>
>> I think that sounds like a useful feature, and I'm kinda surprised that
>> it doesn't exist yet.  Or does it?  Anybody know?
>>
>> To implement this, I guess the obvious thing would be to have a global
>> minor mode that'd listen to frame size changes, and then adjust the font
>> size up/down to reach the desired number of characters in a frame?  So
>> we'd have a user option font-size-adjust-target (defaulting to 80)
>> and a font-size-adjust-mode?
>>
>
> That's not what the feature request asked for, AFAIU: it wanted
> dynamic resizing, and it wanted the size to depend on the "longest
> line" (not clear if "longest in the window" or "longest in the
> buffer").
>
Correct, a dynamic resizing based on "longest in the buffer".  I would say that 
one would not want frequent resizing either.  Though I am not best to state how the
dynamic resizing could get activated.  Then again there should be a limit of the size
of the font for instances where the resizing would get too big for files with short lines.


> With your proposal, how would you determine the target value?  If it's
> just an arbitrary value (80 sounds like an arbitrary one to me), then
> the recently-added global-text-scale-adjust-resizes-frames variable
> does the same, just from the other end: the user enlarges the font and
> the frame follows suit.  And since our default frame width is already
> set for 80 characters, it sounds like we already have the feature you
> envisioned, no?
>


[-- Attachment #2: Type: text/html, Size: 3111 bytes --]

bug#56357: Request for font size adaptation that fits window

[Lars Ingebrigtsen]

carlmarcos@tutanota.com writes:

> Correct, a dynamic resizing based on "longest in the buffer".  I would
> say that one would not want frequent resizing either.  Though I am not
> best to state how the dynamic resizing could get activated.  Then
> again there should be a limit of the size of the font for instances
> where the resizing would get too big for files with short lines.

Oh, OK.  I'm not sure I think that's something many people would find
useful -- people usually choose a fill-column/frame width/font size
that's suitable for each other.  Making lines in a buffer shorter, for
instance, to be able to jack up the font size isn't something I think
would be popular.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56357: Request for font size adaptation that fits window

[Christopher Dimech]

> Sent: Tuesday, July 05, 2022 at 11:11 PM
> From: "Lars Ingebrigtsen" <larsi@gnus.org>
> To: carlmarcos@tutanota.com
> Cc: "Eli Zaretskii" <eliz@gnu.org>, 56357@debbugs.gnu.org
> Subject: bug#56357: Request for font size adaptation that fits window
>
> carlmarcos@tutanota.com writes:
>
> > Correct, a dynamic resizing based on "longest in the buffer".  I would
> > say that one would not want frequent resizing either.  Though I am not
> > best to state how the dynamic resizing could get activated.  Then
> > again there should be a limit of the size of the font for instances
> > where the resizing would get too big for files with short lines.
>
> Oh, OK.  I'm not sure I think that's something many people would find
> useful -- people usually choose a fill-column/frame width/font size
> that's suitable for each other.  Making lines in a buffer shorter, for
> instance, to be able to jack up the font size isn't something I think
> would be popular.

It all depends how often the longest line in modified.  I can see the problem
with dynamic resizing.

Perhaps it can be an extension of `C-x C-+' and `C-x C--' so users would
not have press them multiple times for code to fit window.  And be able to
set some other variables so that the result the user sees is optimal as much
as possible.