From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: carlmarcos--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#56357: Request for font size adaptation that fits window Date: Mon, 4 Jul 2022 21:25:24 +0200 (CEST) Message-ID: References: <871qv187lr.fsf@gnus.org> <83y1x985p4.fsf@gnu.org> Reply-To: carlmarcos@tutanota.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1154359_1052702778.1656962724145" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7606"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 56357@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 04 21:26:10 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o8Rhx-0001kn-PT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Jul 2022 21:26:10 +0200 Original-Received: from localhost ([::1]:35106 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o8Rhw-0002xd-6w for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Jul 2022 15:26:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42020) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o8Rhq-0002xN-Bu for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2022 15:26:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54778) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o8Rhq-0004qp-1j for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2022 15:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o8Rhp-0007KS-V7 for bug-gnu-emacs@gnu.org; Mon, 04 Jul 2022 15:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: carlmarcos@tutanota.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Jul 2022 19:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56357 X-GNU-PR-Package: emacs Original-Received: via spool by 56357-submit@debbugs.gnu.org id=B56357.165696273328093 (code B ref 56357); Mon, 04 Jul 2022 19:26:01 +0000 Original-Received: (at 56357) by debbugs.gnu.org; 4 Jul 2022 19:25:33 +0000 Original-Received: from localhost ([127.0.0.1]:48669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o8RhM-0007J3-NZ for submit@debbugs.gnu.org; Mon, 04 Jul 2022 15:25:33 -0400 Original-Received: from w1.tutanota.de ([81.3.6.162]:44910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o8RhJ-0007Ie-Mj for 56357@debbugs.gnu.org; Mon, 04 Jul 2022 15:25:31 -0400 Original-Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 26C72FBF81D; Mon, 4 Jul 2022 19:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1656962724; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=1m4yyGKtykh+xFvuX8hK77C/Rakrkj9Efj0JC/6LGEQ=; b=ZO6NUpAxHafiLu+BrUEcYs+iaOGCafF1VQ2mCzGselQpREFYRhbfsLCHzJYiPI29 6hrIzsVEYjzMM3ln7aB6Vmn84ZbTBL1JYOEvH6uaDaMGBHVf4JNIkTRlEe0MxZK2Xef TXfuG1+L6WN1S4SrJkoKLzbdDQcbJ+FPCo9B2WLfOcE7rHMCzx/AXG1qoVUR3C21SA1 r8tc37ofiaxcfdQ3TJcf0R5jiNAEzTVejiU5vzwMB9k+bgMAmYvqJcPIDSlNUsEJZXM evkD9NemdCKWg1zpRe4QEePxgz7mPAETWzaIDlqKx5hIIj1aBu8f5gawbRm6t65pl3g 8wVRJXThfw== In-Reply-To: <83y1x985p4.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236069 Archived-At: ------=_Part_1154359_1052702778.1656962724145 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --=20 Sent with Tutanota, enjoy secure & ad-free emails.=20 Jul 4, 2022, 11:42 by eliz@gnu.org: >> Cc: 56357@debbugs.gnu.org >> From: Lars Ingebrigtsen >> 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".=C2=A0 I would= say that=20 one would not want frequent resizing either.=C2=A0 Though I am not best to = state how the dynamic resizing could get activated.=C2=A0 Then again there should be a li= mit of the size of the font for instances where the resizing would get too big for files wi= th 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? > ------=_Part_1154359_1052702778.1656962724145 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


--
Sent with Tutanota, e= njoy secure & ad-free emails.


<= div>
Jul 4, 2022, 11:42 by eliz@gnu.org:
Cc: 56357@debbugs.gnu.org
From: Lars Ingebrigtsen <larsi@gnus.org>
D= ate: Mon, 04 Jul 2022 13:01:20 +0200

carlmarco= s@tutanota.com writes:

> Suppose a user use= s a 13 pt font size. Let there be some space
> between th= e 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 wi= ndow size in
> minimised.

I t= hink 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 t= hen adjust the font
size up/down to reach the desired number = of characters in a frame? So
we'd have a user option font-si= ze-adjust-target (defaulting to 80)
and a font-size-adjust-mo= de?

That's not what the feature r= equest asked for, AFAIU: it wanted
dynamic resizing, and it w= anted 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 "longe= st in the buffer".  I would say that
one w= ould not want frequent resizing either.  Though I am not best to state= how the
dynamic resizing could get activated.&n= bsp; Then again there should be a limit of the size
of the font for instances where the resizing would get too big for file= s with short lines.

With your proposal, how would you determine t= he 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?

= ------=_Part_1154359_1052702778.1656962724145--