Boyko Bantchev wrote:
> On 8 August 2010 23:01, Bram Moolenaar <[email protected]> wrote:
> > ...
> > We are getting close to the 7.3 release! If nothing goes wrong I will
> > release 7.3 in less than a week. Last chance to report problems!
> > ...
>
> Bram,
>
> Great thanks to you for doing all this huge work on keeping Vim the
> best text editor. This work of yours helps so many people in the
> world, and in so many ways, to do their own work.
>
> The upcoming 7.3 release will no doubt improve on our experience
> with Vim, as all previous have done. However, I am concerned that
> the problems with Vim language's basic input and output about which
> I wrote several times, are, it seems, going to remain in 7.3 – and
> that means for at least another couple of years or more.
>
> Please reconsider this!
>
> One way to use Vimscript is to write and execute simple REPLs in the
> editor. A number of useful utilities, as well as educational programs
> can be written this way. Simple and reliable I/O primitives are
> essential to this, but, alas, Vim's :echo and input() have serious
> bugs each, and are even more problematic when used together. Said
> problems can be circumvented, I guess, but at the expense of ugliness
> and inconvenience reproduced in every single script. This would
> continually repel especially potential new users of Vim.
>
> I am once again describing the bugs and incosistencies I know of, in
> the hope that this would help to change your mind w.r.t. them. I am
> mostly repeating my previous posts but exposing the issues a bit more
> systematically.
I am not going to change this now, because:
- it's not a new problem in 7.3
- it is going to be incompatible with previous versions, some scripts
may need to be adjusted
- knowing how Vim does this it's possible to make it work
> Thank you for your attention, best regards,
> Boyko
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ==1==
> The documentation says that echo “… starts on a new line” but this
> is broken in at least several cases:
>
> (a) empty strings, e.g.
> for s in ['abc', '', 'def'] | echo s | endfor
> prints
> abc
> def
> rather than
> abc
>
> def
It only starts a new line if you have output something. Change the
empty string to ' ' and it works.
> (b) this doesn't look like empty strings but still:
> echo "abc\n" | echo "def"
> is supposed to output
> abc
>
> def
> but instead prints
> abc
> def
This works:
echo "abc\n " | echo "def"
abc
def
> (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.
> ==2==
> The documentation says nothing about whether input() always starts
> on a new line or not. Simple tests such as e.g.
> echo ">>>" | let x = input('')
> lead one to concluding that it does. However, then,
> while 1 | let x = input('A') | echo "R\n" | endw
> should be expected to print empty lines between each "R\n" and the
> subsequent input('A') but it does not – that contradicts the
> assumption that input() always moves to a new line at start.
It's difficult to explain how this works and probably also depends on
options settings, such as 'shortmess'. You can see what happens.
> (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.
> ==3==
> Reducing the "R\n" in the above example to just "R":
> while 1 | let s = input('A') | echo 'R' | endw
> exhibits an even stranger behaviour. For a start, just enter several
> empty lines to each input() before breaking the loop: not only is the
> 'R' printed on the same line as 'A' (which it shouldn't) but each new
> 'R' is displaced more and more to the right.
That looks like a bug.
> ==4==
> Once input() finishes, both the prompt and the entered string are
> being removed from display. Apart from this being, I believe, a
> wrong behaviour in itself, it, again, is not consistently manifested.
> This is easily seen by trying the last example above, this time
> entering non-empty lines. One can see that the implicitly echoed
> input is fully or partially (depending on its length) retained –
> which is probably a particular manifestation of some of the other
> bugs I mentioned (or perhaps a remnant of a correct behaviour).
>
> Also, the input()'s display, both the prompt and the entered text,
> is not removed if a single command such as
> :let x = input('PROMPT: ')
> is executed.
>
> I believe that input() should *never* remove the entered text, as well
> as the prompt, if any. Provided that it ends without moving to a new
> line, it shoild still be possible, if that is wanted, to erase the
> said text by ‘echon’-ing \r or \b. If removal is the default and
> one wants to keep the input, one would have to re-echo what he just
> typed in, which I think is much less natural.
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.
--
Time is an illusion. Lunchtime doubly so.
-- Ford Prefect, in Douglas Adams'
"The Hitchhiker's Guide to the Galaxy"
/// 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
