unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Aaron Jensen <aaronjensen@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Eli Zaretskii <eliz@gnu.org>, 56102@debbugs.gnu.org
Subject: bug#56102: 29.0.50; fit-frame-to-buffer's window-text-pixel-size calculation can be incorrect when only is set to vertically
Date: Fri, 24 Jun 2022 10:28:42 -0400	[thread overview]
Message-ID: <CAHyO48xEnb4RkAsOkMRegb4rfjMpGgL=hLToS9Scxzizy3Z8CQ@mail.gmail.com> (raw)
In-Reply-To: <62155072-ac5f-2a3d-b1dd-0c9363c74975@gmx.at>

On Fri, Jun 24, 2022 at 5:20 AM martin rudalics <rudalics@gmx.at> wrote:
>
>  > That seems to work for me. I do wonder though if the the check for
>  > `only' should be first (i.e. if only is vertically, max-width is nil).
>  > Is there a reason that we should not ignore a specified max-width when
>  > only is set to vertically?
>
> The idea of 'fit-frame-to-buffer' was that an application should be able
> to call it (maybe implicitly via 'temp-buffer-resize-mode') and not care
> about where on the display the frame will be shown.  Hence, a major
> concern of its design was to constrain the frame to some specified area
> on the display, to avoid that parts of it move off screen.  That's why
> 'fit-frame-to-buffer-margins' and 'fit-frame-to-buffer-sizes' have been
> provided.
>
> Currently, we check for an explicit MAX-WIDTH first and then consult
> 'fit-frame-to-buffer-sizes' via SIZES as
>
>                      ((numberp max-width) (* max-width char-width))
>                      ((numberp (nth 2 sizes)) (* (nth 2 sizes) char-width))
>
> If we were to override MAX-WIDTH by setting ONLY to 'vertically', where
> and how would we check SIZES?

I'm definitely not familiar enough with the workings and the intended
use cases. My only thought about it was one of principle of least
surprise. If I say that I only want it to scale vertically, I would
expect no width changes to occur, which means I would expect that
max-width and anything else width related would not be relevant.
There's likely something I'm missing here, so please feel free to
disregard if this is necessary for some reason.

>  > I ask because in the package that I had
>  > this issue with I employed a work-around where I set the max-width to
>  > (frame-parameter frame 'width), which seems to work well enough, but
>  > probably not as good as your fix. We may not be able to remove that
>  > workaround for some time, so ignoring max-width if set would probably
>  > work better in our specific case.
>
> Are these issues really related?  If your workaround works, it should
> continue working regardless of whether we ignore MAX-WIDTH when ONLY is
> 'vertically' or not.  Or am I missing something?

My concern was this:

> Also, the sizes of frame and window decorations would hardly match.

Effectively, that there would be some subtle difference between using
(frame-parameter frame 'width) as MAX-WIDTH and passing nil to
window-text-pixel-size window.

If there's no difference to be concerned about then my workaround
should be fine with the code as it was in the patch.

Thanks,

Aaron





  reply	other threads:[~2022-06-24 14:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20  3:03 bug#56102: 29.0.50; fit-frame-to-buffer's window-text-pixel-size calculation can be incorrect when only is set to vertically Aaron Jensen
2022-06-22 13:58 ` Eli Zaretskii
2022-06-22 14:15   ` Aaron Jensen
2022-06-23  7:30     ` martin rudalics
2022-06-24  2:28       ` Aaron Jensen
2022-06-24  9:20         ` martin rudalics
2022-06-24 14:28           ` Aaron Jensen [this message]
2022-06-26 10:09             ` martin rudalics
2022-06-26 13:12               ` Aaron Jensen
2022-06-27  8:24                 ` martin rudalics
2022-06-27 13:24                   ` Aaron Jensen
2022-06-28  9:29                     ` martin rudalics
2022-06-28 14:52                       ` Aaron Jensen
2022-07-05 13:07                         ` Aaron Jensen
2022-07-06  7:37                           ` martin rudalics
2022-07-06 13:17                             ` Aaron Jensen

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='CAHyO48xEnb4RkAsOkMRegb4rfjMpGgL=hLToS9Scxzizy3Z8CQ@mail.gmail.com' \
    --to=aaronjensen@gmail.com \
    --cc=56102@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=rudalics@gmx.at \
    /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).