Bram Moolenaar <[email protected]> wrote:
> - it's not a new problem in 7.3
Isn't a/the purpose of a new release resolving known issues?
Specifically, the manifest bug that I described in ==3== and the
first part of ==4== has been known for at least two years now.
> - it is going to be incompatible with previous versions, some scripts
> may need to be adjusted
If the behaviour under discussion is ever going to change, then the
sooner this happens the better. Neither writing more scripts to the
current interface nor abstaining from writing such would make things
any easier in the future.
> - knowing how Vim does this it's possible to make it work
I for one am not sure that I understand all the intricacies involved,
even after your explanations. Neither are those complicacies described
in the documentation. And even where it is known what to do, the
resulting code tends to get contrived and prone to error.
Anyway, I see I cannot change your mind.
The following is only a clarification of (my opinion on) the essence
and importance of issues being discussed.
>> for s in ['abc', '', 'def'] | echo s | endfor
>> ...
>
> It only starts a new line if you have output something. Change the
> empty string to ' ' and it works.
Provided that I know it is indeed empty. If it were
for s in ss … endfor
then I'd have to add an ‘if’ statement to check each string if it's
empty, and if it is, print something else instead of it. I see it
much simpler to use echon and explicit ‘\n’s all the way … but then
what is the use of having echo at all?
There is a deeper, and more serious problem here: echo's outcome
appears to be history-dependent rather than self-contained, which is
an especially bad case of non-orthogonality. Obviously, there are
situations where history is unknown, hence the outcome of echo is
unpredictable. (Imagine a history-dependent printf() in C.)
>> echo "abc\n" | echo "def"
>> ...
>
> This works:
> echo "abc\n " | echo "def"
Same as above holds. Normally two calls of echo do not textually
follow each other, so you do not actually know whether adding that
space makes sense. What if the second echo were to be echon?
>> (c) after a call of input(), e.g. in
>> let x = input('') | echo 'ABC'
>> the ABC string goes to the same line as the input; similarly,
>> let x = input('') | echo "\nABC"
>> prints ABC on the line immediately following the input(), while
>> it should really leave an empty line between that of input() and
>> that with the ABC.
>
> This is intentional, it avoids having to press Enter at the more-prompt.
> You can echo the result of input() if you want to see it.
The issue here is not whether we want to see the result of input(),
but, once more, the echo not starting on a new line.
And I don't really understand how the more-prompt gets into the
picture; we are discussing echo and input() which I understand as
general-purpose programming facilities.
>> (Besides, the echo is again erroneous as described in (c) above.)
>
> Please don't call things an error when it might actually be intended
> behavior.
I called it erroneous because it did seem so, in the absence of self-
consistency as well as consistency with the documentation. There was
no reason to suspect it was intentional.
> The behavior of messages is very complicated. It's a compromise between
> keeping the text the user might want to read and avoiding an annoying
> hit-enter prompt. These things can't be solved by looking at only one
> side of the problem.
But they are solvable, as many examples out there demonstrate.
I believe solutions to be achievable through streamlining rather than
the opposite. If any compromise is needed, it'd better not affect
simplicity, dependability, consistency, and composability.
Best regards,
Boyko
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
