> you Ben for my carelessness.
No need at all to apologise.
> 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.
The help section is definitely written with a buffer perspective.
However, it doesn't have anything in it to say it is restricted to that.
I'm not sure what makes more sense. I lean towards doing the
substitutions, though, so that \= works the same way regardless of
whether you use it in a substitute() or a :substitute.
For buffers, this means:
<CR> => line break
\<CR> => carriage return
<NL> => line break (for convenience)
\<NL> => linefeed, which is interpreted as a null in a buffer
For strings:
<CR> => linefeed
\<CR> => carriage return
<NL> => line break, linefeed (unchanged)
\<NL> => null (ends the string)
Part of my reasoning for this is that I can't think of any situation
where you would want to use \= in a substitute() call, unless you were
writing some plugin that took a \= originally intended for a :substitute
command and used it in substitute(). Ordinarily if you want an
expression in substitute(), you just write the expression as the
argument.
>> 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?
He definitely follows vim_use a bit, but appears more frequently in
vim_dev. I'm sure he wouldn't mind being CCed or emailed directly with a
specific question about a patch (or proposed patch), though, as it is a
question only he can answer. :-)
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