* bug#56357: Request for font size adaptation that fits window
@ 2022-07-02 12:17 carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-03 3:39 ` Richard Stallman
2022-07-04 11:01 ` Lars Ingebrigtsen
0 siblings, 2 replies; 10+ messages in thread
From: carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-02 12:17 UTC (permalink / raw)
To: 56357
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-02 12:17 bug#56357: Request for font size adaptation that fits window carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-03 3:39 ` Richard Stallman
2022-07-04 11:01 ` Lars Ingebrigtsen
1 sibling, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2022-07-03 3:39 UTC (permalink / raw)
To: carlmarcos; +Cc: 56357
[[[ 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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-02 12:17 bug#56357: Request for font size adaptation that fits window carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-03 3:39 ` Richard Stallman
@ 2022-07-04 11:01 ` Lars Ingebrigtsen
2022-07-04 11:42 ` Eli Zaretskii
2022-07-04 15:54 ` Drew Adams
1 sibling, 2 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-04 11:01 UTC (permalink / raw)
To: carlmarcos; +Cc: 56357
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-04 11:01 ` Lars Ingebrigtsen
@ 2022-07-04 11:42 ` Eli Zaretskii
2022-07-04 13:54 ` Lars Ingebrigtsen
2022-07-04 19:25 ` carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-04 15:54 ` Drew Adams
1 sibling, 2 replies; 10+ messages in thread
From: Eli Zaretskii @ 2022-07-04 11:42 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: carlmarcos, 56357
> 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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-04 11:42 ` Eli Zaretskii
@ 2022-07-04 13:54 ` Lars Ingebrigtsen
2022-07-04 14:05 ` Eli Zaretskii
2022-07-04 19:25 ` carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-04 13:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: carlmarcos, 56357
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-04 13:54 ` Lars Ingebrigtsen
@ 2022-07-04 14:05 ` Eli Zaretskii
0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2022-07-04 14:05 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: carlmarcos, 56357
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-04 11:42 ` Eli Zaretskii
2022-07-04 13:54 ` Lars Ingebrigtsen
@ 2022-07-04 19:25 ` carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-05 11:11 ` Lars Ingebrigtsen
1 sibling, 1 reply; 10+ messages in thread
From: carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-04 19:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, 56357
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-04 19:25 ` carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-05 11:11 ` Lars Ingebrigtsen
2022-07-05 15:33 ` Christopher Dimech
0 siblings, 1 reply; 10+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-05 11:11 UTC (permalink / raw)
To: carlmarcos; +Cc: Eli Zaretskii, 56357
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-05 11:11 ` Lars Ingebrigtsen
@ 2022-07-05 15:33 ` Christopher Dimech
0 siblings, 0 replies; 10+ messages in thread
From: Christopher Dimech @ 2022-07-05 15:33 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, carlmarcos, 56357
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#56357: Request for font size adaptation that fits window
2022-07-04 11:01 ` Lars Ingebrigtsen
2022-07-04 11:42 ` Eli Zaretskii
@ 2022-07-04 15:54 ` Drew Adams
1 sibling, 0 replies; 10+ messages in thread
From: Drew Adams @ 2022-07-04 15:54 UTC (permalink / raw)
To: Lars Ingebrigtsen, carlmarcos@tutanota.com; +Cc: 56357@debbugs.gnu.org
> > 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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-07-05 15:33 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-02 12:17 bug#56357: Request for font size adaptation that fits window carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-03 3:39 ` Richard Stallman
2022-07-04 11:01 ` Lars Ingebrigtsen
2022-07-04 11:42 ` Eli Zaretskii
2022-07-04 13:54 ` Lars Ingebrigtsen
2022-07-04 14:05 ` Eli Zaretskii
2022-07-04 19:25 ` carlmarcos--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-05 11:11 ` Lars Ingebrigtsen
2022-07-05 15:33 ` Christopher Dimech
2022-07-04 15:54 ` Drew Adams
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.