I am about to fix the <f-args> bug that is mentioned in the todo.
There is one remaining ambiguity on which I need to ask the
community. The testcase that illustrates the bug is at the end.

First, about the bug that needs to be fixed. It is in handling of \\ when
\\ precedes th whitespace. I was bitten by this bug myself.
Sequence '\ ' is currently [correctly] treated as whitespace that's
embedded in the whitespace. Sequence '\\ ' is [incorrectly] treated
as '\ ' embedded into argument. It shall be treated as '\' then
argument break. (Current incorrect treatment does now allow to
have an argument consisting of single \, or of argument ending
with \).

There is one remaining ambiguity on which I need to ask the
community. It is how to treat \\ (when \\ is not preceding the whitespace).

One possibility is to treat \\ as \\. Second possibility is to treat
\\ as \. I am inclined to first (\\->\\), because (a) it is backward-compatible
and (b) it seems less surprising when \\ is embedded into arguments
containing regular expressions and the like.

What are your opinions on expanding \\ as \\ vs \ in <f-args> ?

Yakov
----------------------------------------------------------------------------------------------
" XX \\         works, 2 args ('\\')
" XX a b        works, 2 args ('a','b')
" XX a\ b       works, 1 arg ('a b')
" XX a\\b              1 arg ('a\\b')       Shall it be 1 arg('a\b') ?
" XX a\\ b      bug:   1 arg('a\ b')         Expected 2 args('a\','b')
" XX a\\  b     bug:   2 args ('a\ ','b').   Expected 2 args('a\','b')

command! -nargs=* XX :call Test(<f-args>)
fun! Test(...)
 echo "XX: ".a:0." args("
 let i=1
 let argc=a:0
 while i <= a:0
     echon "'".a:{i}."'"

     if i != a:0 | echon "," | endif

     let i = i + 1
 endwhile
 echon ")"
endfun

Reply via email to