Boyko Bantchev wrote:
> 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.
Yes, but we are too close to a release to make changes that might cause
more trouble than they fix. There is not sufficient time for testing
and discussing alternative solutions.
> > - 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
--
hundred-and-one symptoms of being an internet addict:
32. You don't know what sex three of your closest friends are, because they
have neutral nicknames and you never bothered to ask.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
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