search

minad / marginalia

:scroll: marginalia.el - Marginalia in the minibuffer
GNU General Public License v3.0
780 stars 27 forks source link

wrapping problem #142

Closed svictor9 closed 2 years ago

svictor9 commented 2 years ago

I use marginalia with icomplete-vertical-mode (the one built into Emacs 29)

(icomplete-mode 1) 
(icomplete-vertical-mode)
(marginalia-mode 1)

The results of, say, describe-variable sometimes wrap at the window edge. I would like to understand why, and to get rid of that wrapping if possible. What is weird is that the wrapping doesn't depend on the window size. I attach two outputs of describe-variable.

With the input "mar", it doesn't wrap Screenshot_2022-06-10_11-27-46

With the input "marg", it wraps Screenshot_2022-06-10_11-28-10

Why is that? How could I get rid of the wrapping in the second case?

minad commented 2 years ago

My recommendation is to adjust truncate-lines:

(add-hook 'icomplete-minibuffer-setup-hook
          (lambda () (setq truncate-lines t)))
minad commented 2 years ago

As an alternative one could also right trim annotations if marginalia-align=left.

(advice-add #'marginalia--align :filter-return #'marginalia-trim-right)
(defun marginalia-trim-right (list)
  (cl-loop for (cand prefix suffix) in list collect
           (list cand prefix (string-trim-right suffix))))

Marginalia doesn't do this currently, it formats all annotations to a fixed width and pads with whitespace.

svictor9 commented 2 years ago

Thanks! Both methods solve the problem when the emacs window is maximized. However, only the first one seems to work when the window is smaller than maximum (tested at 71 cols)

Another problem is that once the padding is enlarged it doesn't shrink back. Consider the two screenshots in the first post: with the input "marg" the padding is increased, compared to "mar". I suppose that this is normal behavior and has to do with the collected results. But if I then delete the last "g", I would expect the padding to be smaller again. In effect, the large padding remains, and the results are still truncated. I can live with that of course, but I'm not sure it's normal behavior.

minad commented 2 years ago

Thanks! Both methods solve the problem when the emacs window is maximized. However, only the first one seems to work when the window is smaller than maximum (tested at 71 cols)

Sure. The second method does not truncate the line, so you will still get wrapping, but not because of the whitespace padding.

Another problem is that once the padding is enlarged it doesn't shrink back. Consider the two screenshots in the first post: with the input "marg" the padding is increased, compared to "mar". I suppose that this is normal behavior and has to do with the collected results. But if I then delete the last "g", I would expect the padding to be smaller again. In effect, the large padding remains, and the results are still truncated. I can live with that of course, but I'm not sure it's normal behavior.

Yes, this is expected and usually not a problem, since deleting input characters during filtering happens rarely. Marginalia remembers the maximal length of the candidates and adjusts the alignment accordingly. If Marginalia wouldn't do this, we would see a lot of jumping during filtering and scrolling.

svictor9 commented 2 years ago

I understand. All clear, thanks!