Re: in sub-replace-expression('\=')

Hi, Ben and all;

Thank you for your reply. At first, I should have made my system
environment clear at the previous post.

OS - Fedora 12
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 18 2010 15:14:40)
Included patches: 1-29
Modified by <bugzilla@redhat.com>
Compiled by <bugzilla@redhat.com>

I would like to exclude the issue of echo/echomsg dependency here.
I updated the previous code like the following;

function! s:nl()
return "\n"
endfunction
let x = substitute('a', '.', "\n", "")
let y = substitute('a', '.', '\=s:nl()', "")
echomsg x
echomsg y
echomsg len(y)
echomsg strpart(y, 0, 1) == "\x0a"
echomsg strpart(y, 0, 1) == "\x0d"

The result is,

^@
^M
1
0
1

I hope that I could have made my point clear and would like to
focus on the behaviour of substitute() and sub-replace-expression.

>"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')

Please refer to the function vim_regsub_both in regexp.c if you like.

>I think you are doing something you're not really supposed to do. The
>bug is probably that it doesn't trigger an error, not that it works
>unexpectedly.

As you mention, if I'm doing something what is not supposed to do, Vim
should generate an error. However I suspect that what I'm doing
something not supposed to do.

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.

Regards,

Motoya Kurotsu

===================== attachment =================
--- vim73/src/regexp.c 2011-03-06 16:45:15.000000000 +0900
+++ vim73.1/src/regexp.c 2011-03-06 16:36:12.000000000 +0900
@@ -7011,7 +7011,7 @@
{
/* Change NL to CR, so that it becomes a line
break.
* Skip over a backslashed character. */
- if (*s == NL)
+ if (*s == NL && !reg_line_lbr)
*s = CAR;
else if (*s == '\\' && s[1] != NUL)
{
@@ -7021,7 +7021,7 @@
* abc\
* def
*/
- if (*s == NL)
+ if (*s == NL && !reg_line_lbr)
*s = CAR;
had_backslash = TRUE;
}

On 3月5日, 午後5:13, Ben Schmidt <mail_ben_schm...@yahoo.com.au> wrote:
> > Could anyone tell me why<NL>(0x0a) should be replaced by<CR>(0x0d)
> > in sub-replace-expression('\=')?
>
> > See the following code snippet;
>
> >    function! s:nl()
> >      return "\n"
> >    endfunction
> >    echomsg substitute('a', '.', "\n", "")       "(1)
> >    echomsg substitute('a', '.', '\=s:nl()', "") "(2)
>
> > (1) returns<NL>(0x0a), (2) returns<CR>(0x0d).
>
> > Why such design choice was done?
>
> I think you are doing something you're not really supposed to do. The
> bug is probably that it doesn't trigger an error, not that it works
> unexpectedly.
>
> I think there are a bunch of different things going on here.
>
> For (1), I don't get <NL> returned, but ^@ (<Nul>). This is somewhat
> expected, given :help keycodes, but still a little mysterious, as that
> help topic is about bytes being represented in a buffer, not a string.
> Strings usually behave a bit differently and more normally.
>
> But I get different results with :echo to what I get with :echomsg, too.
> :echo behaves in a more expected manner. So I suspect :echomsg is not
> really printing a Vim string properly, treating it more like raw text
> out of a buffer, which is slightly different, and :echo is doing more
> the right thing. There are a lot of funny little behaviours with things
> like this. Doing Ctrl-R = in insert mode and then using strings like
> "\<NL>", "\<CR>", "\<Nul>", "\<Up>", etc. all do different and strange
> things, too. Likewise trying them with :echo and :echomsg. Lots of
> strangeness.
>
> Regarding (2), note this comment in the help (:help
> sub-replace-expression):
>
> "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.
>
> However, the help text at that place, as well as at :help
> sub-replace-special sheds some light on the matter, and perhaps explains
> why things are happening the way they are. Of course, the differences
> between :echo and :echomsg make it even more confusing.
>
> 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.
>
> 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