Option not to truncate to narrowest window #170
-
|
My expectation was for marginalia to use the entire width of the minibuffer, but I see that function becomes If you want me to go through the PR process for this, that's not a problem, just tell me what you want the |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 3 replies
-
|
Marginalia takes the full minibuffer width into account. For most completion UIs the minibuffer is only displayed in the miniwindow, and as such the loop already returns the entire minibuffer width. Note that the code does not truncate to the narrowest window. It truncates to the narrowest window displaying the minibuffer. The comment also explains that we can generalize this to other UIs. I wouldn't want to add an option, but maybe auto-detect other UIs. Which UI do you use where the computation is not correct as is? EDIT: Clarified comment in ea356eb. |
Beta Was this translation helpful? Give feedback.
-
|
I generally run Emacs full screen on a wide-screen desktop monitor and
split the Emacs frame in half (M-x split-window-right "C-x 3"). What
I've been getting is candidate descriptions truncated to less than half
the Emacs frame.
For me, the change to function 'marginalia--affixate' helps for
use-cases such as '{,counsel-}'describe-function'. For functions such as
'{,ivy-}switch-buffer', it helps to replace function
'marginalia--truncate' with
(defun marginalia--truncate (str width)
(if (string-match "\n" str)
(substring str 0 (match-beginning 0))
str))
…On 2024-01-04 22:55, Daniel Mendler wrote:
Marginalia takes the full minibuffer width into account. For most
completion UIs the minibuffer is only displayed in the miniwindow, and
as such the loop already returns the entire minibuffer width. Note that
the code does not truncate to the narrowest window. It truncates to the
narrowest window displaying the minibuffer. The comment also explains
that we can generalize this to other UIs. Which UI do you use where the
computation is not correct as is?
—
Reply to this email directly, [1]view it on GitHub, or [2]unsubscribe.
You are receiving this because you authored the thread. Message ID:
***@***.***>
References
1. #170 (comment)
2. https://github.com/notifications/unsubscribe-auth/AAOE3KEDV2COKKNNOSV74ITYM6PXJAVCNFSM6AAAAABBN762ZGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAMRQGEYTA
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
|
Beta Was this translation helpful? Give feedback.
-
This is a little bit odd. If the affixation function is executed in the minibuffer, both width computations should yield the same result:
Can you please print the return values of |
Beta Was this translation helpful? Give feedback.
-
|
Sure. I added the following lines to function 'marginalia--affixate'.
(message "debug: window-width: %s" window-width)
(message "debug: current-buffer: %s" (current-buffer))
(message "debug: selected-window: %s" (selected-window))
(message "debug: get-buffer-window-list): %s" (get-buffer-window-list))
The output, upon performing 'M-x C-g C-g':
Evaluating...
marginalia--affixate
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
debug: window-width: 197
debug: current-buffer: marginalia.el
debug: selected-window: #<window 476 on *Minibuf-1*>
debug: get-buffer-window-list): (#<window 1217 on marginalia.el>)
I then also did a manual test. My procedure was to first type 'M-x' in order
to open and select focus into the minibuffer, then within the minibuffer
I type 'M-:' so that would perform an evaluation with the minibuffer
current. I read my results from the messages buffer.
window-width => 197
(current-buffer) => #<buffer *Minibuf-1*>
(selected-window) => #<window 476 on *Minibuf-1*>
(get-buffer-window-list) => (#<window 476 on *Minibuf-1*>)
…On 2024-01-05 04:18, Daniel Mendler wrote:
For me, the change to function 'marginalia--affixate' helps for
use-cases such as '{,counsel-}'describe-function'. For functions
such as
'{,ivy-}switch-buffer', it helps to replace function
'marginalia--truncate' with
This is a little bit odd. If the affixation function is executed in the
minibuffer, both width computations should yield the same result:
1. (cl-loop for win in (get-buffer-window-list) minimize (window-width
win))
2. (window-width)
Can you please print the return values of (current-buffer),
(selected-window) and (get-buffer-window-list) in marginalia--affixate?
—
Reply to this email directly, [1]view it on GitHub, or [2]unsubscribe.
You are receiving this because you authored the thread. Message ID:
***@***.***>
References
1. #170 (reply in thread)
2. https://github.com/notifications/unsubscribe-auth/AAOE3KDVVCBNOJ4ASS27F63YM7VTBAVCNFSM6AAAAABBN762ZGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAMRSGYZDO
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks. It seems that Ivy executes the affixation function inside the originally selected buffer and not the minibuffer unlike all the other completion UIs. Please open an issue on the Ivy issue tracker. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, but no. That would be asking them to make an architecture change
just to accomodate your add-on, when you would need to make only one or
two very minor additions in order to be compatible with them.
…On 2024-01-05 04:57, Daniel Mendler wrote:
Thanks. It seems that Ivy executes the affixation function inside the
originally selected buffer and not the minibuffer, like all the other
completion UIs. Please open an issue on the Ivy issue tracker.
—
Reply to this email directly, [1]view it on GitHub, or [2]unsubscribe.
You are receiving this because you authored the thread. Message ID:
***@***.***>
References
1. #170 (reply in thread)
2. https://github.com/notifications/unsubscribe-auth/AAOE3KCOOPYQVZZ6H35UDHLYM72FPAVCNFSM6AAAAABBN762ZGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAMRSHE3DE
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
|
Beta Was this translation helpful? Give feedback.
-
|
This is not only about this package, it is about using the completion APIs coherently, like other UIs do. The reference implementation is the default completion UI. Ivy already had to be changed, since Ivy didn't have full support for the annotation/affixation function for a long time. See abo-abo/swiper#2780. |
Beta Was this translation helpful? Give feedback.
Thanks. It seems that Ivy executes the affixation function inside the originally selected buffer and not the minibuffer unlike all the other completion UIs. Please open an issue on the Ivy issue tracker.