current default read --prompt-str (lhs) truncation leads to frequent "all path / no question" [y/n] user queries (add flag to force wrapping?)

[koedx]

fish version: 3.6.1

When fish's builtin read prompt-str is used to query a user w/ a question in the general form of "{some question} at {path} [y/N]?", the LHS truncation leads to a "question" consisting of .../long/path/to/x? [y/N]: ... which obviously leaves the user with no basis for answering.

An example where this happens is when using the shipped funced which includes

if not set -q _flag_save
    echo (_ "Warning: the file containing this function has not been saved. Changes may be lost when fish is closed.")                            
    set -l prompt (printf (_ 'Save function to %s? [Y/n]') "$writepath")
    # long $writepath pushes everything "off stage left" >_<                                              
    read --prompt-str "$prompt" response
    # ....

as a kludgey fix, I edited funced to echo "$prompt" (so that the prompt wraps & the "question" part of the $prompt is guaranteed to be visible), & left the read prompt blank.

Would it be worthwhile to modify the way screen.cpp currently handles prompt-str (perhaps a flag to force wrapping)?

I read thru the discussion @ #904 leading to a2ae2d6, but I still believe that for the extremely common case of queries that lead w/ the "what" (of the question) & then follow-up w/ the (occasionally less important) matter of "where/how/etc..." (the paradigmatic case being "confirmation" prompts preceding potentially destructive changes) such prompts should be seen in their entirety (ie. default to wrapping)... otherwise, how is the user supposed to know what they are [y/n]ing to (eg. ...your entire /path/to/home directory? [y/n]) is that "..." backup/delete/move? ... you get the point 😉)