redrawing doesn't help. In this case with getchar(), echon'ed trailing spaces are only shown after a non-space character is echon'ed afterwards.
It's not a big deal, but I'm going to cc: [EMAIL PROTECTED] since I can't find any way to create a getchar() + prompt with trailing spaces. I'm writing mappings like: cnoremap <silent> cd call Cd_plus() <CR> such that I want the user to see ":cd " as the prompt in the command line. On 5/16/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:
Eric Arnold wrote: > On 5/16/06, Gerald Lai <[EMAIL PROTECTED]> wrote: >> On Tue, 16 May 2006, Eric Arnold wrote: >> >> > Does anybody understand why trailing spaces in an "echon" string don't >> > actually show up? >> > >> > echon "\ngimme " >> > let inp = getchar() >> > echon nr2char(inp) >> >> I think echo/echon is doing fine. It's getchar() that's eating up >> trailing spaces. Compare @a's for: >> >> :redir @a | echon " 123 " | call getchar() | redir END >> :redir @a | echon "\n123 " | call getchar() | redir END >> :redir @a || echon " 123 " | call getchar() | redir END > > Not sure what the last example is supposed to do. > >> The "\n" or previous ex command "|" has something to do with it. >> >> (tested on Vim 6.3) >> -- >> Gerald >> > > It's odd that it remembers all the trailing spaces, and prints them > out as soon as the echon following the getchar() prints a > non-space char. > > I'm thinking that it could also be the rendering in the command window > that is causing it, as if it truncates trailing spaces when writing to > the screen, but not when actually building the strings internally. > > It's probably a combination of this, and that getchar() isn't in > the list of things that triggers printing the trailing spaces. > > I can't tell whether to call this a bug yet. > > > (Just guessing in the dark) Could it be a redraw problem? Best regards, Tony.
