You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 😉)
The text was updated successfully, but these errors were encountered:
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 includesas 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 😉)The text was updated successfully, but these errors were encountered: