Re: [Swig-devel] regex patches

[William S F. <ws...@fu...>]

Vadim Zeitlin wrote:

> WSF> Swig_name_regexmatch_value in patch (8) formats code to 80 chars, please 
> WSF> add a patch to use 160 chars.
> 
>  Ok, I didn't know about this rule. What other settings should be used for
> SWIG code, is "set sw=2 ts=8 noet tw=160" all I need (as you quoted vim
> version output below I hope this was an understandable question for you :-)?
> 
I use this in .vimrc:
au BufRead */swig*/* set tabstop=8 | set shiftwidth=2 | set 
softtabstop=2 | set expandtab " SWIG
au BufRead */swig*/Source/* set tabstop=8 | set shiftwidth=2 | set 
softtabstop=2 | set noexpandtab " SWIG Source

The formatting rules are really those used in the 'make beautify-file' 
target in the Source directory. This doesn't get run often though as it 
doesn't work 100%, requiring some manual fixes afterwards :(

> WSF> Then we'd also need an option to report how SWIG was built, something
> WSF> similar to what vim outputs
> WSF> options for vim:
> 
>  Currently we have
> 
> 	% swig -version
> 
> 	SWIG Version 2.0.1
> 
> 	Compiled with g++ [x86_64-unknown-linux-gnu]
> 	Please see http://www.swig.org for reporting bugs and further information
> 
> Should I just add a line "This version of SWIG has regular expression
> support." after "Compiled with" line?
> 
Let's add a new line for configured options like in vim, using +pcre for 
--with-pcre and -pcre for --without-pcre:

% swig -version

SWIG Version 2.0.1

Compiled with g++ [x86_64-unknown-linux-gnu]
Configured options: +pcre
Please see http://www.swig.org for reporting bugs and further information

> WSF> > Q3: Code handling substitutions in regex replacement part normally expects
> WSF> >     '@' to be followed by a digit but its handling of not normal cases
> WSF> >     seems inconsistent to me: A bare '@' at the end of the string is kept
> WSF> >     as is but there is no way to quote '@' anywhere else, it is just
> WSF> >     skipped silently if it's not followed by a digit. I don't think '@' is
> WSF> >     valid in identifiers in any output language anyhow but I'm not sure
> WSF> >     about this. In any case, I think that we should either provide a way to
> WSF> >     quote it anywhere (using "@@"?) or not allow it anywhere, including at
> WSF> >     the end of the string.
> WSF> > 
> WSF> I'll pass on this one, but I don't follow why SWIG's handling of @ 
> WSF> should be different to perl or any other language using regular 
> WSF> expressions. Or is this something wrong with pcre?
> 
>  SWIG uses "@1" instead of "\1" in Perl (and everywhere else). I think it's
> not a bad idea to continue to do this because it will make it simpler for
> people having code using rxspencer to upgrade and also because it avoids
> the double backslashes galores but it could be changed to use '\\' if you
> prefer.
> 
I don't think the rxspencer should dictate how we do things going 
forwards unless it is the best option. Some upgrade documentation in the 
CHANGES file will suffice, so here we can mention to use \\ instead of @ 
if we want to go this way. I really don't like the idea that the rest of 
the world uses \1 and SWIG uses @1. Why don't we accept \1 ? Aren't 
these quoted within square brackets in any case, so the C string 
escaping would not be needed? What do other C oriented languages do for 
escaping backslashes in regular expressions?


> WSF> I would go ahead and commit your patches as you supplied them and then 
> WSF> feel free to just commit any modifications as discussed or as you see fit.
> WSF> > Q4: Currently the regex isn't implicitly anchored to the beginning/end of
> WSF> >     the string. This means that regexmatch$name="Max" will match
> WSF> >     FindMaximum() which might be unexpected. You need to use "^Max$"
> WSF> >     explicitly to match this string only. I wonder if we shouldn't rather
> WSF> >     implicitly anchor the string by adding '^' and '$' to it ourselves?
> WSF> > 
> WSF> No, personally I think the default is expected and it is normal to add 
> WSF> want it.
Sorry, half my sentence got chomped. I'm just trying to say that a user 
should explicitly add "^" and "$" when needed.

> 
>  I could update the patches before you commit them if you prefer but it
> would have to wait until tomorrow as it's getting too late to start doing
> this today...
No great rush, I'll leave you to commit them as you see fit.

William