Although I'm not certain that I understand the full set of use cases that would benefit from a resolution of these inconsistencies, it seems plausible to me that most or all of the use cases could be implemented in a buffer with some insightful mappings (of, for example, `i_^M`) and/or autocommands. There are at least a couple of full-blown shells that run in a buffer this way: [vimshell] and [conque]. Maybe their techniques could be useful to you.
As a tentative suggestion for resolving the inconsistencies with `:echo`: perhaps there could be an option which would enable full echoing, including empty lines, set by default to the current behaviour? Cheers -Ted [conque]: http://www.vim.org/scripts/script.php?script_id=2771 [vimshell]: http://github.com/Shougo/vimshell On Aug 9, 5:02 pm, Bram Moolenaar <[email protected]> wrote: > 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
