GNU bug report logs -
#48307
Feature request: provide default keybindings to change the font size in all windows
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48307 in the body.
You can then email your comments to 48307 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 07:10:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Clément Pit-Claudel <cpitclaudel <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 09 May 2021 07:10:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi all,
Emacs has keybindings to change the font size in the current buffer (C-x C-=, etc which use text-scale-adjust). We don't have keybindings for commands to change the font size globally, and in fact we don't have commands for that purpose at all, AFAICT.
My students keep running into this issue, and it seems pretty common online, too:
- https://stackoverflow.com/questions/18783227/emacs-zoom-in-out-globally
- https://stackoverflow.com/questions/24705984/increase-decrease-font-size-in-an-emacs-frame-not-just-buffer
- https://www.reddit.com/r/emacs/comments/dip6e6/zoom_in_zoom_out/
… and there are many libraries that reimplement solutions to this issue:
- https://www.emacswiki.org/emacs/download/zoom-frm.el
- https://practicalli.github.io/spacemacs/install-spacemacs/change-font.html
- https://github.com/purcell/default-text-scale
- https://www.emacswiki.org/emacs/GlobalTextScaleMode
- https://www.emacswiki.org/emacs/SetFonts#ZoomFrame
I'm sure many more people have custom code for this (I do). Not all the implementations are good, and it would be very nice if such a feature were available out of the box.
Currently mouse-wheel-text-scale is bound to C-<mouse-5> and C-<mouse-4>; could we have an equivalent command for all buffers, maybe on C-S-<mouse-5> and C-S-<mouse-4>?
Clément.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 08:24:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Sun, 9 May 2021 03:09:45 -0400
>
> Emacs has keybindings to change the font size in the current buffer (C-x C-=, etc which use text-scale-adjust). We don't have keybindings for commands to change the font size globally, and in fact we don't have commands for that purpose at all, AFAICT.
>
> My students keep running into this issue, and it seems pretty common online, too:
It is not clear what should the requested feature do, and the links
you provided each talk about different aspects of the problem without
actually completely defining the requested functionality.
So: what should be the effect of this "global" change of the "font
size"? Some thought-provoking questions:
. should this affect only the faces whose fonts don't define their
own size, or should it affect _all_ fonts?
. should this really affect _all_ the buffers? e.g., what about the
minibuffer and the echo-area buffers?
. should this affect all the frames or just the currently selected
frame? what about future frames?
. should this affect the mode line?
. should this affect tooltips?
. should this affect the fringes and their bitmaps?
. should this affect the menu bar, the drop-down menus, and the GUI
dialogs?
We need a clear understanding of the feature before we implement it,
IMO.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 08:44:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Currently mouse-wheel-text-scale is bound to C-<mouse-5> and
> C-<mouse-4>; could we have an equivalent command for all buffers,
> maybe on C-S-<mouse-5> and C-S-<mouse-4>?
I suppose you mean a command for all _frames_. Any buffer-local text
scaling would still override that.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 15:20:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/9/21 4:43 AM, martin rudalics wrote:
>> Currently mouse-wheel-text-scale is bound to C-<mouse-5> and
>> C-<mouse-4>; could we have an equivalent command for all buffers,
>> maybe on C-S-<mouse-5> and C-S-<mouse-4>?
>
> I suppose you mean a command for all _frames_. Any buffer-local text
> scaling would still override that.
Sure: I meant something that scales the font in every window (and possibly in every frame, too, indeed)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 15:33:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/9/21 4:23 AM, Eli Zaretskii wrote:
> So: what should be the effect of this "global" change of the "font
> size"? Some thought-provoking questions:
Thanks. Some wild guesses:
> . should this affect only the faces whose fonts don't define their
> own size, or should it affect _all_ fonts?
Probably all of them except the ones that specify an absolute height?
> . should this really affect _all_ the buffers? e.g., what about the
> minibuffer and the echo-area buffers?
Yes, certainly.
> . should this affect all the frames or just the currently selected
> frame? what about future frames?
I'm guessing all frames.
> . should this affect the mode line?
Absolutely.
> . should this affect tooltips?
Yes, to the extent that we have control over that.
> . should this affect the fringes and their bitmaps?
That would be nice.
> . should this affect the menu bar, the drop-down menus, and the GUI
> dialogs?
That's extra credit; I guess it could be nice?
> We need a clear understanding of the feature before we implement it,
> IMO.
Indeed, although starting with an implementation and refining it over time could be good, too (to some extent I think the specifics matter less than having something available). For example, just including any one of the short implementations into Emacs by default would work to solve the concrete issue that I'm talking about (with the pandemic we do screen-sharing all the time, and I hear "how do I resize the font in Emacs again?" more than once a week these days ^^).
A good approximation of what I would like that command to do is what menu-set-font does if you ignore the part about changing the face and only change the size part. Something similar to doing text-scale-adjust in every buffer would also work, too (I've noticed that changing the :height attribute of the default face is slow, while text-scale-adjust is fast).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 15:59:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> and there are many libraries that reimplement
> solutions to this issue:
Except for zoom-frm.el, which dates from 2005, those
all seem to date from at least 2013.
It doesn't really look like zoom-frm.el RE-implements
this. It also looks to be the only one that lets you
use the same commands to text-scale (zoom individual
buffers - in all of their windows) or zoom frames
(zoom all windows in a frame).
As for zooming all frames together, zoom-frm.el has
commands `zoom-all-frames-(in|out)' for that.
But when it comes to zooming all frames in some way,
the questions Eli raised seem relevant, in general.
IMO, it's particularly useful to be able to optionally
(1) zoom a buffer everywhere, so all its windows show
its text at the same size _OR_ (2) show a buffer's text
at different sizes in different windows. Text-scaling
does (only) #1. Frame zooming allows #2.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 16:06:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> >> Currently mouse-wheel-text-scale is bound to C-<mouse-5> and
> >> C-<mouse-4>; could we have an equivalent command for all buffers,
> >> maybe on C-S-<mouse-5> and C-S-<mouse-4>?
> >
> > I suppose you mean a command for all _frames_. Any buffer-local text
> > scaling would still override that.
>
> Sure: I meant something that scales the font in every window (and possibly in
> every frame, too, indeed)
That's what frame-zooming does (in zoom-frm.el).
It just zooms in or out on a frame (or all frames).
(To be clear, zoom-frm.el doesn't zoom images etc.
It just affects font size.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 16:09:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Cc: 48307 <at> debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Sun, 9 May 2021 11:31:57 -0400
>
> Indeed, although starting with an implementation and refining it over time could be good, too (to some extent I think the specifics matter less than having something available). For example, just including any one of the short implementations into Emacs by default would work to solve the concrete issue that I'm talking about (with the pandemic we do screen-sharing all the time, and I hear "how do I resize the font in Emacs again?" more than once a week these days ^^).
Why not point them to Options->Set Default Font menu item? That does
almost everything you asked for in your answer to my questions. In
fact, given that we already have that menu item, it could be argued we
already have the feature implemented.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 16:31:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> > . should this affect only the faces whose fonts don't define their
> > own size, or should it affect _all_ fonts?
>
> Probably all of them except the ones that specify
> an absolute height?
Frame zooming does that.
> > . should this really affect _all_ the buffers? e.g.,
> > what about the minibuffer and the echo-area buffers?
>
> Yes, certainly.
Frame zooming does that.
> > . should this affect the mode line?
>
> Absolutely.
Frame zooming does that.
> > . should this affect tooltips?
>
> Yes, to the extent that we have control over that.
Frame zooming does not do that.
(And I, for one, don't think I would want that. Maybe
it could be an optional behavior, if there's really a
use case for it.)
> > . should this affect the fringes and their bitmaps?
>
> That would be nice.
Frame zooming does not do that.
Likewise, it doesn't zoom scroll bar width. But it would
certainly be possible to zoom such things (and tooltips).
That should likely be optional - be able to specify for
_each_ such non-font thing whether to zoom it when zooming
a frame.
> > . should this affect the menu bar, the drop-down menus, and the GUI
> > dialogs?
>
> That's extra credit; I guess it could be nice?
Frame zooming does not do that.
> I hear "how do I resize the font in Emacs again?"
> more than once a week these days
There are likely many things in Emacs that people
learn and forget, if they don't use them often.
And not just Emacs. I'm sure you're used to that,
as a teacher.
> A good approximation of what I would like that
> command to do is what menu-set-font does if you
> ignore the part about changing the face and only
> change the size part.
Frame zooming does that.
> Something similar to doing text-scale-adjust in
> every buffer would also work, too
That wouldn't let you show parts of the same buffer
in different windows with text show at different
sizes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 16:40:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> > I hear "how do I resize the font in Emacs again?"
> > more than once a week these days ^^).
>
> Why not point them to Options->Set Default Font menu item? That does
> almost everything you asked for in your answer to my questions. In
> fact, given that we already have that menu item, it could be argued we
> already have the feature implemented.
For only that use case, that suffices, indeed.
But this enhancement request is about _incrementally_
zooming (I think); that is, the kind of thing you do
with `C-x (+|-)'.
Users of other apps, especially browsers, are used to
using, say, `C-(+-)' or `C-wheel-(up|down)' to zoom
the browser window.
(You can also a mouse wheel for frame zooming with
zoom-frm.el. I use that most of the time, not
`C-x (+|-)'.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 16:59:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "48307 <at> debbugs.gnu.org" <48307 <at> debbugs.gnu.org>
> Date: Sun, 9 May 2021 16:39:33 +0000
>
> > > I hear "how do I resize the font in Emacs again?"
> > > more than once a week these days ^^).
> >
> > Why not point them to Options->Set Default Font menu item? That does
> > almost everything you asked for in your answer to my questions. In
> > fact, given that we already have that menu item, it could be argued we
> > already have the feature implemented.
>
> For only that use case, that suffices, indeed.
>
> But this enhancement request is about _incrementally_
> zooming (I think); that is, the kind of thing you do
> with `C-x (+|-)'.
When you click on that menu item, Emacs pops up a GUI font selection
dialog, where you can increase or decrease the font size. So if the
font you selected doesn't fit, you can do the same again and pick up a
different size.
IOW, no one said that this has to be done with a key sequence that has
"+" or "-" as its part.
Of course writing a wrapper for that command whcih is bound to mouse
wheel with some modifier should be trivial if that's the main issue
here; patches welcome. I thought the request was for a non-existing
feature, so I pointed out that it already exists.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 20:17:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>
> Not all the implementations are good, and it would be very nice if such
> a feature were available out of the box.
>
Would the following do what you want?
(defun global-text-scale-adjust-do (increment)
(set-face-attribute 'default nil :height
(+ (face-attribute 'default :height) increment))
(message "Use + and - for further adjustment")
(set-transient-map
(let ((map (make-sparse-keymap)))
(define-key map (kbd "+") 'global-text-scale-adjust-increase)
(define-key map (kbd "-") 'global-text-scale-adjust-decrease)
map)))
(defun global-text-scale-adjust-increase ()
(interactive)
(global-text-scale-adjust-do +5))
(defun global-text-scale-adjust-decrease ()
(interactive)
(global-text-scale-adjust-do -5))
(global-set-key (kbd "C-x M-+") 'global-text-scale-adjust-increase)
(global-set-key (kbd "C-x M--") 'global-text-scale-adjust-decrease)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 21:37:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/9/21 4:16 PM, Gregory Heytings wrote:
>> Not all the implementations are good, and it would be very nice if such a feature were available out of the box.
>>
>
> Would the following do what you want?
>
> (defun global-text-scale-adjust-do (increment)
> (set-face-attribute 'default nil :height
> (+ (face-attribute 'default :height) increment))
> (message "Use + and - for further adjustment")
> (set-transient-map
> (let ((map (make-sparse-keymap)))
> (define-key map (kbd "+") 'global-text-scale-adjust-increase)
> (define-key map (kbd "-") 'global-text-scale-adjust-decrease)
> map)))
> (defun global-text-scale-adjust-increase ()
> (interactive)
> (global-text-scale-adjust-do +5))
> (defun global-text-scale-adjust-decrease ()
> (interactive)
> (global-text-scale-adjust-do -5))
> (global-set-key (kbd "C-x M-+") 'global-text-scale-adjust-increase)
> (global-set-key (kbd "C-x M--") 'global-text-scale-adjust-decrease)
Yup, probably. The performance isn't great, but that's more or less what I have in my .emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 21:39:03 GMT)
Full text and
rfc822 format available.
Message #44 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/9/21 11:58 AM, Drew Adams wrote:
> It doesn't really look like zoom-frm.el RE-implements this.
Sorry if the term RE-implementing ruffled feathers. If zoom-frm works well and can be merged into Emacs, then it would fit the bill perfectly, I expect.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 22:04:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>
> Yup, probably.
>
Why "probably"? Is something missing?
>
> The performance isn't great,
>
Of course, if you need to recalculate all fonts and redisplay all frames,
it takes some time. But AFAICS the performance is similar to the one of,
say, Chromium or Visual Studio when you press C-+ and C--. The effect is
not immediate.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 22:16:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/9/21 6:03 PM, Gregory Heytings wrote:
>
>>
>> Yup, probably.
>>
>
> Why "probably"? Is something missing?
I'm not sure: I don't know if this is the right implementation, or if there's something subtly wrong about it. It looks good to me (though it's missing a command to go back to the original size), but since there are many implementations that use different strategies I had concluded that there must be some subtlety.
>> The performance isn't great,
>>
>
> Of course, if you need to recalculate all fonts and redisplay all frames, it takes some time. But AFAICS the performance is similar to the one of, say, Chromium or Visual Studio when you press C-+ and C--. The effect is not immediate.
There's something more subtle happening, because using text-scale-adjust is much faster, even on a frame with a single buffer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 22:31:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/9/21 12:58 PM, Eli Zaretskii wrote:
> Of course writing a wrapper for that command whcih is bound to mouse
> wheel with some modifier should be trivial if that's the main issue
> here; patches welcome. I thought the request was for a non-existing
> feature, so I pointed out that it already exists.
Sorry, it sounds like the original request was unclear. Drew's description is pretty good. The request is specifically for a new keybinding; it may well be that the code that goes behind it is trivial.
I'd love to provide a patch, but I have no idea what it should say. I've counted 5 different implementations of the functionality (6 now with Gregory's). All are acceptable, and I don't know enough about Emacs' fonts to judge which one is best, or whether they're all equally reasonable (for example Gregory uses set-face-attribute, and Steve uses face-spec-set in default-text-scale.el).
On 5/9/21 12:08 PM, Eli Zaretskii wrote:
> In fact, given that we already have that menu item, it could be argued we
> already have the feature implemented.
Almost, yes. What we're missing are commands for incrementing and decrementing the size interactively; we only menu-set-font. It's indeed what I recommend that people use when they ask. It's pretty good, even though sometimes (depending on how the user configured fonts in the first place) it starts with the wrong size and font, so you have to scroll through the list.
Sorry for not mentioning menu-set-font explicitly in the original message.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sun, 09 May 2021 22:57:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>
> I'm not sure: I don't know if this is the right implementation, or if
> there's something subtly wrong about it. It looks good to me (though
> it's missing a command to go back to the original size), but since there
> are many implementations that use different strategies I had concluded
> that there must be some subtlety.
>
I don't know. It's certainly possible to do something more complex, but
this is equivalent to changing the size with Options -> Set Default Font.
>
> There's something more subtle happening, because using text-scale-adjust
> is much faster, even on a frame with a single buffer.
>
Again I don't know, but I don't think so. AFAICS it's faster because
redisplaying a single buffer without changing the window and frame size is
faster than redisplaying all buffers in a frame and resizing the frame
itself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 08:25:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>> I suppose you mean a command for all _frames_. Any buffer-local text
>> scaling would still override that.
>
> Sure: I meant something that scales the font in every window (and
> possibly in every frame, too, indeed)
There is one subtle difference you should be aware of:
(1) If you change the size of the default font of a live frame, that
frame's size may change unless you rule out implied resizing for it.
(2) If you change the font in all windows showing a buffer by adjusting
that buffer's text scaling, frame sizes will stay the same.
So you have to be precise about the "something that scales" you want.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:18:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> There is one subtle difference you should be aware of:
>
> (1) If you change the size of the default font of a live frame, that
> frame's size may change unless you rule out implied resizing for
> it.
>
> (2) If you change the font in all windows showing a buffer by adjusting
> that buffer's text scaling, frame sizes will stay the same.
>
> So you have to be precise about the "something that scales" you want.
Indeed. Zooming (text scaling or frame zooming) and
fitting windows or frames to buffer text are different
things. There should be ways to get different
combinations (e.g. autofit window/frame or not).
To enable windows to show the same text (e.g. without
wrapping or introducing extra blank space at the
right), I introduced option `text-scale-resize-window'.
It lets you automatically resize the selected window
(horizontally, vertically, or both) when text is
resized, so that the way the window fits the buffer
text remains relatively constant.
Shrinking the text in one window shrinks that window,
giving more space to adjacent windows.
If you also use library `fit-frame.el', then 1-window
frames also respond to text resizing by scaling. If
not, then the text-scale commands have no effect on
frame size for one-window frames.
(I tried to get Emacs to add such an option, but had
no luck with that.)
https://www.emacswiki.org/emacs/download/face-remap%2b.el
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:18:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 48307 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for mentioning frame-inhibit-implied-resize, I did not know it
exists.
I attach a patch that does, I believe, what Clément has in mind.
Comments and feedback welcome.
Note that this patch can't be applied yet, my paperwork is still not
finished :(
[Global-adjustments-to-the-default-face.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:20:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 09 May 2021 22:56:34 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: 48307 <at> debbugs.gnu.org
>
> > There's something more subtle happening, because using text-scale-adjust
> > is much faster, even on a frame with a single buffer.
>
> Again I don't know, but I don't think so. AFAICS it's faster because
> redisplaying a single buffer without changing the window and frame size is
> faster than redisplaying all buffers in a frame and resizing the frame
> itself.
Enlarging the frame means we also interact with the WM and await its
response, no?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:25:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>>> There's something more subtle happening, because using
>>> text-scale-adjust is much faster, even on a frame with a single
>>> buffer.
>>
>> Again I don't know, but I don't think so. AFAICS it's faster because
>> redisplaying a single buffer without changing the window and frame size
>> is faster than redisplaying all buffers in a frame and resizing the
>> frame itself.
>
> Enlarging the frame means we also interact with the WM and await its
> response, no?
>
The patch I just sent avoids that problem, and does what other programs do
when the user zooms: their frames are not resized.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:27:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 10 May 2021 14:17:55 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: Clément Pit-Claudel <cpitclaudel <at> gmail.com>,
> 48307 <at> debbugs.gnu.org
>
> + (let ((frame-inhibit-implied-resize t))
> + (set-face-attribute 'default nil :height
> + (+ (face-attribute 'default :height) inc)))
Why does it make sense to inhibit frame resizing in this case? I
think it will make an ugly display: mode-line text will spill over,
lines will become wrapped, etc.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:34:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 10 May 2021 14:24:35 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: cpitclaudel <at> gmail.com, 48307 <at> debbugs.gnu.org
>
> The patch I just sent avoids that problem, and does what other programs do
> when the user zooms: their frames are not resized.
I think it's a mistake. Other programs don't change all the fonts on
display, only the one in the main window, which is more similar to
text-scale-adjust. This feature was supposed to change _everything_,
which is why it modifies the default face.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:34:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> The patch I just sent avoids that problem, and does what other
> programs do when the user zooms: their frames are not resized.
Doing just what other programs do can be good or bad -
a blessing or a curse. It's often better to be able to
do so, but not be limited to doing so.
Not resizing the frame to continue to show the buffer
in the same way within it (e.g. perhaps no wrapping
and no wasted blank space at the right) is not
necessarily what a given user wants in a given context.
I use automatic fitting of frames to the (single) buffer
shown in them, by default. Zooming a frame, and having
it continue to fit the text the same way, is a feature,
not a bug. Like most features, it should of course be
optional.
As I mentioned in a earlier mail in this thread today,
I provided similar optional behavior for text scaling.
Zooming out by text scaling shouldn't necessarily add,
in effect, a lot of blank space at the right. (I like
to avoid such wasted space, whether it's for windows
or frames, in general.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:35:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>> + (let ((frame-inhibit-implied-resize t))
>> + (set-face-attribute 'default nil :height
>> + (+ (face-attribute 'default :height) inc)))
>
> Why does it make sense to inhibit frame resizing in this case? I think
> it will make an ugly display: mode-line text will spill over, lines will
> become wrapped, etc.
>
Because (1) it's what other programs do, (2) it's also what
text-scale-adjust does, (3) it's much faster, (4) if you do not inhibit
frame resizing the frame can easily become larger than your screen. Note
that global-text-scale-adjust uses smaller steps than text-scale-adjust,
so the user can more easily control the potential undesirable effects.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:43:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> > Why does it make sense to inhibit frame resizing in this case? I
> > think it will make an ugly display: mode-line text will spill over,
> > lines will become wrapped, etc.
> >
>
> Because (1) it's what other programs do,
See what I wrote. That can be good and bad.
Why limit Emacs to what other programs do?
> (2) it's also what text-scale-adjust does,
See what I wrote. Text scaling too can benefit from
being able to fit window size to text, to keep what
you see pretty much the same regardless of zoom
factor.
> (3) it's much faster, (4) if you do not inhibit
> frame resizing the frame can easily become larger
> than your screen.
Depends on what the code resizing the frame does.
Nothing requires frame resizing not to respect
screen boundaries. (But yes, usually it's a
_feature_ that you can have part of a window-mgr
window (frame) off-screen.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 14:55:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/10/21 10:26 AM, Eli Zaretskii wrote:
>> Date: Mon, 10 May 2021 14:17:55 +0000
>> From: Gregory Heytings <gregory <at> heytings.org>
>> Cc: Clément Pit-Claudel <cpitclaudel <at> gmail.com>,
>> 48307 <at> debbugs.gnu.org
>>
>> + (let ((frame-inhibit-implied-resize t))
>> + (set-face-attribute 'default nil :height
>> + (+ (face-attribute 'default :height) inc)))
>
> Why does it make sense to inhibit frame resizing in this case? I
> think it will make an ugly display: mode-line text will spill over,
> lines will become wrapped, etc.
I think preventing frame resizing is the right move, at least in the context that I had in mind (screen sharing): if you scale the frame and the font at once, then nothing changes on the recipient's screen (since the videoconferencing software scales the frame to a constant size).
(Besides, that's what menu-set-font does; and it's easy to resize the frame after scaling the font, no?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 15:08:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 48307 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> Why does it make sense to inhibit frame resizing in this case? I
>>> think it will make an ugly display: mode-line text will spill over,
>>> lines will become wrapped, etc.
>>
>> Because (1) it's what other programs do,
>
> See what I wrote. That can be good and bad. Why limit Emacs to what
> other programs do?
>
I don't want to limit Emacs to anything... but not everything can be bound
to a key or a mouse event. Perhaps this could become a defcustom,
defaulting to t? I tried to understand what Clément had in mind, and IIUC
my understanding was right.
I will not use that feature, but I tried both frame-inhibit-implied-resize
nil and t, and I'd guess that t is what most users would want.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 15:23:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> > Why does it make sense to inhibit frame resizing in this case? I
> > think it will make an ugly display: mode-line text will spill over,
> > lines will become wrapped, etc.
>
> I think preventing frame resizing is the right move,
There's no single "right" move, here, IMO. Which
behavior should be the _default_ one is a different
question. But both behaviors should be possible -
each has its uses.
> at least in the context that I had in mind (screen sharing)
Exactly - see above. That's a particular context.
> (Besides, that's what menu-set-font does;
Not very relevant, IMO, but OK. Again, this is a
consideration, perhaps, for which behavior to choose
as default.
> and it's easy to resize the frame after scaling the font, no?)
No. It's not so easy to get right, e.g. to keep the
same fit as before zooming (text scaling or frame
zooming). And someone who wants that likely doesn't
want to have to do it manually each time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 15:27:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> >>> Why does it make sense to inhibit frame resizing in this case? I
> >>> think it will make an ugly display: mode-line text will spill over,
> >>> lines will become wrapped, etc.
> >>
> >> Because (1) it's what other programs do,
> >
> > See what I wrote. That can be good and bad. Why limit Emacs to what
> > other programs do?
>
> I don't want to limit Emacs to anything... but not everything can be
> bound to a key or a mouse event. Perhaps this could become a defcustom,
> defaulting to t?
,----
| text-scale-resize-window is a variable defined in `face-remap+.el'.
|
| Its value is t
|
| Documentation:
| Non-nil means text scaling resizes the window or frame accordingly.
| For example, if you use `C-x C--' (`text-scale-decrease')' to make the
| text smaller, then the window or frame is made smaller by a similar
| factor.
|
| If the window is not alone in its frame, then the window is resized.
| Otherwise, the frame is resized (provided you also use library
| `fit-frame.el'). The frame is always resized both horizontally and
| vertically.
|
| You can customize this variable.
`----
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 15:37:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/10/21 11:22 AM, Drew Adams wrote:
>>> Why does it make sense to inhibit frame resizing in this case? I
>>> think it will make an ugly display: mode-line text will spill over,
>>> lines will become wrapped, etc.
>>
>> I think preventing frame resizing is the right move,
>
> There's no single "right" move, here, IMO. Which
> behavior should be the _default_ one is a different
> question. But both behaviors should be possible -
> each has its uses.
Well, there's a concrete request that stems from a concrete need — my students and colleagues running into trouble when sharing their screen. Of course, I don't have objections to including other features.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 16:17:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Cc: rudalics <at> gmx.at, 48307 <at> debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Mon, 10 May 2021 10:53:57 -0400
>
> (Besides, that's what menu-set-font does
No, it doesn't, at least not here. My frame is resized when I choose
the same font of a different size.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 16:25:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 48307 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> The patch I just sent avoids that problem, and does what other programs
>> do when the user zooms: their frames are not resized.
>
> I think it's a mistake. Other programs don't change all the fonts on
> display, only the one in the main window, which is more similar to
> text-scale-adjust. This feature was supposed to change _everything_,
> which is why it modifies the default face.
>
Indeed, but that feature is already present on C-x C-{+-0}. And I don't
know any other program that changes its frame size when a zoom factor is
applied.
What the existing C-x C-{+-0} does is what C-{+-0} does in Atom. What the
proposed C-x C-M-{+-0} does is what C-{+-0} does in Visual Studio.
As I said, I would not object to make this configurable with a defcustom,
which would default to "do not resize". Would you agree with that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 16:27:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/10/21 12:16 PM, Eli Zaretskii wrote:
>> Cc: rudalics <at> gmx.at, 48307 <at> debbugs.gnu.org
>> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
>> Date: Mon, 10 May 2021 10:53:57 -0400
>>
>> (Besides, that's what menu-set-font does
>
> No, it doesn't, at least not here. My frame is resized when I choose
> the same font of a different size.
Good catch. But not past the size of the screen, it seems.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 16:47:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/10/21 10:17 AM, Gregory Heytings wrote:
> Thanks for mentioning frame-inhibit-implied-resize, I did not know it exists.
>
> I attach a patch that does, I believe, what Clément has in mind. Comments and feedback welcome.
>
> Note that this patch can't be applied yet, my paperwork is still not finished :(
The patch looks good, thanks!. You could bind combinations with '=', too, since text-scale-adjust does that (you can press = instead of +).
More complicated: I wonder if it'd be easy to ignore repeated delayed input. As it stands, keeping '+' pressed will zoom in continuously, and continue zooming in after '+' is released, until all buffered repeated '+' inputs are processed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 18:18:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>
> More complicated: I wonder if it'd be easy to ignore repeated delayed
> input. As it stands, keeping '+' pressed will zoom in continuously, and
> continue zooming in after '+' is released, until all buffered repeated
> '+' inputs are processed.
>
What do you mean exactly by "ignore repeated delayed input"? Do you want
to "throw away" the remaining "+" keys when "+" is released? Or do you
want to disable the zoom effect, count the "+" keypresses, and apply the
effect of all the keys in one go?
(My computer is a bit too fast I guess, I cannot see what you see.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 18:36:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/10/21 2:16 PM, Gregory Heytings wrote:
>
>>
>> More complicated: I wonder if it'd be easy to ignore repeated delayed input. As it stands, keeping '+' pressed will zoom in continuously, and continue zooming in after '+' is released, until all buffered repeated '+' inputs are processed.
>>
>
> What do you mean exactly by "ignore repeated delayed input"? Do you want to "throw away" the remaining "+" keys when "+" is released?
This one.
> (My computer is a bit too fast I guess, I cannot see what you see.)
Either that, or my keyboard is fast :) Try adding (sleep-for 1) right before the font size adjustment, then press "+" for a second or so and release it. Emacs will keep processing the delayed "+" input and keep zooming.
Not sure that it matters much.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 18:47:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Mon, 10 May 2021 14:34:58 -0400
> Cc: 48307 <at> debbugs.gnu.org
>
> Either that, or my keyboard is fast :) Try adding (sleep-for 1) right before the font size adjustment, then press "+" for a second or so and release it. Emacs will keep processing the delayed "+" input and keep zooming.
I don't think that Emacs can know when the user stopped pressing the
keys. Without that, how can we know when to discard keypresses still
in the queue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 19:05:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/10/21 2:46 PM, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
>> Date: Mon, 10 May 2021 14:34:58 -0400
>> Cc: 48307 <at> debbugs.gnu.org
>>
>> Either that, or my keyboard is fast :) Try adding (sleep-for 1) right before the font size adjustment, then press "+" for a second or so and release it. Emacs will keep processing the delayed "+" input and keep zooming.
>
> I don't think that Emacs can know when the user stopped pressing the
> keys. Without that, how can we know when to discard keypresses still
> in the queue.
Got it, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 19:36:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 48307 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here is the updated patch with, as discussed, a new user option to control
the frame resizing, and the additional C-x C-M-= binding.
[Global-adjustments-to-the-default-face.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 19:42:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 48307 <at> debbugs.gnu.org (full text, mbox):
On 5/10/21 3:35 PM, Gregory Heytings wrote:
> Here is the updated patch with, as discussed, a new user option to control the frame resizing, and the additional C-x C-M-= binding.
Looks good! A small stylistic comment:
+ (pcase key
+ ((or ?+ ?=) (* increment 5))
+ (?- (* (- increment) 5))
+ (?0 (- global-text-scale-adjust--default-height
+ (face-attribute 'default :height)))
+ (_ (* increment 5)))))
Do you need the first branch? If you remove it, those cases will be caught by the default fall-through.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Mon, 10 May 2021 19:48:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>
> Looks good! A small stylistic comment:
>
> + (pcase key
> + ((or ?+ ?=) (* increment 5))
> + (?- (* (- increment) 5))
> + (?0 (- global-text-scale-adjust--default-height
> + (face-attribute 'default :height)))
> + (_ (* increment 5)))))
>
> Do you need the first branch? If you remove it, those cases will be
> caught by the default fall-through.
>
Oh yes, indeed! Thanks :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Tue, 25 May 2021 07:59:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 48307 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Updated patch attached. The main added feature is that face resizing is
now bounded (between 10 and 500).
[Global-adjustments-to-the-default-face.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Tue, 25 May 2021 12:32:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 25 May 2021 07:58:42 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> Cc: 48307 <at> debbugs.gnu.org
>
> Updated patch attached.
Thanks.
> The main added feature is that face resizing is now bounded (between
> 10 and 500).
Hmm, the GCS frowns on arbitrary limits, so perhaps we should have a
defcustom to control the limits?
> +@kindex C-M-wheel-up
> + Similarly, to change the height of the default face globally, type
> +@kbd{C-x C-M-+}, @kbd{C-x C-M-=}, @kbd{C-x C-M--} or @kbd{C-x C-M-0},
> +or scroll the mouse wheel with both the @kbd{Ctrl} and @kbd{Meta}
> +modifiers pressed. To enable frame resizing when the height of the
> +default face is changed globally, customize the variable
> +@code{global-text-scale-adjust-resizes-frames} (@pxref{Easy
> +Customization}).
The last part should explain why frame resizing is related to font
size changes, it isn't obvious.
Also, I wonder whether we should say "height of the default face's
font", because this is what this actually does. I'm not sure every
user will understand the notion of the height of a face.
And finally, "height" or "size"?
> +(defun global-text-scale-adjust (increment)
> + "Globally adjust the height of the default face by INCREMENT.
> +
> +INCREMENT may be passed as a numeric prefix argument.
The last sentence should start with "Interactively, ". Also, the doc
string should tell what are the units of INCREMENT.
> +The adjustment made depends on the final component of the key binding
> +used to invoke the command, with all modifiers removed:
I wonder if we could rephrase this to be less awkward and more clear.
> +After adjusting, further adjust the default face height as long as the
> +key, with all modifiers removed, is one of the above characters.
And this.
> +Buffer-local face adjustements remain in effect when global face
> +adjustments are made.
I don't think I understand what this means, so it would be good to
clarify that.
> +The variable `global-text-scale-adjust-resizes-frames' controls whether
> +the frames are resized when the default face is adjusted.
Suggest to say "... resized to keep the same number of lines and
characters per line ...".
> + (inc
> + (pcase key
> + (?- (* (- increment) 5))
> + (?0 (- global-text-scale-adjust--default-height cur))
> + (_ (* increment 5))))
Do we really need pcase here?
> +(defun mouse-wheel-global-text-scale (event)
> + "Increase or decrease the global height of the default face according to the EVENT."
This sentence is too long to fit on a single line. Suggest to make it
shorter:
"Increase or decrease the height of the default face according to EVENT."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Tue, 25 May 2021 13:00:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 48307 <at> debbugs.gnu.org (full text, mbox):
Thanks for your feedback, a few comments before updating the patch:
>> The main added feature is that face resizing is now bounded (between 10
>> and 500).
>
> Hmm, the GCS frowns on arbitrary limits,
>
What is "the GCS"?
>
> so perhaps we should have a defcustom to control the limits?
>
I'd rather wait for a feature request to add a defcustom for this. IMO
10-500 is a reasonable range for that feature, 10 is really small and 500
is really huge.
>
> Also, I wonder whether we should say "height of the default face's
> font", because this is what this actually does. I'm not sure every user
> will understand the notion of the height of a face.
>
I used "height" because it's what text-scale-{adjust,increase,decrease}
use. Otherwise I would have used the word "size" indeed. WDYT?
>> +Buffer-local face adjustements remain in effect when global face
>> +adjustments are made.
>
> I don't think I understand what this means, so it would be good to
> clarify that.
>
It means that if you C-x C-+ in a buffer B (buffer-local face adjustment),
and then C-x C-M-+, the buffer-local adjustment in B remains in effect, or
IOW that after C-x C-M-+ the buffer B will still have a larger font than
the other buffers.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Tue, 25 May 2021 13:13:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 25 May 2021 12:58:59 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: cpitclaudel <at> gmail.com, 48307 <at> debbugs.gnu.org
>
> Thanks for your feedback, a few comments before updating the patch:
>
> >> The main added feature is that face resizing is now bounded (between 10
> >> and 500).
> >
> > Hmm, the GCS frowns on arbitrary limits,
> >
>
> What is "the GCS"?
GNU Coding Standards.
> > so perhaps we should have a defcustom to control the limits?
> >
>
> I'd rather wait for a feature request to add a defcustom for this. IMO
> 10-500 is a reasonable range for that feature, 10 is really small and 500
> is really huge.
We could avoid arguing about what's reasonable by providing an option.
Lars, WDYT?
> > Also, I wonder whether we should say "height of the default face's
> > font", because this is what this actually does. I'm not sure every user
> > will understand the notion of the height of a face.
> >
>
> I used "height" because it's what text-scale-{adjust,increase,decrease}
> use. Otherwise I would have used the word "size" indeed. WDYT?
I prefer "size".
> >> +Buffer-local face adjustements remain in effect when global face
> >> +adjustments are made.
> >
> > I don't think I understand what this means, so it would be good to
> > clarify that.
> >
>
> It means that if you C-x C-+ in a buffer B (buffer-local face adjustment),
> and then C-x C-M-+, the buffer-local adjustment in B remains in effect, or
> IOW that after C-x C-M-+ the buffer B will still have a larger font than
> the other buffers.
I think what's missing is the last part you wrote, or some variant
thereof. "Remains in effect" is ambiguous because it isn't clear
whether the absolute size remains in effect or the relative size does.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Tue, 25 May 2021 13:17:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 48307 <at> debbugs.gnu.org (full text, mbox):
>>> Also, I wonder whether we should say "height of the default face's
>>> font", because this is what this actually does. I'm not sure every
>>> user will understand the notion of the height of a face.
>>
>> I used "height" because it's what text-scale-{adjust,increase,decrease}
>> use. Otherwise I would have used the word "size" indeed. WDYT?
>
> I prefer "size".
>
Okay, so should I also replace the word "height" by "size" in
text-scale-{adjust,increase,decrease}?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Tue, 25 May 2021 13:43:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 48307 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 25 May 2021 13:16:42 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: cpitclaudel <at> gmail.com, 48307 <at> debbugs.gnu.org
>
>
> >>> Also, I wonder whether we should say "height of the default face's
> >>> font", because this is what this actually does. I'm not sure every
> >>> user will understand the notion of the height of a face.
> >>
> >> I used "height" because it's what text-scale-{adjust,increase,decrease}
> >> use. Otherwise I would have used the word "size" indeed. WDYT?
> >
> > I prefer "size".
>
> Okay, so should I also replace the word "height" by "size" in
> text-scale-{adjust,increase,decrease}?
I guess so, yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Tue, 25 May 2021 19:44:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 48307 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> The main added feature is that face resizing is now bounded (between 10
>> >> and 500).
[...]
>> I'd rather wait for a feature request to add a defcustom for this. IMO
>> 10-500 is a reasonable range for that feature, 10 is really small and 500
>> is really huge.
>
> We could avoid arguing about what's reasonable by providing an option.
I can definitely see people wanting to go below 10, so I think a user
option here would be nice.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#48307; Package
emacs.
(Sat, 02 Jul 2022 13:43:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 48307 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <gregory <at> heytings.org> writes:
> From d47e46a0108aa3499cdf4ff61da5134650a96818 Mon Sep 17 00:00:00 2001
> From: Gregory Heytings <gregory <at> heytings.org>
> Date: Tue, 25 May 2021 07:56:38 +0000
> Subject: [PATCH] Global adjustments to the default face
>
> * lisp/face-remap.el (global-text-scale-adjust): New command.
> (text-scale-adjust): Refer to the new related command.
> (global-text-scale-adjust-resizes-frames): New user option.
I've now respun the patch for Emacs 29, and it seems to work well, so
I've now pushed, adjusting for the comments that arrived after the
patch, and general changes in the terminology in this area that have
been done lately.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
48307 <at> debbugs.gnu.org and Clément Pit-Claudel <cpitclaudel <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 02 Jul 2022 13:43:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 31 Jul 2022 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 327 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.