Hirohito Higashi wrote:
> 2016-1-10(Sun) 22:14:01 UTC+9 Bram Moolenaar:
> > Hirohito Higashi wrote:
> >
> > > 2016-1-10(Sun) 4:15:14 UTC+9 Bram Moolenaar:
> > > > Hirohito Higashi wrote:
> > > >
> > > > > 2016-1-8(Fri) 2:27:17 UTC+9 Bram Moolenaar:
> > > > > > Hirohito Higashi wrote:
> > > > > >
> > > > > > > > > To: Bram (As a Vimboss)
> > > > > > > > > To: Christian Brabandt (As a visual <C-A>/<C-X> first patch
> > > > > > > > > author)
> > > > > > > > > To: Jason Schulz (As a support for bin 'nrformats' patch
> > > > > > > > > author)
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I refactored visual <C-A>/<C-X> to support vcol et al.
> > > > > > > > > This mean is <TAB> code free!
> > > > > > > > >
> > > > > > > > > Contents of patch.
> > > > > > > > > - visual <C-A>/<C-X> support vcol. (<TAB> code free)
> > > > > > > > > - 'test_increment' convert from old style test to new style
> > > > > > > > > test. and added some test items.
> > > > > > > > > - Processing was allowed to separate.
> > > > > > > > > (line loop process and add/subtract process)
> > > > > > > > > (We have to use the existing function block_prep() to
> > > > > > > > > process the block-wise)
> > > > > > > > > - We removed the halfway right-to-left processing.
> > > > > > > > > (Remove RLADDSUBFIX() macro)
> > > > > > > > > (This is causing the actual problem)
> > > > > > > > > $ vim -Nu NONE -c "set rightleft"
> > > > > > > > > i123 45<Esc>
> > > > > > > > > <C-A> " Unexpected swap the numbers of strings
> > > > > > > > > occurred.
> > > > > > > > >
> > > > > > > > > Christian Brabandt and Jason Schulz and List>
> > > > > > > > > I was wondering if you could review this patch.
> > > > > > > > >
> > > > > > > > > Jason Schulz>
> > > > > > > > > Sorry to such just your patch was included.
> > > > > > > > > I have just completed the doing has been working since last
> > > > > > > > > fall :-)
> > > > > > > >
> > > > > > > > That's a big change. Can you give an example of what didn't
> > > > > > > > work before
> > > > > > > > and works now?
> > > > > > >
> > > > > > > Please see Test_visual_increment_27() ~
> > > > > > > Test_visual_increment_34().
> > > > > > > Below is ather exsample.
> > > > > > >
> > > > > > > Case 1 (Visual blockwise <C-A> with TAB and SPACE mixed)
> > > > > > > - Manipulate
> > > > > > > $ vim -Nu NONE
> > > > > > > :call setline(1, ["1234 56", "\<TAB>78"])
> > > > > > > :exec "norm! ggw\<C-V>jl\<C-A>"
> > > > > > > - Expect result
> > > > > > > "1234 57"
> > > > > > > "\<TAB>79"
> > > > > > > - Unpatched result
> > > > > > > "1235 56"
> > > > > > > "\<TAB>79"
> > > > > >
> > > > > >
> > > > > > I see, thanks for fixing that.
> > > > > >
> > > > > > > > To make reviewing easier, it would be good to first make a
> > > > > > > > patch to
> > > > > > > > change the test from old to new style. Then we know the test
> > > > > > > > works with
> > > > > > > > the old code.
> > > > > > >
> > > > > > > Okay. I attached simple patch that only convert to new style test
> > > > > > > of
> > > > > > > test_increment.
> > > > > >
> > > > > > Thanks. The original test had a nice explanation of what it was
> > > > > > doing.
> > > > > > Although the new style test do have the assert_equal() calls that
> > > > > > make
> > > > > > it easier to see what is going on, the commands themselves are
> > > > > > still a
> > > > > > bit of a puzzle. Since the explanations were already written, we
> > > > > > can
> > > > > > keep them. Using the comment above the test function should work
> > > > > > well.
> > > > >
> > > > > Indeed. I did it. Please check and include attached patch.
> > > >
> > > > Thanks!
> > >
> > > Thanks for including this.
> > > Patch 7.4.1072
> > > https://groups.google.com/d/topic/vim_dev/_K0eQkIB5aY/discussion
> > >
> > > >
> > > > > BTW, The following changes I thought happy for test_increment.vim.
> > > > > How do you like it?
> > > >
> > > > Yes, that's better than the arbitrary order we have now.
> > > > Unfortunately it break test_quickfix, it makes an assumption about test
> > > > function ordering. That needs to be fixed.
> > >
> > > Thanks for including this too.
> > > Patch 7.4.1071
> > > https://groups.google.com/d/topic/vim_dev/p6IAS6bPFDU/discussion
> > >
> > >
> > > Well, the next simple patch is about this.
> > > > - We removed the halfway right-to-left processing.
> > > > (Remove RLADDSUBFIX() macro)
> > > > (This is causing the actual problem)
> > > > $ vim -Nu NONE -c "set rightleft"
> > > > i123 45<Esc>
> > > > <C-A> " Unexpected swap the numbers of strings occurred.
> > >
> > > Investigation result:
> > > Reverse line process of 'rightleft' is performed by the display part.
> > > therefore it doesn't need in do_addsub().
> > >
> > > I've attached a patch containing the test.
> > > Please check it.
> >
> > Thanks. Now I could check that the test fails before including the
> > change in ops.c.
>
> Thanks for include this quickly.
> Patch 7.4.1076
> https://groups.google.com/d/topic/vim_dev/TOHFHDxek34/discussion
>
> The last patch fixing this.
> - visual <C-A>/<C-X> support vcol. (<TAB> code free)
> - Processing was allowed to separate.
> (line loop process and add/subtract process)
> (We have to use the existing function block_prep() to process the
> block-wise)
>
> Sorry, more than this is difficult to separate the patch...
> Please include this.
I have included it now. Unfortunately there was a merge conflict with
patch 7.4.1085. I solved that. Then it turns out that the marks are
set differently. Patch 7.4.1085 sets then before the first changed
number and at the end of the last changed number. Your patch put them
on the Visual area. I think the first solution is more accurate, thus I
kept that.
I found that OP_ADD and OP_SUBTRACT are also used in a Perl header file.
Thus I changed them to OP_NR_ADD and OP_NR_SUB. Not so nice...
--
SUPERIMPOSE "England AD 787". After a few more seconds we hear hoofbeats in
the distance. They come slowly closer. Then out of the mist comes KING
ARTHUR followed by a SERVANT who is banging two half coconuts together.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" 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_dev" 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.
