[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#34294: 27.0.50; flymake-start-on-save-buffer has no effect
From: |
Juri Linkov |
Subject: |
bug#34294: 27.0.50; flymake-start-on-save-buffer has no effect |
Date: |
Mon, 29 Apr 2019 23:15:09 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>> I expected everything displayed in the echo area to be preserved
>> in the *Messages* buffer because clicking on the echo area displays
>> the *Messages* buffer.
>
> At the time the echo area is displayed, every connection to where its
> text comes from may have been lost already. Currently, the only way
> to securely trace that relationship from Lisp is by using a separate
> minibuffer-only frame and setting 'resize-mini-frames' to some
> function. When that function gets called, the buffer of the root
> window of its frame argument is the buffer whose contents should be
> displayed in the mini window. See my attachment of
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33498#41
>
> for an example of how to call such a function.
>
> Maybe we should allow to set `resize-mini-windows' to a function which
> gets called to resize the mini window (or just allow Lisp code to look
> at its buffer and call some standard function afterwards).
>
> But always keep in mind that Emacs asks 'yes-or-no-p' questions in the
> minibuffer window and 'y-or-n-p' questions in the echo area and adjust
> your expectations accordingly ;-)
Glad to see you back :-) We needed your help in bug#33992
to use display-buffer-in-direction and fit-window-to-buffer
for xref-find-definitions. Is your code ready for pushing
to master? display-buffer-in-direction would be a nice
direction of development.