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

Reply via email to