Thank you for following up. At first, I would like to correct the
previous my post.
> I think that you misunderstand the help above. It means, for example,
> the following code does not work, I think. See the function
> vim_regsub_both in regexp.c.
>
> let y = substitute(str, '.', "\=substitute(v:val, 'x', 'X', '')", 'g')
This code is wrong and is not what I intended.
let y = substitute(str, '.', '\=substitute(submatch(0), "x", "X",
"")', 'g')
This one is what I intended. And this code "works" correctly.
So I would like to delete the part of the previous post and apologize
you Ben for my carelessness.
> :s/./\=substitute(submatch(0),'x','\=whatever','') - (1)
>
> My main point, though, which has basically just been proven, is that
> it's hard to know exactly what the help means, or was intended to
> describe; that fact merely suggests there might be problems if you have
> \= inside a substitute() call.
Yes, I agree that help is only suggestion. In this case, code says us
that
there would be problems if we have '\=' inside a 'recursively' called
substitute(). For example, the (1) you showed is one case and the
below
is another in the context of function call.
let y = substitute(str, '.', '\=substitute(submatch(0), "x",
"\=whatever", "")', '')
I assume that we can have '\=' inside a 'non-recursively' called
substitute()
like the following;
let y = substitute('a', '.', '\=s:nl()', "")
The issue is that evaluation denoted by '\=' includes the
interpretation
such as ':help sub-replace-expression' describes. Actually we don't
have
any way to replace something with the result of evaluation including
"\n".
> Also, there may be other issues that are probably worth
> checking/addressing at the same time. As :help sub-replace-expression
> notes, using \n to break lines is a convenience. The 'proper' way to do
> it is to use \r. Does \r currently 'do the right thing', or does it
> result in \r in the string? Also, does \\\r do the right thing (insert a
> \r), and how about \\\n--does it insert a null (i.e. probably end the
> string) as it should if the documentation is followed?
I think that ':help sub-replace-expression' describes about
substitution
of buffer. I think that substitution of string should not do such
interpretation. What really we want seems the flag which disable such
interpretation. The variable reg_line_lbr seems to work as such flag,
but as you mention, we may need another flag.
>>> I'm not sure how much, if any, of this could be regarded as bugs, and
>>> how much, if any, would be fixed, given backwards-compatibility issues.
>
> I still stand by this, though.
I understand.
> We'll need to hear from Bram whether he's
> willing to change this.
Yes, I would. Is he check this group periodically? Or is it better to
post this
issue to vim_dev?
Regards,
Motoya Kurotsu
On 3月7日, 午前9:58, Ben Schmidt <mail_ben_schm...@yahoo.com.au> wrote:
> > I would like to exclude the issue of echo/echomsg dependency here.
>
> OK, sounds good!
>
> >> "This does not work recursively: a substitute() function inside the
> >> expression cannot use "\=" for the substitute string."
>
> >> This suggests you can't really expect \= to work as the substitute
> >> string in a substitute() function call.
>
> > I think that you misunderstand the help above. I think that it means,
> > for example, the following code does not work.
>
> > let y = substitute(str, '.', "\=substitute(v:val, 'x', 'X', '')",
> > 'g')
>
> I don't think that's the correct interpretation of the help, either.
> Actually, I think it means you can't do
>
> :s/./\=substitute(submatch(0),'x','\=whatever','')
>
> My main point, though, which has basically just been proven, is that
> it's hard to know exactly what the help means, or was intended to
> describe; that fact merely suggests there might be problems if you have
> \= inside a substitute() call.
>
>
>
> > The attached patch is the example which works around this problem. It
> > is assumed that the variable reg_line_lbr is true if the function
> > vim_regsub_both is called from the substitute(), vice versa if it is
> > called from the :substitute command as the current implementation is.
>
> > The result of the code above;
>
> > ^@
> > ^@
> > 1
> > 1
> > 0
>
> > It seems OK. Next test :substitute command with the pattern
> > written at the comment of the function vim_regsub_both. On text;
>
> > abc\
> > def
>
> > execute ':%s/abc\\\ndef/\="aaa\\\nbbb"/'.
>
> > aaa\
> > bbb
>
> > It seems OK, too.
>
> > In summary, I think that this issue is a bug and it should be fixed
> > so that the result is as same as my patch works around. Otherwise,
> > Vim should inform us of illegal usage by generating error.
>
> Your workaround seems sensible to me, though yes, of course, it should
> either be ensured that reg_line_lbr is always set as you expect, and
> documented in a code comment to be that way, or another variable should
> be introduced to give the distinction you need.
>
> Also, there may be other issues that are probably worth
> checking/addressing at the same time. As :help sub-replace-expression
> notes, using \n to break lines is a convenience. The 'proper' way to do
> it is to use \r. Does \r currently 'do the right thing', or does it
> result in \r in the string? Also, does \\\r do the right thing (insert a
> \r), and how about \\\n--does it insert a null (i.e. probably end the
> string) as it should if the documentation is followed?
>
> >> I'm not sure how much, if any, of this could be regarded as bugs, and
> >> how much, if any, would be fixed, given backwards-compatibility issues.
>
> I still stand by this, though. We'll need to hear from Bram whether he's
> willing to change this.
>
> Ben.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment