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

Previous Next

Package: emacs;

Reported by: Clemens <clemens.radermacher <at> posteo.de>

Date: Mon, 19 Oct 2020 18:40:02 UTC

Severity: normal

Found in version 27.1

Done: Clemens <clemens.radermacher <at> posteo.de>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44080 in the body.
You can then email your comments to 44080 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Mon, 19 Oct 2020 18:40:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clemens <clemens.radermacher <at> posteo.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 19 Oct 2020 18:40:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; Display behavior of overlays `after-string` in resizable
 minibuffer frames
Date: Mon, 19 Oct 2020 20:39:15 +0200
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))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Mon, 19 Oct 2020 19:44:02 GMT) Full text and rfc822 format available.

Message #8 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clemens <clemens.radermacher <at> posteo.de>, martin rudalics <rudalics <at> gmx.at>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1;
 Display behavior of overlays `after-string` in resizable minibuffer
 frames
Date: Mon, 19 Oct 2020 22:43:41 +0300
> From: Clemens <clemens.radermacher <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 20 Oct 2020 07:22:01 GMT) Full text and rfc822 format available.

Message #11 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Clemens <clemens.radermacher <at> posteo.de>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 20 Oct 2020 09:21:36 +0200
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 20 Oct 2020 09:28:02 GMT) Full text and rfc822 format available.

Message #14 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 20 Oct 2020 11:27:17 +0200
> 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.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 20 Oct 2020 14:41:02 GMT) Full text and rfc822 format available.

Message #17 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Clemens <clemens.radermacher <at> posteo.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 20 Oct 2020 16:40:00 +0200
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 20 Oct 2020 15:20:02 GMT) Full text and rfc822 format available.

Message #20 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 20 Oct 2020 17:19:22 +0200
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 20 Oct 2020 17:03:01 GMT) Full text and rfc822 format available.

Message #23 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 20 Oct 2020 19:02:00 +0200
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.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Wed, 21 Oct 2020 09:12:02 GMT) Full text and rfc822 format available.

Message #26 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Wed, 21 Oct 2020 11:11:34 +0200

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Wed, 21 Oct 2020 13:50:01 GMT) Full text and rfc822 format available.

Message #29 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Clemens <clemens.radermacher <at> posteo.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Wed, 21 Oct 2020 15:49:00 +0200
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Wed, 21 Oct 2020 14:14:02 GMT) Full text and rfc822 format available.

Message #32 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Wed, 21 Oct 2020 16:13:30 +0200
> 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!








Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Wed, 21 Oct 2020 15:01:01 GMT) Full text and rfc822 format available.

Message #35 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: clemens.radermacher <at> posteo.de, 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Wed, 21 Oct 2020 18:00:41 +0300
> Cc: 44080 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Wed, 21 Oct 2020 16:06:02 GMT) Full text and rfc822 format available.

Message #38 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Clemens <clemens.radermacher <at> posteo.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Wed, 21 Oct 2020 18:05:34 +0200
> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Wed, 21 Oct 2020 17:21:01 GMT) Full text and rfc822 format available.

Message #41 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Wed, 21 Oct 2020 19:20:05 +0200
>  > 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Wed, 21 Oct 2020 17:26:02 GMT) Full text and rfc822 format available.

Message #44 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Clemens <clemens.radermacher <at> posteo.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Wed, 21 Oct 2020 19:25:25 +0200
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Wed, 21 Oct 2020 19:46:01 GMT) Full text and rfc822 format available.

Message #47 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Clemens <clemens.radermacher <at> posteo.de>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Wed, 21 Oct 2020 22:45:11 +0300
Clemens <clemens.radermacher <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Thu, 22 Oct 2020 12:41:02 GMT) Full text and rfc822 format available.

Message #50 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Thu, 22 Oct 2020 14:39:55 +0200
[Message part 1 (text/plain, inline)]
> 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!
[mini-frame.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Thu, 22 Oct 2020 16:27:03 GMT) Full text and rfc822 format available.

Message #53 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Clemens <clemens.radermacher <at> posteo.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Thu, 22 Oct 2020 18:26:51 +0200
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Sat, 24 Oct 2020 13:09:02 GMT) Full text and rfc822 format available.

Message #56 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Sat, 24 Oct 2020 15:08:19 +0200
[Message part 1 (text/plain, inline)]
> 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 :)
[0001-Don-t-skip-empty-lines-when-fitting-mini-frame-to-bu.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Sat, 24 Oct 2020 13:41:02 GMT) Full text and rfc822 format available.

Message #59 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Clemens <clemens.radermacher <at> posteo.de>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Sat, 24 Oct 2020 15:39:56 +0200
>>>>> On Sat, 24 Oct 2020 15:08:19 +0200, Clemens <clemens.radermacher <at> 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
-- 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Mon, 26 Oct 2020 18:25:01 GMT) Full text and rfc822 format available.

Message #62 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Clemens <clemens.radermacher <at> posteo.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Mon, 26 Oct 2020 19:24:00 +0100
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Mon, 26 Oct 2020 18:33:02 GMT) Full text and rfc822 format available.

Message #65 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: clemens.radermacher <at> posteo.de, 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Mon, 26 Oct 2020 20:32:09 +0200
> Cc: 44080 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Mon, 26 Oct 2020 20:54:01 GMT) Full text and rfc822 format available.

Message #68 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Mon, 26 Oct 2020 21:53:13 +0100
> - 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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 27 Oct 2020 09:09:01 GMT) Full text and rfc822 format available.

Message #71 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Clemens <clemens.radermacher <at> posteo.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 27 Oct 2020 10:08:29 +0100
>> - 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 27 Oct 2020 12:11:02 GMT) Full text and rfc822 format available.

Message #74 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 27 Oct 2020 13:10:30 +0100
[Message part 1 (text/plain, inline)]
> 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!
[news.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 27 Oct 2020 18:03:01 GMT) Full text and rfc822 format available.

Message #77 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Clemens <clemens.radermacher <at> posteo.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 27 Oct 2020 19:02:33 +0100
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 27 Oct 2020 18:16:02 GMT) Full text and rfc822 format available.

Message #80 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 27 Oct 2020 19:15:31 +0100
> The process is described here: (info "(elisp) Writing Emacs Primitives")
> (or C-h i m elisp RET i defining custom RET)

Thanks!




Reply sent to Clemens <clemens.radermacher <at> posteo.de>:
You have taken responsibility. (Tue, 27 Oct 2020 18:24:01 GMT) Full text and rfc822 format available.

Notification sent to Clemens <clemens.radermacher <at> posteo.de>:
bug acknowledged by developer. (Tue, 27 Oct 2020 18:24:01 GMT) Full text and rfc822 format available.

Message #85 received at 44080-done <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: 44080-done <at> debbugs.gnu.org
Subject: Fixed for Emacs 27.2
Date: Tue, 27 Oct 2020 19:23:33 +0100



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44080; Package emacs. (Tue, 27 Oct 2020 18:30:02 GMT) Full text and rfc822 format available.

Message #88 received at 44080 <at> debbugs.gnu.org (full text, mbox):

From: Clemens <clemens.radermacher <at> posteo.de>
To: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44080 <at> debbugs.gnu.org
Subject: Re: bug#44080: 27.1; Display behavior of overlays `after-string` in
 resizable minibuffer frames
Date: Tue, 27 Oct 2020 19:29:50 +0100
> Pushed now.
> 
> Thanks, martin


Thanks!




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 25 Nov 2020 12:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 124 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.