bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plain text matching with regex: RE_PLAIN


From: Reuben Thomas
Subject: Re: Plain text matching with regex: RE_PLAIN
Date: Sun, 19 Sep 2010 13:32:16 +0100

On 15 September 2010 02:54:45 UTC+1, Bruno Haible <address@hidden> wrote:
>> > Why can't you instead add \ escaping to all existing regex
>> > meta-characters
>> > that occur in the string, at which point you get the same effect without
>> > a
>> > new flag?
>>
>> Because that is error-prone (in particular, I would have to take the
>> current syntax into account).
>
> Error-prone? No, it's a function which transforms a string to a string.
> I'm sure this function has been implemented many times already. The one I
> wrote is called 'regexp-quote' [1][2].

(I meant that it would take some work to write and test it, which,
having seen the code, is certainly the case, though I'm guessing that
it took Bruno rather less time than it would have taken me.)

>> In the meantime is there any better way to use this for myself than
>> simply maintaining a variant version of GNU regex? e.g. some way of
>> maintaining a patch against gnulib...
>
> Yes, you can maintain patches against gnulib, see the gnulib documentation
> [3].

Once again, gnulib already does what I want!

Some questions, having read the documentation:

1. There doesn't seem to be a default value for --local-dir. I used
local-lib; is there a recommended value? It would be nice to have a
default, both to encourage compatible naming and to avoid the need for
--local-dir when the default value is used.

2. There's a remark that is unclear to me: "(This kind of kitchen-sink
module is not needed when you
use the @command{gnulib-tool} option @samp{--makefile-name}.)" How
does --makefile-name help in this case? Perhaps this is worth
explaining.

3. It seems to me that the structure of this section of the
documentation could be clearer: in particular, it seems that all the
things listed that you "can do" to add local code are, rather than
fixed options, consequences of the file override rules listed below.
Hence, I suggest reordering the page to first explain the rule, and
then say that "as a result, you can..." and list the things you can
do, which are effectively recommended ways to exploit the file
overrides (there may be other good ways, or other bad ways). If the
maintainers agree, I'd be happy to draft a patch for this.

-- 
http://rrt.sc3d.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]