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

      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).