unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).