counsel-find-file line wrap issue on long file names

[dmalyuta]

I am using Emacs 27.1 on Ubuntu 20.04, with the latest version of ivy/counsel/swiper from MELPA. The issue that I'm seeing is that the "find file" prompt for counsel-find-file wraps by just one line when the file name becomes too long. Here is what I mean:

This creates all sorts of problems, for example ivy-posframe gets out of alignment when it happens.

One would prefer that the "Find file: ..." prompt stays consistently all on one line if the lines are truncated, or wraps (according to ivy-truncate-lines).

[basil-conto]

See also #2501 and hlissner/doom-emacs#3686.

[dmalyuta]

Thanks, I read through those issues but it doesn't solve the problem that I'm reporting here. The specific issue here is that long file names cause the prompt to overflow into a new line, causing the behavior in the GIF of the original post, where the minibuffer starts looking like this:

x   Find file:
<LONG FILE PATH>                    <======== New line! This should not happen!
<completion candidates>

The expected behavior is the following. If ivy-truncate-lines is t:

... <LONG FILE PATH TAIL>
<completion candidates>

or:

x   Find file: ... <LONG FILE PATH TAIL>
<completion candidates>

On the other hand, if ivy-truncate-lines is nil, then:

x   Find file: <LONG 
FILE 
PATH>
<completion candidates>

The behavior that I'm trying to get to is a consistent treatment of the first line of the prompt, which should truncate or not truncate like a normal line... What is happening right now is that the prefix x Find file: is somehow "special" and always stays on the first line, while the file path "jumps" to a new line when it is too long for the frame-width.

[basil-conto]

I understand, and I agree that what you describe is desirable behaviour. I only linked the other issues for some precedent on this (there's probably more, but I couldn't find it easily).

[basil-conto]

The expected behavior is the following. If ivy-truncate-lines is t:

... <LONG FILE PATH TAIL>
<completion candidates>

or:

x   Find file: ... <LONG FILE PATH TAIL>
<completion candidates>

BTW this is not how truncate-lines works: non-nil means long lines are truncated on the window edge.

The first example looks more like an automatic-hscrolling value of current-line, and the second example looks like file name abbreviation/truncation to the left, neither of which are controlled by truncate-lines.