[ruby-core:28471] Re: [Feature #2759] Regexp /g and /G options

(2010/03/04 14:53), caleb clausen wrote:
> It seems to me that Michael has a burning need for this feature and
> it can't be (easily) provided any other way.

We can know how easy to provide only after implement and test it.
In this case, Michael want ONIG_OPTION_CAPTURE_GROUP and
ONIG_OPTION_DONT_CAPTURE_GROUP, but the flag he really needed
was ONIG_OPTION_CAPTURE_GROUP.

> TextMate is one of the
> foremost development environments for ruby; it should be possible to
> rewrite it entirely in ruby but the lack of this feature makes that
> it hard to run textmate bundles.


> It appears there is a patch already.

Do you really know how the patch is?

> The objections to this feature amounted to "it's complicated for
> users to understand and no-one needs it". Which would be a perfectly
> valid justification if true, but clearly Michael does need it, and
> has been willing to argue extensively for it. In short, there are
> compelling reasons to accept this feature, and very little reason to
> reject it.

I don't know what is really need by those regexps.
Oniguruma has many compile options and
our fork one has some difference from Oniguruma.
Possible traps are \d, \s, \w difference, duplicate charclass warning,
meaning of /m, Unicode properties, Capture history and so on.

If I fix this issue but some of regexp still doesn't work,
the goal of this ticket won't achieved.
So we can't start to run before the goal is concrete.

> This issue has been closed, but it ought to be reopened. As Michael's
> last comment indicates, the fix supplied (r26796) does address the
> smallest of the problems he's seeing, but the broader issue is not
> yet resolved. It's a step in the right direction, but it looks like
> his original suggested new feature needs to be implemented in its
> full glory.

I set the goal to pass following regexp:
/(?x)\G
(?=	([ ]{4}|\t)
|	[#]{1,6}\s*+
|	[ ]{,3}(?<marker>[-*_])([ ]{,2}\k<marker>){2,}[ \t]*+$
)/
And it can pass after r 26796.


Anyway, We won't simply implement what reporter says.
Better design of language needs to know the use case of each function and,
think and think the API is really suitable to the use case.
So we always want to know what is the use case,
what is the true goal the reporter want to go.
This is because some feature request is rejected
even if its implementation is easy.

See also akr's good document:
http://www.a-k-r.org/pub/howto-persuade-matz-rubykaigi2008.pdf

-- 
NARUSE, Yui <[e-mail]>