Errors on NUL characters in vroom files.

[splinterofchaos]

Hi. I need to test various features of vim/neovim related to NUL (digraph: ^@) characters. I've tried this a couple different ways and all failed, one causing vroom itself to quit early.

  % ab^@cd
  ab^@cd

(The ^@ produced with Ctrl+k NU) This test might not be well-formed as no keyboard has a NUL key, but here's the output for running with --neovim:

FAILED on line 8: Expected "acd" in verbatim mode.

Found:
1   ab <<<<

Failed command on line 8:
acd

Ran 1 test in test/legacy/nul.vroom. 0 passing, 0 errored, 1 failed.

Expected "acd"? What happened to b? At least I understand the Found: line--vroom thinks NUL means termination.

Now, run with plain vim:

ERROR: Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/vroom/runner.py", line 71, in __call__
    self.Run(lines)
  File "/usr/local/lib/python2.7/dist-packages/vroom/runner.py", line 162, in Run
    self.Test(self.env.buffer.Verify, line, **controls)
  File "/usr/local/lib/python2.7/dist-packages/vroom/runner.py", line 116, in Test
    self.ExecuteCommands()
  File "/usr/local/lib/python2.7/dist-packages/vroom/runner.py", line 56, in ExecuteCommands
    self._running_command.Execute()
  File "/usr/local/lib/python2.7/dist-packages/vroom/command.py", line 59, in Execute
    self.env.vim.Communicate(self.command, delay)
  File "/usr/local/lib/python2.7/dist-packages/vroom/vim.py", line 118, in Communicate
    '--remote-send', command])
  File "/usr/local/lib/python2.7/dist-packages/vroom/vim.py", line 260, in TryToSay
    env=env).communicate()
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
TypeError: execve() arg 2 must contain only strings


Ran 1 test in test/legacy/nul.vroom. 0 passing, 1 errored, 0 failed.

Try 2:

  > i<C-k>NU<Esc>
  ^@

neovim:

FAILED on line 2: Expected "" in verbatim mode.

Found:
1   
 <<<<

Failed command on line 2:


Ran 1 test in test/legacy/nul.vroom. 0 passing, 0 errored, 1 failed.

vim:

FAILED on line 2: Expected "" in verbatim mode.

Found:
1    <<<<

Failed command on line 2:


Ran 1 test in test/legacy/nul.vroom. 0 passing, 0 errored, 1 failed.

Almost the same, but note that the <<<< marker for the neovim test displays on the next line.

On a lighter side, this test works with both vim and neovim.

  > i<C-k>SH<Esc>
  % �^A
  ��^A^A

Eventually, I'd like to use vroom to test system() and systemlist()'s support of NUL characters. Thank you.

[dbarnett]

It needs to be something --remote-send can accept. At least <Nul> should work, but looks like it doesn't, either:

  % ab<Nul>cd
  ab^@cd

FAILED on line 1: Suspected error message:
E29: No inserted text yet

Message was "E29: No inserted text yet"

Failed command on line 1:
% ab<Nul>cd

Last few commands (most recent last) were:
iab<Nul>cd<ESC>

The exception and behavior you're seeing are a little surprising, too. There's probably some overall bugginess with special characters. Not sure if we actually want to support literal NUL characters, but if not we could at least improve the error message to say Unsupported character "^@". Use "<Nul>" instead..

[equalsraf]

Quick check for Neovim's replace_termcodes is turning 'ab\x0cd' into 'ab' not sure why. It is quite possible it is not ready to take a Null byte.

As for the and cases it is likely they are affected by #36(neovim/neovim#1270)

[splinterofchaos]

Quick check for Neovim's replace_termcodes is turning 'ab\x0cd' into 'ab' not sure why.

Because replace_termcodes() doesn't take a len parameter (needs to return one, too) and relies on strlen(). Same for ins_typebuf(). The String object we pass to it does have a len member, so it should be trivial to fix. Would it be too non-topical to add that change to neovim/neovim#1270?

[splinterofchaos]

Quick check for Neovim's replace_termcodes is turning 'ab\x0cd' into 'ab' not sure why.

Actually, it's working for the lua tests (neovim/neovim#1296 (comment)), but it converts NULs to newlines within the line. We just need to modify the API (buffer_get_*) to convert them back.