bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

Hi,

there seems to be display bug when using `after-string` to display text 
in resizable minibuffer frames. To reproduce:

1. `emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"`
2. `eval-buffer` with following code:

```elisp
(setq resize-mini-frames t)

(defvar ov (make-overlay (point-min) (point-min) nil t t))

(minibuffer-with-setup-hook
     (lambda ()
       (move-overlay ov
		    (point-max)
		    (point-max)
		    (current-buffer))
        ;; Note the initial newline...
       (overlay-put ov 'after-string "\nHey there, I'm hidden initially 
and will hide again after any space in the input"))
   (read-string "Hi? "))
```

3. Start typing

As stated in the after-string text, it is initially hidden, shows when 
you input some text and gets hidden again every time you type a space.

--

In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, 
cairo version 1.15.10)
  of 2020-08-20 built on clemera
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.5 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item

Configured using:
  'configure --with-modules --with-json --with-cairo'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2
GMP

Important settings:
   value of $LC_MONETARY: de_DE.UTF-8
   value of $LC_NUMERIC: de_DE.UTF-8
   value of $LC_TIME: de_DE.UTF-8
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 43837 7270)
  (symbols 48 6003 1)
  (strings 32 15436 1428)
  (string-bytes 1 506267)
  (vectors 16 9260)
  (vector-slots 8 124508 9186)
  (floats 8 19 43)
  (intervals 56 184 0)
  (buffers 1000 11))

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Eli Zaretskii]

> From: Clemens <clemens.radermacher@posteo.de>
> Date: Mon, 19 Oct 2020 20:39:15 +0200
> 
> 1. `emacs -Q --eval "(setq default-frame-alist '((minibuffer . nil)))"`
> 2. `eval-buffer` with following code:
> 
> ```elisp
> (setq resize-mini-frames t)
> 
> (defvar ov (make-overlay (point-min) (point-min) nil t t))
> 
> (minibuffer-with-setup-hook
>      (lambda ()
>        (move-overlay ov
> 		    (point-max)
> 		    (point-max)
> 		    (current-buffer))
>         ;; Note the initial newline...
>        (overlay-put ov 'after-string "\nHey there, I'm hidden initially 
> and will hide again after any space in the input"))
>    (read-string "Hi? "))
> ```
> 
> 3. Start typing
> 
> As stated in the after-string text, it is initially hidden, shows when 
> you input some text and gets hidden again every time you type a space.

It looks like the problem is in fit-frame-to-buffer: it is not
prepared to handle after-string at the end of the prompt.
Specifically, the fact that the 2nd and the 3rd args of the call to
window-text-pixel-size are both t causes the function to return the
value which doesn't account for the after-string.

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 > It looks like the problem is in fit-frame-to-buffer: it is not
 > prepared to handle after-string at the end of the prompt.
 > Specifically, the fact that the 2nd and the 3rd args of the call to
 > window-text-pixel-size are both t causes the function to return the
 > value which doesn't account for the after-string.

Indeed.  'fit-frame-to-buffer' strips empty spaces at the beginning and
end of the buffer - it's aim is to make the frame occupy as little of
screen space as possible.  If 'resize-mini-frames' should handle
peculiarities as such display strings, it's probably better to write a
tailored function that handles them by calling 'window-text-pixel-size'
with the appropriate arguments.

But we can change the default behavior as well, or provide an appropriate
option.

martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

> Indeed.  'fit-frame-to-buffer' strips empty spaces at the beginning and
> end of the buffer - it's aim is to make the frame occupy as little of
> screen space as possible.  If 'resize-mini-frames' should handle
> peculiarities as such display strings, it's probably better to write a
> tailored function that handles them by calling 'window-text-pixel-size'
> with the appropriate arguments.
> 
> But we can change the default behavior as well, or provide an appropriate
> option.


