From: Emre Yolcu <mail@emreyolcu.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 71085@debbugs.gnu.org
Subject: bug#71085: text-scale-adjust does not adjust margin width
Date: Tue, 21 May 2024 12:14:41 -0400 [thread overview]
Message-ID: <c9163847-ba87-4fe8-8297-5d2b986466e8@emreyolcu.com> (raw)
In-Reply-To: <86r0dv8kes.fsf@gnu.org>
Eli Zaretskii wrote:
> I don't understand the expectations: the window and frame geometry are
> not changed by text-scale-adjust, so why did you expect the window
> margins to change? The margins are part of the window geometry.
I was not thinking of the margins as part of the window geometry but as
a special part of the buffer that we set aside and do not interact with.
This is partly because the margins display text, the height of which is
affected by text-scale-adjust, and partly because there is no visual
separation between the margin and the buffer (assuming fringes are
disabled). For comparison, the mode line also displays text, but it has
its own face and its text size is not affected by text-scale-adjust (as
one would expect). The fringe also has its own face, as do all of the
other things that I would consider to be part of the window geometry,
but there is no "margin" face. (I am aware that we can affect its
display to some degree by propertizing the text in it.)
> Since Emacs 29.1, we have global-text-scale-adjust-resizes-frames,
> which, if non-nil, causes the frame to resize when you change the
> text-size globally (e.g., with C-M-+ or C-M-mouse-wheel). If you do
> that, the window-margins resize as well, which in this case is indeed
> expected (and works for me).
Thanks for that suggestion. Indeed, I often change text size globally,
but sometimes resizing in a buffer-local manner is nice to have.
>> It also seems to me that there is no way to work around this problem in
>> the Elisp layer, because text-scale-mode works by remapping faces in a
>> buffer-local manner; however,
>> - there is no face defined for the margins, and
>> - it seems that the pixel width of the margins is not determined in a
>> buffer-local manner.
>>
>> Given that {left,right}-margin-width are buffer-local variables, I would
>> expect their pixel width to be determined in a buffer-local manner.
> The above is inaccurate: the text shown in the margin can have its own
> distinct face. For example, try this in "emacs -Q":
>
> M-x font-lock-mode RET
> M-<
> M-: (set-window-margins nil 4 4) RET
> M-: (add-text-properties (point) (1+ (point)) (list 'display (list '(margin left-margin) (propertize "FOO" 'face 'warning)))) RET
>
> You will see the string "FOO" displayed in the margin with a distinct
> face. You could define this face to have an absolute :height
> attribute, in which case the text in the margin will not scale, and
> thus will not be clipped when you use text-size-adjust. So there _is_
> in fact a way to work around, even if you don't want to use
> global-text-scale-adjust-resizes-frames and the globalized
> text-scaling.
I didn't mean to imply that we cannot affect the appearance of the text
displayed in the margins in any way, but simply that there is no
"margin" face that a user can modify via, for instance,
custom-set-faces. The workaround that you suggested requires the user to
patch every single package that displays text in the margins, which is
less than ideal. A much nicer workaround would be possible if there
existed a "margin" face: text-scale-mode could simply remap it as it
does the default face. As a motivating example, let me point out that
text-scale-mode defines the variable text-scale-remap-header-line to
allow resizing the size of the header line along with buffer text. If a
"margin" face existed, we could add a new variable
text-scale-remap-margin to achieve the behavior I suggested in an easy way.
> I see no bug here.
Fair enough. Please consider it a feature request for a "margin" face
(for the reasons in the above paragraph). This is admittedly a highly
niche problem, so I would understand if you think it is not worth the
time. However, if you at least agree that having a face for the margins
would be a welcome addition, I could make an attempt at a patch.
next prev parent reply other threads:[~2024-05-21 16:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-20 22:50 bug#71085: text-scale-adjust does not adjust margin width Emre Yolcu
2024-05-21 11:38 ` Eli Zaretskii
2024-05-21 16:14 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-21 16:14 ` Emre Yolcu [this message]
2024-05-21 18:17 ` Eli Zaretskii
2024-05-21 20:10 ` Emre Yolcu
2024-05-22 12:03 ` Eli Zaretskii
2024-05-22 17:05 ` Emre Yolcu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c9163847-ba87-4fe8-8297-5d2b986466e8@emreyolcu.com \
--to=mail@emreyolcu.com \
--cc=71085@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.