Yakov Lerner wrote:
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')
My stupid, uninformed :-) opinion is that if '\\' /can/ mean '\', then
it /should/ (unconditionally) mean '\'. Anything else is internally
inconsistent (in that you have 'x means y, but only if z'). 'x means y'
is a lot easier to understand, and IMO less error-prone (or maybe more
error-prone, but of the sort that are immediately recognized and easily
fixed, as opposed to subtle, hard-to-track-down errors).
Anyway, that's my logical argument, but being logical doesn't make it
right. :-)
--
Matthew
vIMprove your life! Now on version 7!
(Good day for this .sig, I guess ;-))
