On 24-Apr-2014 14:27 +0200, Christian Brabandt wrote:
> Am 2014-04-24 13:39, schrieb Ingo Karkat:
>> Hello Vim developers,
>>
>> my plugins' automated test suite found another regression. When
>> reformatting lines with gq{motion}, the start of change mark '[ does not
>> point to the start of the first line [0, lnum, 1, 0] any more, but
>> instead to after the end of the original first line [0, lnum,
>> len(getline(lnum)) + 1, 0].
>> As gq processes entire lines, the start of the change should indeed be
>> at column 1, as it used to.
>>
>> This scriptlet shows the discrepancy:
>>
>> :call setline(1, ["\t\tO sodales, ludite, vos qui", "attamen
>> consulite per voster honur. Tua pulchra facies me fay planszer
>> milies"])
>> :1normal! gqj
>> :echo getpos("'[") " Should yield [0, 1, 1, 0], but gives [0, 1,
>> 29, 0].
>>
>> Using the attached scriptlet, I've bisected this to the following patch:
>>
>> ,----[ bad change ]----
>> | 7.4.178 the J command does not update '[ and '] marks
>> `----
>>
>> I still see this in the latest 7.4.264 (HUGE build) on Linux/x64.
>
> Yes, previously, the join command wouldn't update the '[ and '] marks.
> Now it does.
> That is causing your regression.
Yeah, I had assumed that the gq implementation internally uses the join
command, so this is a classic case of unexpected side effects.
> I look into it.
Thank you very much!
> BTW: What kind of regression tests are you doing? Could that be used
> to extend the unit-test functionality in the testdir/ directory of Vim's
> source?
I have automated tests for about half of my plugins, using my own
runVimTests (http://www.vim.org/scripts/script.php?script_id=2565) test
framework. For illustration, here's the particular test that exposed
this regression:
,----[ example runVimTests test ]----
| " Test formatting lines to the width.
|
| edit text.txt
|
| call vimtest#StartTap()
| call vimtap#Plan(2)
|
| 13normal V5j\gq
|
| 3normal V5j\gq
| call vimtap#Is(getpos("'["), [0, 3, 1, 0], 'start of change')
| call vimtap#Is(getpos("']"), [0, 14, 3, 0], 'end of change')
|
| call vimtest#SaveOut()
| call vimtest#Quit()
`----
As all of my tests require and mainly test my plugins, I don't think
that Vim's test suite can directly benefit from them. However, as a side
effect, my test suite had exposed several bugs in the NFA-based regexp
engine before.
I've put down a note to set up a cron job that every few days pulls down
the latest changes from Mercurial, compiles Vim, and runs my tests. That
should enable me to quickly point out any regressions caught by my suite
in the future!
For each test failure, I still have to analyze, extract the code from my
test and plugin, and distill a minimal test scriptlet, which I then use
to bisect and post here. I hope that those can indeed be easily turned
into a Vim test. If there's anything I can do to make this translation
easier, please let me know. In general, a short tutorial how the Vim
tests work, idioms, and best practices (posted here on or vim.org) would
be great.
-- regards, ingo
--
--
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.