To give some context, the current behavior is a problem for completion 
frameworks which want to display a vertical list of candidates in the 
minibuffer. They need to use an overlay so the candidates aren't 
considered part of the minibuffer-contents which is expected to only 
contain the current user input.

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 > To give some context, the current behavior is a problem for completion
 > frameworks which want to display a vertical list of candidates in the
 > minibuffer. They need to use an overlay so the candidates aren't
 > considered part of the minibuffer-contents which is expected to only
 > contain the current user input.

I've never used such completion frameworks and thus I've not seen this
problem so far.  Yet I'm using a separate minibuffer child frame which I
resize by calling 'window-text-pixel-size' with both, second and third
argument, nil.

We could do the same in 'fit-frame-to-buffer' but this would be an
incompatible change for the latter.  Can you nevertheless try running
with such a change so we can tell whether it fixes the problem?  If it
does fix it, we can either provide a separate 'fit-mini-frame-to-buffer'
function or a further option to set the function 'fit-frame-to-buffer'
calls to get the size of the frame's root window.

martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

> We could do the same in 'fit-frame-to-buffer' but this would be an
> incompatible change for the latter.  Can you nevertheless try running
> with such a change so we can tell whether it fixes the problem?  If it
> does fix it, we can either provide a separate 'fit-mini-frame-to-buffer'
> function or a further option to set the function 'fit-frame-to-buffer'
> calls to get the size of the frame's root window.


Setting the third argument of `window-text-pixel-size` to `nil` fixes 
it. Thank you both for the quick response and your help finding the 
cause of this! Having a size function sounds good to me, ideally it 
would already default to avoid skipping whitespace in minibuffers if 
your think that is reasonable.

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

On the other hand if you think it is reasonable to do this in minibuffer 
frames by default you could also change the current behavior in place to 
avoid adding another option. I can't imagine a scenario this would break 
some other use case but who knows...For now I will recommend users to 
use the following workaround:

