2

How can I reliably print a message and pause during processing of .vimrc? I'm using vim 7.4 (not gvim) on Linux Mint. The input() function behaves erratically as shown below. The redraw function doesn't seem to help. I'd like to print a message and wait for the user to press a key to proceed.

Any tips?

For example, with my .vimrc set to:

redraw!
echo "xa"
redraw!
call input("y123456")
redraw!
echo "xb"
redraw!
call input("z123456")
redraw!
echo "xc"
redraw!

with vim -u .vimrc --noplugin no-such-file, I see:

  • xay123456, on the bottom line (~ on the other lines), with cursor on the digit 5
  • press ENTER
  • xbz123456, with cursor about 6 or 7 characters after the digit 6
  • press ENTER
  • xcPress ENTER or type command to continue, with cursor immediately after "continue"
  • press ENTER
  • `"no-such-file" [New File]

with vim -u .vimrc --noplugin I see:

  • screen 2/3 full of ~ down the left side, with y123456 towards the right side, about 15 lines above the bottom line, with cursor on the (empty) bottom line about 8 characters from the left
  • press ENTER
  • screen unchanged except for bottom line now says xbz123456 with cursor about 6 characters to the right of the digit 6
  • press ENTER
  • last line now says xcPress ENTER or type command to continue with cursor just after continue
  • press ENTER
  • normal screen with nothing on the bottom line

1 Answer 1

2

Problem description

You're trying something that Vim was not really meant to do. Although your VimScript does work, I've modified it to:

redraw!
echo "xa"
redraw!
let i1 = input("y123456")
redraw!
echo "xb"
redraw!
let i2 = input("z123456")
redraw!
echo "xc"
redraw!

And checked that i1 and i2 variables are correctly setup. For this purpose I've run Vim as:

vim -u NONE -u the_above_vimrc_file

On urvxt and on xterm. And the behaviour on both terminals is considerably different. Using the GUI is even a worse idea since :h input has:

NOTE: This function must not be used in a startup file, for
the versions that only run in GUI mode (e.g., the Win32 GUI).

You probably can get the right terminfo configuration to make Vim work like a prompt program on startup, but even then, it is unlikely to be portable across different terminal emulators.

Correct approach

You should not really try to pause during Vim startup. Even if you would like to select between different environments it can be better done with a shell (or even bat) script. And moreover, pausing during the startup would annoy anyone trying to use the editor.

Instead you should really use :echom to output messages during startup, and then use :messages to check what happened during the startup. It does not only allow you to check the messages several times (until you clear them), but logs together your debug messages with error messages from Vim in chronological order (which is very useful for debugging).

4
  • Thanks. I had seen that note about not using input() in GUI mode, but fortunately I'm not using a GUI. What I'm trying to do is use the time-tested technique of print-statement debugging for my .vimrc. I'd like to print a message, pause the control flow while waiting for a keystroke, and then continue. I'm not trying to do anything fancy, like select between different environments.
    – jrw32982
    Commented Dec 25, 2016 at 16:16
  • @JohnWiersba - But that is the wrong idea of debugging even in interactive programs. You want to log an error in a prominent way in a log and then exit the program still logging the exit path. gcc, httpd, msyql, postgres, all main programs follow that approach. The only meaningful program that stops on error is LaTeX, and even then people prefer to force it to quit on errors. So no, don't pause on error, log it and make the program exit (or start if it is possible), pausing on errors is bad design. (Also, I've fixed a typo in the answer.)
    – grochmal
    Commented Dec 25, 2016 at 16:42
  • I guess we'll have to agree to differ on valid approaches to program debugging. Brian Kernighan seems to approve: "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." See stackoverflow.com/questions/189562 and everything2.com/title/printf%2528%2529%2520debugging
    – jrw32982
    Commented Dec 25, 2016 at 20:55
  • @JohnWiersba - I don't disagree about print statements, I disagree that a program should stop and wait for the user to read the error message. The *nix way is to log the message and then ask the user to read the log after the process terminates. Not interrupt the program flow to show an error message to the user. Print statements are awesome, often more useful than a fully flagged debugger.
    – grochmal
    Commented Dec 25, 2016 at 22:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.