On 8 August 2010 23:01, Bram Moolenaar <b...@moolenaar.net> 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.
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
(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
(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.
==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.
(Besides, the echo is again erroneous as described in (c) above.)
==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.
==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.
--
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
