On Saturday, August 5, 2017 at 2:09:41 PM UTC-7, ZyX wrote: > 2017-08-05 23:27 GMT+03:00 porphyry5 <[email protected]>: > > On Friday, August 4, 2017 at 10:03:16 AM UTC-7, porphyry5 wrote: > >> :h submatch( includes > >> Example: > >> :s/\d\+/\=submatch(0) + 1/ > >> This finds the first number in the line and adds one to it. > >> > >> Needing to increment several fields consisting of underscore and a single > >> digit (_\d) I modified the above along the lines of > >> > >> s/_\(\d\)/\='_'.submatch(1) + 1/gc > >> > >> most of which merely replaced the entire field with '1' > >> > >> Thinking the problem might be a conflict between the types, string and > >> number, I tried > >> > >> s/_\(\d\)/\="_".nr2char(submatch(1) + 1)/gc > >> then > >> s/_\(\d\)/\="_".nr2char(submatch(1) + 31)/gc > >> and finally success with > >> s/_\(\d\)/\="_".nr2char(submatch(1) + 49)/gc > >> which is limited to operations on just a single digit. > >> > >> So, is there a generally reliable method of performing arithmetic on > >> numeric fields embedded in a larger string pattern with :s? Thank you. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> Graham Lawrence > > > > Thank you, > > s/_\(\d\)/\='_'.(submatch(1)+1)/g > > works perfectly, and I see what I was trying initially > > s/_\(\d\)/\='_'.submatch(1)+1/g > > is actually equivalent to > > s/_\d/\=submatch(0)+1/g > > > > In the meantime, I read :h substitute( and found > > s/_\(\d\)/\=substitute(submatch(0),'\d',submatch(1)+1,'')/g > > which avoids the problem by making a secondary pattern selection of the > > number alone. But that's more typing, so I will pay attention to operator > > precedence in future. > > If you write using more then one language there is a good rule: do not > pay attention to operator precedence, just use parenthesis every time > you are not sure. I normally just assume that precedence is “[*/%] > > [-+] > binary comparison (>, <, >=, <=, ==, etc) > binary logical (not > bitwise) operators (&&, ||)” which is rather safe (though there are > languages where even these assumptions are not valid), and everything > else needs parenthesis. > > > > > -- > > -- > > 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 > > > > --- > > You received this message because you are subscribed to the Google Groups > > "vim_use" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout.
That's a good idea; you're saying to impose the operator precedence one needs on expressions, that it is simpler than keeping track of which particular little squiggle pre-empts another little squiggle (sorry, that's how I think of operator symbols). It just may have a profound effect on my success rate with expressions, because, if not mathematical, my idea of precedence has been limited to "goes left to right. Thank you again. -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
