On Wed, 11 May 2022 at 22:22, Reuben Thomas wrote:
>
> Yes. I'll revise the patch.
>
Patch updated, now with correct (I hope!) documentation for \s and \S,
modeled on that for \w and \W. (And with Bruno's stray comma removed.)
--
https://rrt.sc3d.org
From 1348c63b5b4cb1b47b846f8f8299ff325f70c9
On Wed, 11 May 2022 at 21:49, Paul Eggert wrote:
> On 5/11/22 11:09, Reuben Thomas wrote:
> > Sorry, I don't follow. The concrete example given is: \Sw matches any
> > character that is
> > not word-constituent. That seems to be [^[:alnum:]]?
>
> In glibc regex, \Sw matches a nonspace followed by
On 5/11/22 11:09, Reuben Thomas wrote:
Sorry, I don't follow. The concrete example given is: \Sw matches any
character that is
not word-constituent. That seems to be [^[:alnum:]]?
In glibc regex, \Sw matches a nonspace followed by a 'w'. That is, it is
equivalent to [^[:space:]]w and it has a
On Wed, 11 May 2022 at 18:25, Paul Eggert wrote:
>
> Sorry, I should have been more specific. In glibc regex, \s is a synonym
> for [[:space:]] and \S is a synonym for [^[:space:]], so the discussion
> in regex.texi of @samp{\s@var{class}} etc. is wrong on a syntactic level
> not just a semantic
On 5/11/22 09:37, Reuben Thomas wrote:
Only thing I spotted offhand was that \s and \S mean something entirely
different in glibc as syntax classes are not programmable.
I think the documentation as I've edited it is correct.
Sorry, I should have been more specific. In glibc regex, \s is a sy
On Wed, 11 May 2022 at 17:26, Paul Eggert wrote:
>
> Only thing I spotted offhand was that \s and \S mean something entirely
> different in glibc as syntax classes are not programmable.
>
I think the documentation as I've edited it is correct. Perhaps it should
say "character classes" instead of
On 5/11/22 04:18, Bruno Haible wrote:
Reuben Thomas wrote:
I'm happy to prepare a patch in this case. I would simply remove all
mention of syntax tables, as that functionality is no longer available.
Attached.
Thanks! Looks good to me, except that the comma in line 111 is superfluous.
Paul,
On Wed, 11 May 2022 at 12:18, Bruno Haible wrote:
> Reuben Thomas wrote:
> > > I'm happy to prepare a patch in this case. I would simply remove all
> > > mention of syntax tables, as that functionality is no longer available.
> >
> > Attached.
>
> Thanks! Looks good to me, except that the comma i
Reuben Thomas wrote:
> > I'm happy to prepare a patch in this case. I would simply remove all
> > mention of syntax tables, as that functionality is no longer available.
>
> Attached.
Thanks! Looks good to me, except that the comma in line 111 is superfluous.
Paul, OK with you as well?
Bruno
On Wed, 11 May 2022 at 09:15, Reuben Thomas wrote:
>
> I'm happy to prepare a patch in this case. I would simply remove all
> mention of syntax tables, as that functionality is no longer available.
>
Attached. Here's the commit message to explain what I've done:
Remove mention of both Emacs
On Wed, 11 May 2022 at 03:11, Bruno Haible wrote:
>
> I'd suggest to keep it. If we don't have time for a deep overhaul: please
> just tell me which nodes of [1] have inaccurate information, and I'll add a
> big warning "Note: The information on this page is out-of-date!" in each.
>
I would like
Paul Eggert wrote:
> Oh my. For years I thought that gnulib/doc/regex.texi documents the
> regular expressions supported by glibc (and by Gnulib, which mimics
> glibc). Unfortunately it appears that I am wrong, and it's documentation
> for the old GNU regex package (however, with some edits by m
12 matches
Mail list logo
