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