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 11:28:49 -0500 [thread overview]
Message-ID: <CAN+1Hbr19zQTQRhN4uT4Z3acej+WuX5d3h+WhFUZXU_9Pd61Sg@mail.gmail.com> (raw)
In-Reply-To: <7404039b-e71e-44e5-a446-70fa07889528@gmx.at>
[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]
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.
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.
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?
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.
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?
My default GUI setup is frame-resize-pixelwise t
frame-inhibit-implied-resize t as I expect many people have adopted these
days.
(defun my/clone-frame (&optional frame no-windows pixelwise)
"Make a new frame with the same parameters and windows as FRAME.
With a prefix arg NO-WINDOWS, don't clone the window configuration. When
PIXELWISE is non-nil or if `frame-resize-pixelwise' is non-nil, and frame
is not text-only, clone the originating frame's pixel size.
FRAME defaults to the selected frame. The frame is created on the
same terminal as FRAME. If the terminal is a text-only terminal then
also select the new frame."
(interactive (list (selected-frame) current-prefix-arg))
(let* ((frame (or frame (selected-frame)))
(windows (unless no-windows
(window-state-get (frame-root-window frame))))
(default-frame-alist
(seq-remove (lambda (elem)
(memq (car elem) frame-internal-parameters))
(frame-parameters frame)))
(new-frame))
(when (and (display-graphic-p frame)
(or pixelwise frame-resize-pixelwise))
(push (cons 'width (cons 'text-pixels (frame-text-width frame)))
default-frame-alist)
(push (cons 'height (cons 'text-pixels (frame-text-height frame)))
default-frame-alist))
(setq new-frame (make-frame))
(when windows
(window-state-put windows (frame-root-window new-frame) 'safe))
(unless (display-graphic-p frame)
(select-frame new-frame))
new-frame))
On Fri, Dec 13, 2024 at 5:30 AM martin rudalics <rudalics@gmx.at> wrote:
> > > That patch works to address make-frame's respect for text-pixels, at
> least
> > > on NS (the only platform I tested).
> >
> > I don't like it much and I have to further test the behavior with
> fringes.
> > Maybe I find better solution.
>
> I attach a patch that does away with a frame's inhibit_horizontal_resize
> and inhibit_vertical_resize slots. Please test it. If it works for
> you, I'll install it on master.
>
> martin
[-- Attachment #2: Type: text/html, Size: 5404 bytes --]
next prev parent reply other threads:[~2024-12-13 16:28 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 [this message]
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
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+1Hbr19zQTQRhN4uT4Z3acej+WuX5d3h+WhFUZXU_9Pd61Sg@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).