Improved responsiveness of editor for large projects

[rimesc]

The attached change goes a long way towards improving the responsiveness of the editor for projects with large numbers of steps (issue #6), by not recreating the same StepMatcher for every candidate step on every keystroke.

[benheap]

Please can this pull request be assessed and accepted as soon as possible as we have been waiting a long time for a change that would improve this plugin's responsiveness

[shayzluf]

We would like you to merge the fix as soon as possible

[nevoalm]

it would be great to get the changes!!!

[snipem]

We are waiting for this aswell

Update:
I was able to build the Eclipse plugin for myself based on rimesc's fork and the instructions in BUILD.markdown.
The JBehave Eclipse editor is now fast even with big stories (270 scenarios in one file). Please accept the patch, so that JBehave is usable in a production environment eventually.

Remarks:
I've used a Linux based Maven 3.0.5 build. My first attempt with Maven 3.2.1 failed due to an exception raising from Tycho (see https://stackoverflow.com/questions/18058419/maven-nattable-cleaninstall-failure). This behaviour is likely to be unrelated with rimesc's patch.

Update:
Searching with CTRL+F isn't working properly

[benheap]

Still waiting for this pull request to be merged, are there concerns around it? I believe the CTRL+F issue mentioned in the comment above was pre-existing

[dertseha]

@benheap as far as I remember, PRs are only considered if there is a corresponding issue in their tracker open. Did you create one?
(Yes, I'd also appreciate a performance boost :)

[benheap]

@dertseha I raised #1 a good while back (as you can tell from the issue number :) ) but don't know if thats in the pull request

[benheap]

to be honest, most of our team are using IntelliJ now anyway but for those still using eclipse this does affect them in their day to day writing of stories

[rimesc]

I referenced issue #6 in the pull request because the profiling data (screenshot) attached to that bug matches what I was seeing and what the changes should address. It may also address issue #1 although it obviously only fixes one of the possible performance bottlenecks.

[dertseha]

@benheap I meant the Jira tracker of the project, which is used as a base for everything. But Paul Burton over there just re-referenced this issue here: https://jira.codehaus.org/browse/JBEHAVE-889

[paul-barton]

I created a new improvement request in codehaus for this pull request: https://jira.codehaus.org/browse/JBEHAVE-1023