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 Tue, May 10, 2022 at 06:01:18PM -0700, Paul Eggert wrote:
> Does anybody use gnulib/doc/regex.texi? If not, I suggest we remove it from
> Gnulib. It's not part of any package, and its presence is confusing both
> Rueben and me.
GNU m4 was considering using it for 2.0 (as documentation for the
d
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:37, Paul Eggert wrote:
> On 5/11/22 03:27, Reuben Thomas wrote:
> > Mostly in alloca.c, with one case in parse-datetime.y.
> Bruno handled alloca.c, and I did parse-datetime.y with the attached.
> Thanks for reporting it.
Thanks! I never cease to be amazed by the amoun
On 5/11/22 03:27, Reuben Thomas wrote:
Mostly in alloca.c, with one case in parse-datetime.y.
Bruno handled alloca.c, and I did parse-datetime.y with the attached.
Thanks for reporting it.From 950f04bbf18dad544c61f448206e9dc96cbe3b7a Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 11 May
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
Reuben Thomas wrote:
> Working on the regex documentation, I scanned gnulib for "#ifdef emacs",
> and found some instances (though not in the regex code). Should they be
> there? Mostly in alloca.c
And since version 23.1 (2009), Emacs does not use alloca.c any more. Therefore
this code is no longe
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
Working on the regex documentation, I scanned gnulib for "#ifdef emacs",
and found some instances (though not in the regex code). Should they be
there? Mostly in alloca.c, with one case in parse-datetime.y. As far as I
can see these are "native" gnulib modules, not maintained in sync with code
else
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
On Wed, 11 May 2022 at 02:01, Paul Eggert wrote:
>
> > Failing that, you could also try GNU Emacs's regex implementation, which
> >> is derived from GNU regex 0.12, and which may have fewer bugs than regex
> >> 0.12.
> >
> >
> > That's a good suggestion I hadn't thought of, thanks. I had a look a
17 matches
Mail list logo
