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