From: Ship Mints <shipmints@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Eli Zaretskii <eliz@gnu.org>, 74750@debbugs.gnu.org
Subject: bug#74750: clone-frame and make-frame pixelwise issues
Date: Fri, 13 Dec 2024 13:25:03 -0500 [thread overview]
Message-ID: <CAN+1Hbq74abEhFnXxffc9Y=5oNsQNNo+AZJGcef9P6YR1DTMuA@mail.gmail.com> (raw)
In-Reply-To: <a68a7dd9-17de-4fba-bad9-d37ea7493db1@gmx.at>
[-- Attachment #1: Type: text/plain, Size: 4518 bytes --]
On Fri, Dec 13, 2024 at 1:15 PM martin rudalics <rudalics@gmx.at> wrote:
> > Thank you for the patch and continued focus on this. The following is
> the
> > behavior I see on NS with the patch applied with target width 1700 and
> > height 1000. These are results from clone-frame using text-pixels which
> > I've included below without explicit pixelwise argument so it respects
> > frame-resize-pixelwise.
>
> Thank you for conducting these experiments.
>
My pleasure, actually. I live inside Emacs so the better we make it for us
the better for all.
> Note: frame-inhibit-implied-resize=(tab-bar-lines) is the default setting
> > on NS:
> >
> > #if defined (USE_GTK) || defined (HAVE_NS)
> > frame_inhibit_implied_resize = list1 (Qtab_bar_lines);
> >
> > frame-resize-pixelwise=nil frame-inhibit-implied-resize=nil
> text-width=1692
> > (Δ-8) text-height=984 (Δ-16) native-width=1727 (Δ-8) native-height 988
> > (Δ-16)
> >
> > Result: respects lines/cols as expected.
>
> It's problematic to clone a frame made with 'frame-resize-pixelwise'
> non-nil in a setting with 'frame-resize-pixelwise' nil. I always have
> 'frame-resize-pixelwise' t and never change it.
>
As you pointed out, these are experiments and reflect the desire to fully
understand (and control) Emacs behavior under various circumstances we
encounter.
> > frame-resize-pixelwise=t frame-inhibit-implied-resize=(tab-bar-lines)
> > text-width=1700 (Δ0) text-height=1000 (Δ0) native-width=1735 (Δ0)
> > native-height 1004 (Δ0)
> >
> > Result: Okay by accident, I think, only because tab-bar-lines parameter
> is
> > nil during adjust_frame_height invocations?
>
> adjust_frame_size you mean, I suppose. Does your frame have a tab bar?
>
Yes, typo. These results are all under -Q as we need to repro, so no
visible tab bar, just the default NS view which is the tool bar which under
master, now appears on the title bar. Something I didn't notice until today
but it's neither here nor there, I suppose. I disable tool-bar under all my
own real-world circumstances.
> frame-resize-pixelwise=t frame-inhibit-implied-resize=nil text-width=1700
> > (Δ0) text-height=1000 (Δ0) native-width=1735 (Δ0) native-height 1004
> (Δ0)
> >
> > Result: Okay but with frame-inhibit-implied-resize nil, I'd have
> expected
> > rows/cols vs. pixelwise.
>
> Why? 'frame-inhibit-implied-resize' is about _not_ resizing a frame's
> window when one removes/adds one of the items it mentions. It should
> work with pixelwise and normal resizing.
>
I said that because the latest patch respects frame-inhibit-implied-resize
not frame-resize-pixelwise.
> frame-resize-pixelwise=t frame-inhibit-implied-resize=t text-width=1685
> > (Δ-15) text-height=1000 (Δ0) native-width=1720 (Δ-15) native-height 1004
> > (Δ0)
> >
> > Result: I think this case remains broken needing the adjustment from
> your
> > first patch that you wanted to also account for fringes?
>
> 15 is an odd number so it can't be the default fringes. IIUC it's your
> scroll bar which gets set up after the "frame was made" and while
> resizing is inhibited. Note that the fringes are purely Emacs internal
> - we can set them up any way we like. The scroll bar is more difficult
> since the toolkit usually determines its default width. You could try
> to debug this with a breakpoint in 'gui_set_scroll_bar_width' and after
> that one in 'frame_inhibit_resize'. Here on xfwm/GTK-3 the text width
> remains unchanged.
>
Indeed 15 is the vertical scroll bar width. This was what I reported in the
original bug submission. You suggested a patch that would accommodate
fringes, et.al. If you'd like me to make adjustments; e.g., resizing
fringes or whatever, happy to do it and rerun.
These are all ostensively calls to clone-frame. I'd expect, as I guess most
people would, that cloning produces the precise geometry of the originating
frame, scroll bar or not.
> > My default GUI setup is frame-resize-pixelwise t
> > frame-inhibit-implied-resize t as I expect many people have adopted
> these
> > days.
>
> Few people have AFAICT. Note that all these experiments are borderline.
> Cloning a frame should respect the settings that were active at the time
> the original was made. We can try to make it behave reasonably when
> these values change but I am not sure whether we will succeed.
>
Let's try.
-Stephane
[-- Attachment #2: Type: text/html, Size: 6892 bytes --]
prev parent reply other threads:[~2024-12-13 18:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-09 15:51 bug#74750: clone-frame and make-frame pixelwise issues Ship Mints
2024-12-10 12:27 ` Eli Zaretskii
2024-12-10 15:56 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-10 16:24 ` Ship Mints
2024-12-11 9:37 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-11 22:41 ` Ship Mints
2024-12-12 6:05 ` Eli Zaretskii
2024-12-12 9:22 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-13 10:30 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-13 16:28 ` Ship Mints
2024-12-13 18:15 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-13 18:25 ` Ship Mints [this message]
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='CAN+1Hbq74abEhFnXxffc9Y=5oNsQNNo+AZJGcef9P6YR1DTMuA@mail.gmail.com' \
--to=shipmints@gmail.com \
--cc=74750@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).