(define-advice fit-frame-to-buffer (:around (f &rest args) 
dont-skip-ws-for-mini-frame)
   (cl-letf (((symbol-function #'window-text-pixel-size)
              (lambda (win from to &rest args)
                (apply #'window-text-pixel-size
                       (append (list win from (if (and 
(window-minibuffer-p win) (eq t to)) nil to) args))))))
     (apply f args)))


BTW, the completion frameworks I was referring to are called selectrum 
and icomplete-vertical in case you were interested.

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

On 20.10.20 19:02, Clemens wrote:
> For now I will recommend users to 
> use the following workaround:
> 
> (define-advice fit-frame-to-buffer (:around (f &rest args) 
> dont-skip-ws-for-mini-frame)
>    (cl-letf (((symbol-function #'window-text-pixel-size)
>               (lambda (win from to &rest args)
>                 (apply #'window-text-pixel-size
>                        (append (list win from (if (and 
> (window-minibuffer-p win) (eq t to)) nil to) args))))))
>      (apply f args)))
> 

The version above invokes infinite recursion so I would rather recommend
something like the following for affected users (to avoid spamming this 
bug report with other versions here is the link to the corresponding 
issue on selectrums side: https://github.com/raxod502/selectrum/issues/169

(define-advice fit-frame-to-buffer (:around (f &rest args) 
dont-skip-ws-for-mini-frame)
   (cl-letf* ((orig (symbol-function #'window-text-pixel-size))
             ((symbol-function #'window-text-pixel-size)
              (lambda (win from to &rest args)
                (apply orig
                       (append (list win from
                                     (if (and (window-minibuffer-p win)
                                              (frame-root-window-p win)
                                              (eq t to))
                                         nil
                                       to)
                                     args))))))
     (apply f args)))

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 > The version above invokes infinite recursion so I would rather recommend
 > something like the following for affected users ...

IMO advices are much too complicated to handle this issue.  I'd proceed
in the traditional way:

(1) Rename 'fit-frame-to-buffer' to say 'fit-frame-to-buffer-1' and give
that function two new arguments FROM and TO.  In its
'window-text-pixel-size' call, replace the "t t" with "from to".

(2) Provide a new function 'fit-frame-to-buffer' with the same singature
as the old 'fit-frame-to-buffer' that calls `fit-frame-to-buffer-1' with
FROM and TO t.

(3) Provide a new function 'fit-mini-frame-to-buffer' that calls
'fit-frame-to-buffer-1' with FROM and TO nil.  Offer that function as
first choice when customizing 'resize-mini-frames' and call it in
'window--resize-mini-frame' when 'resize-mini-frames' is nil.

If 'fit-frame-to-buffer' has additional defects when used for resizing
mini frames, we could try to fix them in 'fit-mini-frame-to-buffer' as
well.  WDYT?

martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

> IMO advices are much too complicated to handle this issue.  I'd proceed
> in the traditional way:

Oh I did not mean to propose that as a solution on the Emacs side, sorry 
if that wasn't clear. It was meant as a temporary workaround for 
affected users before an official solution lands.

> (1) Rename 'fit-frame-to-buffer' to say 'fit-frame-to-buffer-1' and give
> that function two new arguments FROM and TO.  In its
> 'window-text-pixel-size' call, replace the "t t" with "from to".
> 
> (2) Provide a new function 'fit-frame-to-buffer' with the same singature
> as the old 'fit-frame-to-buffer' that calls `fit-frame-to-buffer-1' with
> FROM and TO t.
> 
> (3) Provide a new function 'fit-mini-frame-to-buffer' that calls
> 'fit-frame-to-buffer-1' with FROM and TO nil.  Offer that function as
> first choice when customizing 'resize-mini-frames' and call it in
> 'window--resize-mini-frame' when 'resize-mini-frames' is nil.

I did not know `resize-mini-frames` is already allowed to be a function, 
I don't use that feature at all so I'm a bit clueless about possible 
settings. It doesn't look like `window--resize-mini-frame` is called 
anywhere? Is that function meant for users?

> If 'fit-frame-to-buffer' has additional defects when used for resizing
> mini frames, we could try to fix them in 'fit-mini-frame-to-buffer' as
> well.  WDYT?

Sounds like a good approach to me. Thanks for thinking it through!

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 > I did not know `resize-mini-frames` is already allowed to be a
 > function, I don't use that feature at all so I'm a bit clueless about
 > possible settings. It doesn't look like `window--resize-mini-frame` is
 > called anywhere? Is that function meant for users?

Yes.  For example with my Emacs 27 it's documented as


resize-mini-frames is a variable defined in ‘C source code’.
Its value is ‘pop-up-mini-resize-mini-frame’
Original value was nil

   You can customize this variable.


This variable was introduced, or its default value was changed, in
version 27.1 of Emacs.

Documentation:
Non-nil means resize minibuffer-only frames automatically.
If this is nil, do not resize minibuffer-only frames automatically.

If this is a function, call that function with the minibuffer-only
frame that shall be resized as sole argument.  The buffer of the root
window of that frame is the buffer whose text will be eventually shown
in the minibuffer window.

Any other non-nil value means to resize minibuffer-only frames by
calling ‘fit-frame-to-buffer’.

 >> If 'fit-frame-to-buffer' has additional defects when used for resizing
 >> mini frames, we could try to fix them in 'fit-mini-frame-to-buffer' as
 >> well.  WDYT?
 >
 > Sounds like a good approach to me. Thanks for thinking it through!

Could you try coding it?  It's straightforward and you could test it
immediately and possibly discuss it with the 'mini-frame-mode' people.

Thanks, martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

>  > I did not know `resize-mini-frames` is already allowed to be a
>  > function, I don't use that feature at all so I'm a bit clueless about
>  > possible settings. It doesn't look like `window--resize-mini-frame` is
>  > called anywhere? Is that function meant for users?
> 
> Yes.  For example with my Emacs 27 it's documented as

I was referring to the `window--resize-mini-frame` which I couldn't find
any calls for.

> Could you try coding it?  It's straightforward and you could test it
> immediately and possibly discuss it with the 'mini-frame-mode' people.

I can do it but I'm not so familiar with the Emacs development workflow 
myself. In this case I would clone the latest Emacs and then export my 
changes as a patch and send them here right?

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 > I was referring to the `window--resize-mini-frame` which I couldn't find
 > any calls for.

It's called from xdisp.c as


   if (FRAME_MINIBUF_ONLY_P (f))
     {
       if (!NILP (resize_mini_frames))
	safe_call1 (Qwindow__resize_mini_frame, WINDOW_FRAME (w));
     }


which represents one of our ways to call a Lisp function from C.

 > I can do it but I'm not so familiar with the Emacs development
 > workflow myself. In this case I would clone the latest Emacs and then
 > export my changes as a patch and send them here right?

Right.  And if you have any questions, ask here immediately.

martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

> It's called from xdisp.c as
> 
> 
>    if (FRAME_MINIBUF_ONLY_P (f))
>      {
>        if (!NILP (resize_mini_frames))
>      safe_call1 (Qwindow__resize_mini_frame, WINDOW_FRAME (w));
>      }
> 
> 
> which represents one of our ways to call a Lisp function from C.

Thanks, for some reason `debug-on-entry` did not invoke the debugger
when I tested it.

> Right.  And if you have any questions, ask here immediately.

I never dealt with the C side of Emacs and you suggested to offer the 
new function as first customization choice for `resize-mini-frames`.
I guess this needs to be done on the C side as the variable is defined 
there?

I have attached the patch I have worked on. Let me know how to proceed 
and thanks for your help!

[-- Attachment #2: mini-frame.patch --]
[-- Type: text/x-patch, Size: 2530 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index 1fcfffcb53..b7d4b4d26f 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -3432,7 +3432,7 @@ (defun window--resize-mini-frame (frame)
   "Resize minibuffer-only frame FRAME."
   (if (functionp resize-mini-frames)
       (funcall resize-mini-frames frame)
-    (fit-frame-to-buffer frame)))
+    (fit-mini-frame-to-buffer frame)))
 
 (defun window--sanitize-window-sizes (horizontal)
   "Assert that all windows on selected frame are large enough.
@@ -8925,8 +8925,17 @@ (defun window--sanitize-margin (margin left right)
 
 (declare-function tool-bar-height "xdisp.c" (&optional frame pixelwise))
 
+(defun fit-mini-frame-to-buffer (frame)
+  "Adjust size of minibuffer FRAME to display its contents.
+Unlike `fit-frame-to-buffer' FRAME will fit to the contents with
+any leading or trailing empty lines included."
+  (fit-frame-to-buffer-1 frame))
+
 (defun fit-frame-to-buffer (&optional frame max-height min-height max-width min-width only)
   "Adjust size of FRAME to display the contents of its buffer exactly.
+Any leading or trailing empty lines of the buffers content are
+not considered.
+
 FRAME can be any live frame and defaults to the selected one.
 Fit only if FRAME's root window is live.
 
@@ -8945,6 +8954,12 @@ (defun fit-frame-to-buffer (&optional frame max-height min-height max-width min-
 `fit-frame-to-buffer-margins' or setting the corresponding
 parameters of FRAME."
   (interactive)
+  (fit-frame-to-buffer-1 frame max-height min-height max-width min-width only t t))
+
+(defun fit-frame-to-buffer-1 (&optional frame max-height min-height max-width min-width only from to)
+  "Helper function for `fit-frame-to-buffer'.
+FROM and TO are the buffer positions to determine the size to fit
+to, see `window-text-pixel-size'."
   (unless (fboundp 'display-monitor-attributes-list)
     (user-error "Cannot resize frame in non-graphic Emacs"))
   (setq frame (window-normalize-frame frame))
@@ -9079,7 +9094,7 @@ (defun fit-frame-to-buffer (&optional frame max-height min-height max-width min-
            ;; Note: Currently, for a new frame the sizes of the header
            ;; and mode line may be estimated incorrectly
            (size
-            (window-text-pixel-size window t t max-width max-height))
+            (window-text-pixel-size window from to max-width max-height))
            (width (max (car size) min-width))
            (height (max (cdr size) min-height)))
       ;; Don't change height or width when the window's size is fixed

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 > I never dealt with the C side of Emacs and you suggested to offer the
 > new function as first customization choice for `resize-mini-frames`.
 > I guess this needs to be done on the C side as the variable is defined
 > there?

The customization is done here in cus-start.el

              (resize-mini-frames
               frames (choice
                       (const :tag "Never" nil)
                       (const :tag "Fit frame to buffer" t)
                       (function :tag "User-defined function"))
                "27.1")

and the only things to change are to put a "mini" between "Fit" and
"frame" and update the tag to hmmm ... I meanwhile think we should put
that change into Emacs 27.2 provided Eli doesn't object.

And the only C-side change is to change the doc-string of
'resize-mini-frames' (in frame.c) where we say

Any other non-nil value means to resize minibuffer-only frames by
calling `fit-frame-to-buffer'.  */);

to

Any other non-nil value means to resize minibuffer-only frames by
calling `fit-mini-frame-to-buffer'.  */);

 > I have attached the patch I have worked on. Let me know how to proceed
 > and thanks for your help!

The patch looks fine to me.  I'd change the following:

(1) Make the FRAME argument of 'fit-mini-frame-to-buffer' optional so we
     retain a certain consistency wrt 'fit-frame-to-buffer'.

(2) The "Any leading or trailing empty lines of the buffers content are
     not considered." should be moved towards the end of its doc-string
     or at least after the "FRAME can be any live frame and defaults to
     the selected one."

(3) The doc-string of 'fit-frame-to-buffer-1' should be amended with
     something like

     "The remaining arguments are as for `fit-frame-to-buffer'.

In the Elisp manual in the description of 'resize-mini-frames' we should
replace the

Any other non-@code{nil} value means to resize minibuffer-only frames
by calling @code{fit-frame-to-buffer} (@pxref{Resizing Windows}).

with something like

Any other non-@code{nil} value means to resize minibuffer-only frames by
calling @code{fit-mini-frame-to-buffer}, a function that behaves like
@code{fit-frame-to-buffer} (@pxref{Resizing Windows}) but does not strip
leading or trailing empty lines from the buffer text.

In addition we need to call out the change in NEWS and write a
ChangeLog entry.

Many thanks, martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

 > The customization is done here in cus-start.el
 >
 >               (resize-mini-frames
 >                frames (choice
 >                        (const :tag "Never" nil)
 >                        (const :tag "Fit frame to buffer" t)
 >                        (function :tag "User-defined function"))
 >                 "27.1")


Thanks, now I know how that is done, I should have grepped for it.

I have attached an updated patch where I implemented your suggestions.
For now I updated the tag to 27.2. Let me know if anything else could be 
improved and thanks for giving me the opportunity to contribute a little 
to my favorite software :)

[-- Attachment #2: 0001-Don-t-skip-empty-lines-when-fitting-mini-frame-to-bu.patch --]
[-- Type: text/x-patch, Size: 6219 bytes --]

From fa40d19d2eb6339a30d396e51201781fc8a639ca Mon Sep 17 00:00:00 2001
From: Clemens Radermacher <clemens.radermacher@posteo.de>
Date: Sat, 24 Oct 2020 14:49:45 +0200
Subject: [PATCH] Don't skip empty lines when fitting mini frame to buffer
 (bug#44080)

* lisp/window.el: (fit-mini-frame-to-buffer,
window--resize-mini-frame, fit-frame-to-buffer,
fit-frame-to-buffer-1): Fit to mini frames without skipping leading or
trailing empty lines.
* src/frame.c: (resize-mini-frames): Update docstring.
* lisp/cus-start.el: Update for customize.
* doc/lispref/minibuf.texi: (resize-mini-frames) Update description.
---
 doc/lispref/minibuf.texi |  6 ++++--
 etc/NEWS                 |  6 ++++++
 lisp/cus-start.el        |  4 ++--
 lisp/window.el           | 24 +++++++++++++++++++++---
 src/frame.c              |  2 +-
 5 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index d00acd0ded..e5a0233b3c 100644
--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -2501,8 +2501,10 @@ frame is the buffer whose contents will be shown the next time that
 window is redisplayed.  The function is expected to fit the frame to
 the buffer in some appropriate way.
 
-Any other non-@code{nil} value means to resize minibuffer-only frames
-by calling @code{fit-frame-to-buffer} (@pxref{Resizing Windows}).
+Any other non-@code{nil} value means to resize minibuffer-only frames by
+calling @code{fit-mini-frame-to-buffer}, a function that behaves like
+@code{fit-frame-to-buffer} (@pxref{Resizing Windows}) but does not strip
+leading or trailing empty lines from the buffer text.
 @end defopt
 
 
diff --git a/etc/NEWS b/etc/NEWS
index 2aed575159..861ce6ff6f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -274,6 +274,12 @@ of the next command to be displayed in a new window.
 It's bound to the command 'other-frame-prefix' that requests the buffer
 of the next command to be displayed in a new frame.
 
++++
+*** Change behavior of user option 'resize-mini-frames'.
+If set to non-nil resize the mini frame using the new function
+'fit-mini-frame-to-buffer' which won't skip leading or trailing empty
+lines of the buffer.
+
 ** Tab Bars
 
 *** The key prefix 'C-x t t' displays next command buffer in a new tab.
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 3fd6ac031c..6927b6df6b 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -324,9 +324,9 @@ (default-frame-alist frames
              (resize-mini-frames
               frames (choice
                       (const :tag "Never" nil)
-                      (const :tag "Fit frame to buffer" t)
+                      (const :tag "Fit mini frame to buffer" t)
                       (function :tag "User-defined function"))
-               "27.1")
+               "27.2")
              (menu-bar-mode frames boolean nil
 			    ;; FIXME?
                             ;; :initialize custom-initialize-default
diff --git a/lisp/window.el b/lisp/window.el
index 1fcfffcb53..865f6fdd5c 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -3432,7 +3432,7 @@ (defun window--resize-mini-frame (frame)
   "Resize minibuffer-only frame FRAME."
   (if (functionp resize-mini-frames)
       (funcall resize-mini-frames frame)
-    (fit-frame-to-buffer frame)))
+    (fit-mini-frame-to-buffer frame)))
 
 (defun window--sanitize-window-sizes (horizontal)
   "Assert that all windows on selected frame are large enough.
@@ -8925,6 +8925,14 @@ (defun window--sanitize-margin (margin left right)
 
 (declare-function tool-bar-height "xdisp.c" (&optional frame pixelwise))
 
+(defun fit-mini-frame-to-buffer (&optional frame)
+  "Adjust size of minibuffer FRAME to display its contents.
+FRAME should be a minibuffer-only frame and defaults to the
+selected one.  Unlike `fit-frame-to-buffer' FRAME will fit to the
+contents of its buffer with any leading or trailing empty lines
+included."
+  (fit-frame-to-buffer-1 frame))
+
 (defun fit-frame-to-buffer (&optional frame max-height min-height max-width min-width only)
   "Adjust size of FRAME to display the contents of its buffer exactly.
 FRAME can be any live frame and defaults to the selected one.
@@ -8943,8 +8951,18 @@ (defun fit-frame-to-buffer (&optional frame max-height min-height max-width min-
 The new position and size of FRAME can be additionally determined
 by customizing the options `fit-frame-to-buffer-sizes' and
 `fit-frame-to-buffer-margins' or setting the corresponding
-parameters of FRAME."
+parameters of FRAME.
+
+Any leading or trailing empty lines of the buffer content are not
+considered."
   (interactive)
+  (fit-frame-to-buffer-1 frame max-height min-height max-width min-width only t t))
+
+(defun fit-frame-to-buffer-1 (&optional frame max-height min-height max-width min-width only from to)
+  "Helper function for `fit-frame-to-buffer'.
+FROM and TO are the buffer positions to determine the size to fit
+to, see `window-text-pixel-size'.  The remaining arguments are as
+for `fit-frame-to-buffer'."
   (unless (fboundp 'display-monitor-attributes-list)
     (user-error "Cannot resize frame in non-graphic Emacs"))
   (setq frame (window-normalize-frame frame))
@@ -9079,7 +9097,7 @@ (defun fit-frame-to-buffer (&optional frame max-height min-height max-width min-
            ;; Note: Currently, for a new frame the sizes of the header
            ;; and mode line may be estimated incorrectly
            (size
-            (window-text-pixel-size window t t max-width max-height))
+            (window-text-pixel-size window from to max-width max-height))
            (width (max (car size) min-width))
            (height (max (cdr size) min-height)))
       ;; Don't change height or width when the window's size is fixed
diff --git a/src/frame.c b/src/frame.c
index 0b707c2af8..797d885d43 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -6182,7 +6182,7 @@ window of that frame is the buffer whose text will be eventually shown
 in the minibuffer window.
 
 Any other non-nil value means to resize minibuffer-only frames by
-calling `fit-frame-to-buffer'.  */);
+calling `fit-mini-frame-to-buffer'.  */);
   resize_mini_frames = Qnil;
 
   DEFVAR_LISP ("focus-follows-mouse", focus_follows_mouse,
-- 
2.17.1

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Robert Pluim]

>>>>> On Sat, 24 Oct 2020 15:08:19 +0200, Clemens <clemens.radermacher@posteo.de> said:

    >> The customization is done here in cus-start.el
    >> 
    >> (resize-mini-frames
    >> frames (choice
    >> (const :tag "Never" nil)
    >> (const :tag "Fit frame to buffer" t)
    >> (function :tag "User-defined function"))
    >> "27.1")


    Clemens> Thanks, now I know how that is done, I should have grepped for it.

The process is described here: (info "(elisp) Writing Emacs Primitives")
(or C-h i m elisp RET i defining custom RET)

Robert
-- 

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

> The process is described here: (info "(elisp) Writing Emacs Primitives")
> (or C-h i m elisp RET i defining custom RET)

Thanks!

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 > For now I updated the tag to 27.2. Let me know if anything else could
 > be improved and thanks for giving me the opportunity to contribute a
 > little to my favorite software :)

I think it's good to be installed now.  Eli, two questions:

- Is it OK to install this on Emacs 27?  I don't know how popular these
   minibuffers with leading or trailing overlays become, but if they do,
   it might be good to be prepared.

- Can we accept Clemens' patch without paperwork?  Many of its parts are
   slightly amended doc-strings.

Thanks, martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Eli Zaretskii]

> Cc: 44080@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 26 Oct 2020 19:24:00 +0100
> 
> I think it's good to be installed now.  Eli, two questions:
> 
> - Is it OK to install this on Emacs 27?  I don't know how popular these
>    minibuffers with leading or trailing overlays become, but if they do,
>    it might be good to be prepared.
> 
> - Can we accept Clemens' patch without paperwork?  Many of its parts are
>    slightly amended doc-strings.

Yes to both questions.

Thanks.

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

> - Can we accept Clemens' patch without paperwork?  Many of its parts are
>    slightly amended doc-strings.

I have done the paperwork already so this is nothing to worry about.

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 >> - Can we accept Clemens' patch without paperwork?  Many of its parts are
 >>    slightly amended doc-strings.
 >
 > I have done the paperwork already so this is nothing to worry about.

Fine.  I've pushed your changes now as commit
e0de9f3295b4c46cb7198ec0b9634809d7b7a36d.  Please have a look and close
the bug if everything is OK.

Thanks, martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

> Fine.  I've pushed your changes now as commit
> e0de9f3295b4c46cb7198ec0b9634809d7b7a36d.  Please have a look and close
> the bug if everything is OK.


Looks good to me except the NEWS entry which on second look wasn't 
precise enough. I have attached a patch which aims to fix it. Thanks for 
all your help!

[-- Attachment #2: news.patch --]
[-- Type: text/x-patch, Size: 728 bytes --]

diff --git a/etc/NEWS b/etc/NEWS
index f0b5dd088a..61f9c0e1fe 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -35,10 +35,10 @@ This is a bug-fix release with no new features.
 \f
 * Lisp Changes in Emacs 27.2
 
-*** The behavior of the user option 'resize-mini-frames' has changed.
-If set to non-nil, resize the mini frame using the new function
-'fit-mini-frame-to-buffer' which won't skip leading or trailing empty
-lines of the buffer.
+** The behavior of the user option 'resize-mini-frames' has changed.
+If set to a non-nil value which isn't a function, resize the mini
+frame using the new function 'fit-mini-frame-to-buffer' which won't
+skip leading or trailing empty lines of the buffer.
 
 \f
 * Editing Changes in Emacs 27.2

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[martin rudalics]

 > Looks good to me except the NEWS entry which on second look wasn't precise enough. I have attached a patch which aims to fix it. Thanks for all your help!

Pushed now.

Thanks, martin

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Clemens]

> Pushed now.
> 
> Thanks, martin


Thanks!

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Andrii Kolomoiets]

Clemens <clemens.radermacher@posteo.de> writes:

>>  > I did not know `resize-mini-frames` is already allowed to be a
>>  > function, I don't use that feature at all so I'm a bit clueless about
>>  > possible settings. It doesn't look like `window--resize-mini-frame` is
>>  > called anywhere? Is that function meant for users?
>> Yes.  For example with my Emacs 27 it's documented as
>
> I was referring to the `window--resize-mini-frame` which I couldn't find
> any calls for.
>
>> Could you try coding it?  It's straightforward and you could test it
>> immediately and possibly discuss it with the 'mini-frame-mode' people.
>
> I can do it but I'm not so familiar with the Emacs development
> workflow myself. In this case I would clone the latest Emacs and then
> export my changes as a patch and send them here right?

Clemens, if you'll keep the name 'fit-mini-frame-to-buffer' for the new
function, I (as the 'mini-frame-mode' people :)) can replace the call to
'fit-frame-to-buffer' with it in the 'mini-frame-mode' right now.  So
you'll be able to test the new function once you implement it.

bug#44080: 27.1; Display behavior of overlays `after-string` in resizable minibuffer frames

[Eli Zaretskii]

> Cc: 44080@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 21 Oct 2020 15:49:00 +0200
> 
> (1) Rename 'fit-frame-to-buffer' to say 'fit-frame-to-buffer-1' and give
> that function two new arguments FROM and TO.  In its
> 'window-text-pixel-size' call, replace the "t t" with "from to".
> 
> (2) Provide a new function 'fit-frame-to-buffer' with the same singature
> as the old 'fit-frame-to-buffer' that calls `fit-frame-to-buffer-1' with
> FROM and TO t.
> 
> (3) Provide a new function 'fit-mini-frame-to-buffer' that calls
> 'fit-frame-to-buffer-1' with FROM and TO nil.  Offer that function as
> first choice when customizing 'resize-mini-frames' and call it in
> 'window--resize-mini-frame' when 'resize-mini-frames' is nil.
> 
> If 'fit-frame-to-buffer' has additional defects when used for resizing
> mini frames, we could try to fix them in 'fit-mini-frame-to-buffer' as
> well.  WDYT?

SGTM, if this fixes the original problem (as I think it will).

Thanks.

bug#44080: Fixed for Emacs 27.2

[Clemens]