all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
       [not found] ` <20180616204653.86AFC203CB@vcs0.savannah.gnu.org>
@ 2018-06-17 18:42   ` Stefan Monnier
  2018-06-17 18:51     ` Daniel Colascione
  0 siblings, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2018-06-17 18:42 UTC (permalink / raw)
  To: emacs-devel; +Cc: Daniel Colascione

>     (unfreeze_pattern, freeze_pattern): New functions.
>     (compile_pattern): Return a regexp_cache pointer instead of the
>     re_pattern_buffer, allowing callers to use `freeze_pattern' if
>     needed.  Do not consider busy patterns as cache hit candidates;
>     error if we run out of non-busy cache entries.

IIRC the main/only reason why you can't use a compiled pattern in
a reentrant way is because the \{N,M\} repetitions use a counter that's
stored directly within the compiled pattern.

But these are fairly rare.

So we could easily change the code to add a boolean stating whether there
is such a repetition-counter in the pattern, and if there isn't then
"freeze" can just do nothing because we can freely use that pattern
multiple times at the same time.


        Stefan



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-17 18:42   ` [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match Stefan Monnier
@ 2018-06-17 18:51     ` Daniel Colascione
  2018-06-17 19:18       ` Daniel Colascione
                         ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: Daniel Colascione @ 2018-06-17 18:51 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Daniel Colascione, emacs-devel

>>     (unfreeze_pattern, freeze_pattern): New functions.
>>     (compile_pattern): Return a regexp_cache pointer instead of the
>>     re_pattern_buffer, allowing callers to use `freeze_pattern' if
>>     needed.  Do not consider busy patterns as cache hit candidates;
>>     error if we run out of non-busy cache entries.
>
> IIRC the main/only reason why you can't use a compiled pattern in
> a reentrant way is because the \{N,M\} repetitions use a counter that's
> stored directly within the compiled pattern.
>
> But these are fairly rare.
>
> So we could easily change the code to add a boolean stating whether there
> is such a repetition-counter in the pattern, and if there isn't then
> "freeze" can just do nothing because we can freely use that pattern
> multiple times at the same time.

Good idea. My reading of the "smart jump" stuff in regex.c suggested that
we use the optimization for _all_ greedy Kleene star constructs though,
not just the bounded ones. Am I wrong?

But anyway, I think the regex code needs a major overhaul.  I was actually
thinking about forking and vendoring RE2. Granted, having done that, you'd
need a C++ compiler to build Emacs, but it's probably one of the better
actively-maintained DFA-based regex engines around.




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-17 18:51     ` Daniel Colascione
@ 2018-06-17 19:18       ` Daniel Colascione
  2018-06-17 19:34         ` Stefan Monnier
  2018-06-17 19:30       ` Stefan Monnier
  2018-06-18 15:59       ` Perry E. Metzger
  2 siblings, 1 reply; 36+ messages in thread
From: Daniel Colascione @ 2018-06-17 19:18 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Daniel Colascione, Stefan Monnier, emacs-devel

>>>     (unfreeze_pattern, freeze_pattern): New functions.
>>>     (compile_pattern): Return a regexp_cache pointer instead of the
>>>     re_pattern_buffer, allowing callers to use `freeze_pattern' if
>>>     needed.  Do not consider busy patterns as cache hit candidates;
>>>     error if we run out of non-busy cache entries.
>>
>> IIRC the main/only reason why you can't use a compiled pattern in
>> a reentrant way is because the \{N,M\} repetitions use a counter that's
>> stored directly within the compiled pattern.
>>
>> But these are fairly rare.
>>
>> So we could easily change the code to add a boolean stating whether
>> there
>> is such a repetition-counter in the pattern, and if there isn't then
>> "freeze" can just do nothing because we can freely use that pattern
>> multiple times at the same time.
>
> Good idea. My reading of the "smart jump" stuff in regex.c suggested that
> we use the optimization for _all_ greedy Kleene star constructs though,
> not just the bounded ones. Am I wrong?

Oh, yeah. One more thing. The busy flag isn't *just* to prevent the regex
bytecode engine confusing itself with self-modifying bytecode. It also
serves to protect the cache slot holding the regex pattern from reuse,
which would be disastrous whether or not the bytecode of a particular
pattern happens to be mutable. Under your proposal, we can get cache hits
on busy patterns, but we still have to mark them busy in the first place
so we can prevent this reuse.




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-17 18:51     ` Daniel Colascione
  2018-06-17 19:18       ` Daniel Colascione
@ 2018-06-17 19:30       ` Stefan Monnier
  2018-06-18 15:59       ` Perry E. Metzger
  2 siblings, 0 replies; 36+ messages in thread
From: Stefan Monnier @ 2018-06-17 19:30 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

> Good idea. My reading of the "smart jump" stuff in regex.c suggested that
> we use the optimization for _all_ greedy Kleene star constructs though,
> not just the bounded ones. Am I wrong?

Oh, right, I forgot about that lazy optimization.  We'd need to fix this
so the optimization is performed eagerly.

> But anyway, I think the regex code needs a major overhaul.

Yes, but it's a fairly major project.

> I was actually thinking about forking and vendoring RE2.  Granted,
> having done that, you'd need a C++ compiler to build Emacs, but it's
> probably one of the better actively-maintained DFA-based regex
> engines around.

Yes, it's a nice library, but we'd need to add support for
back-references, which doesn't seem straightforward (I think the
easiest would be to fallback on the old regex engine when backrefs are
present, but keeping two completely different regexp engines is a real
PITA).


        Stefan



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-17 19:18       ` Daniel Colascione
@ 2018-06-17 19:34         ` Stefan Monnier
  2018-06-17 19:50           ` Daniel Colascione
  0 siblings, 1 reply; 36+ messages in thread
From: Stefan Monnier @ 2018-06-17 19:34 UTC (permalink / raw)
  To: emacs-devel

> Oh, yeah. One more thing. The busy flag isn't *just* to prevent the regex
> bytecode engine confusing itself with self-modifying bytecode. It also
> serves to protect the cache slot holding the regex pattern from reuse,
> which would be disastrous whether or not the bytecode of a particular
> pattern happens to be mutable.

It doesn't have to be disastrous *if* we complexify the code such that
removing a pattern from the cache doesn't inevitably free that pattern ;-)
[ But, yes, we'd still need to mark the pattern as "busy" in order to
  know when it can be freed.  ]


        Stefan




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-17 19:34         ` Stefan Monnier
@ 2018-06-17 19:50           ` Daniel Colascione
  0 siblings, 0 replies; 36+ messages in thread
From: Daniel Colascione @ 2018-06-17 19:50 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

>> Oh, yeah. One more thing. The busy flag isn't *just* to prevent the
>> regex
>> bytecode engine confusing itself with self-modifying bytecode. It also
>> serves to protect the cache slot holding the regex pattern from reuse,
>> which would be disastrous whether or not the bytecode of a particular
>> pattern happens to be mutable.
>
> It doesn't have to be disastrous *if* we complexify the code such that
> removing a pattern from the cache doesn't inevitably free that pattern ;-)
> [ But, yes, we'd still need to mark the pattern as "busy" in order to
>   know when it can be freed.  ]

Sure. And at that point, we might as well make compiled patterns into
GC-able heap objects. That's probably a good idea, but it's a bigger
project.




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-17 18:51     ` Daniel Colascione
  2018-06-17 19:18       ` Daniel Colascione
  2018-06-17 19:30       ` Stefan Monnier
@ 2018-06-18 15:59       ` Perry E. Metzger
  2018-06-18 17:49         ` Daniel Colascione
  2018-06-18 23:25         ` Richard Stallman
  2 siblings, 2 replies; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-18 15:59 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Stefan Monnier, emacs-devel

On Sun, 17 Jun 2018 11:51:33 -0700 "Daniel Colascione"
<dancol@dancol.org> wrote:
> But anyway, I think the regex code needs a major overhaul.  I was
> actually thinking about forking and vendoring RE2. Granted, having
> done that, you'd need a C++ compiler to build Emacs, but it's
> probably one of the better actively-maintained DFA-based regex
> engines around.

I think needing C++ makes this less than the most obvious choice.

I think the right thing would be to use TRE if we could get Ville
Laurikari to let someone else be the maintainer. Sadly right now it
seems unmaintained and has been for years, but it's fast, complete,
and has the ability to handle things like gap buffers.

This would also give Emacs access to an approximate match facility,
which would be a very neat thing. I often would like to do
approximate searches, and there's no way to do that right now. TRE
would let us do it.

But again, that would be contingent on someone else taking over
maintenance and fixing the backlog of issues it has right now.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-18 15:59       ` Perry E. Metzger
@ 2018-06-18 17:49         ` Daniel Colascione
  2018-06-19 13:40           ` Perry E. Metzger
  2018-06-18 23:25         ` Richard Stallman
  1 sibling, 1 reply; 36+ messages in thread
From: Daniel Colascione @ 2018-06-18 17:49 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: Daniel Colascione, Stefan Monnier, emacs-devel

> On Sun, 17 Jun 2018 11:51:33 -0700 "Daniel Colascione"
> <dancol@dancol.org> wrote:
>> But anyway, I think the regex code needs a major overhaul.  I was
>> actually thinking about forking and vendoring RE2. Granted, having
>> done that, you'd need a C++ compiler to build Emacs, but it's
>> probably one of the better actively-maintained DFA-based regex
>> engines around.
>
> I think needing C++ makes this less than the most obvious choice.

Why? C++ is everywhere these days. I'm in no hurry to move the Emacs core
to C++, but requiring a C++ compiler for the sake of some dependency
shouldn't be a problem. It's good enough for GDB.

>
> I think the right thing would be to use TRE if we could get Ville
> Laurikari to let someone else be the maintainer. Sadly right now it
> seems unmaintained and has been for years, but it's fast, complete,
> and has the ability to handle things like gap buffers.

Last time I looked, many years ago, there were several bugs (or
differences between TRE and POSIX anyway)




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-18 15:59       ` Perry E. Metzger
  2018-06-18 17:49         ` Daniel Colascione
@ 2018-06-18 23:25         ` Richard Stallman
  2018-06-19  1:30           ` Perry E. Metzger
  1 sibling, 1 reply; 36+ messages in thread
From: Richard Stallman @ 2018-06-18 23:25 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: dancol, monnier, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

What is TRE?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-18 23:25         ` Richard Stallman
@ 2018-06-19  1:30           ` Perry E. Metzger
  2018-06-19 22:54             ` Richard Stallman
  0 siblings, 1 reply; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19  1:30 UTC (permalink / raw)
  To: Richard Stallman; +Cc: dancol, monnier, emacs-devel

On Mon, 18 Jun 2018 19:25:04 -0400 Richard Stallman <rms@gnu.org>
wrote:
> What is TRE?

It's a fairly nice regular expression engine, with excellent
performance and the unique feature of doing approximate matching.

https://laurikari.net/tre/about/

code is at

https://github.com/laurikari/tre/

The unfortunate bit is that the author seems to have abandoned it a
few years ago.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-18 17:49         ` Daniel Colascione
@ 2018-06-19 13:40           ` Perry E. Metzger
  2018-06-19 13:44             ` Perry E. Metzger
  0 siblings, 1 reply; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 13:40 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Stefan Monnier, emacs-devel

On Mon, 18 Jun 2018 10:49:46 -0700 "Daniel Colascione"
<dancol@dancol.org> wrote:
> > I think the right thing would be to use TRE if we could get Ville
> > Laurikari to let someone else be the maintainer. Sadly right now
> > it seems unmaintained and has been for years, but it's fast,
> > complete, and has the ability to handle things like gap buffers.  
> 
> Last time I looked, many years ago, there were several bugs (or
> differences between TRE and POSIX anyway)

Bugs yes, but the POSIX conformance was pretty strict. As I said, he
seemed to have abandoned the thing, but the bones are pretty good.
Someone could just fork it and implement all the patches people have
been contributing that have been languishing in the github issue
trackers.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 13:40           ` Perry E. Metzger
@ 2018-06-19 13:44             ` Perry E. Metzger
  2018-06-19 13:49               ` Daniel Colascione
  0 siblings, 1 reply; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 13:44 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Stefan Monnier, emacs-devel

On Tue, 19 Jun 2018 09:40:05 -0400 "Perry E. Metzger"
<perry@piermont.com> wrote:
> On Mon, 18 Jun 2018 10:49:46 -0700 "Daniel Colascione"
> <dancol@dancol.org> wrote:
> > > I think the right thing would be to use TRE if we could get
> > > Ville Laurikari to let someone else be the maintainer. Sadly
> > > right now it seems unmaintained and has been for years, but
> > > it's fast, complete, and has the ability to handle things like
> > > gap buffers.    
> > 
> > Last time I looked, many years ago, there were several bugs (or
> > differences between TRE and POSIX anyway)  
> 
> Bugs yes, but the POSIX conformance was pretty strict. As I said, he
> seemed to have abandoned the thing, but the bones are pretty good.
> Someone could just fork it and implement all the patches people have
> been contributing that have been languishing in the github issue
> trackers.

Oh, and re2 isn't built for POSIX compliance. It has no constructs
that require backtracking etc.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 13:44             ` Perry E. Metzger
@ 2018-06-19 13:49               ` Daniel Colascione
  2018-06-19 14:30                 ` Perry E. Metzger
  0 siblings, 1 reply; 36+ messages in thread
From: Daniel Colascione @ 2018-06-19 13:49 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: Stefan Monnier, emacs-devel

On 06/19/2018 06:44 AM, Perry E. Metzger wrote:
> On Tue, 19 Jun 2018 09:40:05 -0400 "Perry E. Metzger"
> <perry@piermont.com> wrote:
>> On Mon, 18 Jun 2018 10:49:46 -0700 "Daniel Colascione"
>> <dancol@dancol.org> wrote:
>>>> I think the right thing would be to use TRE if we could get
>>>> Ville Laurikari to let someone else be the maintainer. Sadly
>>>> right now it seems unmaintained and has been for years, but
>>>> it's fast, complete, and has the ability to handle things like
>>>> gap buffers.
>>>
>>> Last time I looked, many years ago, there were several bugs (or
>>> differences between TRE and POSIX anyway)
>>
>> Bugs yes, but the POSIX conformance was pretty strict. As I said, he
>> seemed to have abandoned the thing, but the bones are pretty good.
>> Someone could just fork it and implement all the patches people have
>> been contributing that have been languishing in the github issue
>> trackers.
> 
> Oh, and re2 isn't built for POSIX compliance. It has no constructs
> that require backtracking etc.

No DFA engine can do backtracking.



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 13:49               ` Daniel Colascione
@ 2018-06-19 14:30                 ` Perry E. Metzger
  2018-06-19 14:33                   ` Perry E. Metzger
  2018-06-19 14:46                   ` Daniel Colascione
  0 siblings, 2 replies; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 14:30 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Stefan Monnier, emacs-devel

On Tue, 19 Jun 2018 06:49:03 -0700 Daniel Colascione
<dancol@dancol.org> wrote:
> On 06/19/2018 06:44 AM, Perry E. Metzger wrote:
> > On Tue, 19 Jun 2018 09:40:05 -0400 "Perry E. Metzger"
> > <perry@piermont.com> wrote:  
> >> On Mon, 18 Jun 2018 10:49:46 -0700 "Daniel Colascione"
> >> <dancol@dancol.org> wrote:  
> >>>> I think the right thing would be to use TRE if we could get
> >>>> Ville Laurikari to let someone else be the maintainer. Sadly
> >>>> right now it seems unmaintained and has been for years, but
> >>>> it's fast, complete, and has the ability to handle things like
> >>>> gap buffers.  
> >>>
> >>> Last time I looked, many years ago, there were several bugs (or
> >>> differences between TRE and POSIX anyway)  
> >>
> >> Bugs yes, but the POSIX conformance was pretty strict. As I
> >> said, he seemed to have abandoned the thing, but the bones are
> >> pretty good. Someone could just fork it and implement all the
> >> patches people have been contributing that have been languishing
> >> in the github issue trackers.  
> > 
> > Oh, and re2 isn't built for POSIX compliance. It has no constructs
> > that require backtracking etc.  
> 
> No DFA engine can do backtracking.

Correct, but there are regexp libraries that will switch between DFA
and non-DFA implementations depending on whether the regexp has
constructs in it that require backtracking.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 14:30                 ` Perry E. Metzger
@ 2018-06-19 14:33                   ` Perry E. Metzger
  2018-06-19 14:48                     ` Daniel Colascione
  2018-06-19 14:46                   ` Daniel Colascione
  1 sibling, 1 reply; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 14:33 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Stefan Monnier, emacs-devel

On Tue, 19 Jun 2018 10:30:02 -0400 "Perry E. Metzger"
<perry@piermont.com> wrote:
> > > Oh, and re2 isn't built for POSIX compliance. It has no
> > > constructs that require backtracking etc.    
> > 
> > No DFA engine can do backtracking.  
> 
> Correct, but there are regexp libraries that will switch between DFA
> and non-DFA implementations depending on whether the regexp has
> constructs in it that require backtracking.

Just to be explicit: TRE does this, IIRC. It certainly implements
backreferences, which re2 does not. (And, it has provisions in its
API for handling things like gap buffers. The main problem is it is
unmaintained.)

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 14:30                 ` Perry E. Metzger
  2018-06-19 14:33                   ` Perry E. Metzger
@ 2018-06-19 14:46                   ` Daniel Colascione
  2018-06-19 14:58                     ` Andreas Schwab
  1 sibling, 1 reply; 36+ messages in thread
From: Daniel Colascione @ 2018-06-19 14:46 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: Stefan Monnier, emacs-devel

On 06/19/2018 07:30 AM, Perry E. Metzger wrote:
> On Tue, 19 Jun 2018 06:49:03 -0700 Daniel Colascione
> <dancol@dancol.org> wrote:
>> On 06/19/2018 06:44 AM, Perry E. Metzger wrote:
>>> On Tue, 19 Jun 2018 09:40:05 -0400 "Perry E. Metzger"
>>> <perry@piermont.com> wrote:
>>>> On Mon, 18 Jun 2018 10:49:46 -0700 "Daniel Colascione"
>>>> <dancol@dancol.org> wrote:
>>>>>> I think the right thing would be to use TRE if we could get
>>>>>> Ville Laurikari to let someone else be the maintainer. Sadly
>>>>>> right now it seems unmaintained and has been for years, but
>>>>>> it's fast, complete, and has the ability to handle things like
>>>>>> gap buffers.
>>>>>
>>>>> Last time I looked, many years ago, there were several bugs (or
>>>>> differences between TRE and POSIX anyway)
>>>>
>>>> Bugs yes, but the POSIX conformance was pretty strict. As I
>>>> said, he seemed to have abandoned the thing, but the bones are
>>>> pretty good. Someone could just fork it and implement all the
>>>> patches people have been contributing that have been languishing
>>>> in the github issue trackers.
>>>
>>> Oh, and re2 isn't built for POSIX compliance. It has no constructs
>>> that require backtracking etc.
>>
>> No DFA engine can do backtracking.
> 
> Correct, but there are regexp libraries that will switch between DFA
> and non-DFA implementations depending on whether the regexp has
> constructs in it that require backtracking

Sure, but the DFA and non-DFA engines can vary independently so long as 
they understand the same language, modulo backreference support.

IMHO, back reference support is an old unix mistake. I can't think of a 
time when I've wanted to actually use them, but their theoretical use is 
still a hindrance. One option would be to just deprecate them.



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 14:33                   ` Perry E. Metzger
@ 2018-06-19 14:48                     ` Daniel Colascione
  2018-06-19 15:37                       ` Perry E. Metzger
  0 siblings, 1 reply; 36+ messages in thread
From: Daniel Colascione @ 2018-06-19 14:48 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: Stefan Monnier, emacs-devel

On 06/19/2018 07:33 AM, Perry E. Metzger wrote:
> On Tue, 19 Jun 2018 10:30:02 -0400 "Perry E. Metzger"
> <perry@piermont.com> wrote:
>>>> Oh, and re2 isn't built for POSIX compliance. It has no
>>>> constructs that require backtracking etc.
>>>
>>> No DFA engine can do backtracking.
>>
>> Correct, but there are regexp libraries that will switch between DFA
>> and non-DFA implementations depending on whether the regexp has
>> constructs in it that require backtracking.
> 
> Just to be explicit: TRE does this, IIRC. It certainly implements
> backreferences, which re2 does not. (And, it has provisions in its
> API for handling things like gap buffers. The main problem is it is
> unmaintained.)

If we did want to adopt TRE, we'd have to add supports for PCRE-like 
callouts for implementing Emacs-specific assertions. (PCRE itself has 
the opposite problem: explicit support for pluggable callouts, but no 
support for an iterator API.)

I'd also like to better understand the specific remaining differences 
between POSIX regular expression semantics and what TRE implements, 
whether this difference is intentional or not. And I'd also like to 
understand how we can give the engine Emacs-regex semantics instead of 
POSIX ones. (Very few people use the POSIX mode of Emacs regex matching.)

I'm also not sure how copyright assignment would work for abandonware.



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-19 14:46                   ` Daniel Colascione
@ 2018-06-19 14:58                     ` Andreas Schwab
  2018-06-19 15:32                       ` Perry E. Metzger
  0 siblings, 1 reply; 36+ messages in thread
From: Andreas Schwab @ 2018-06-19 14:58 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel, Stefan Monnier, Perry E. Metzger

On Jun 19 2018, Daniel Colascione <dancol@dancol.org> wrote:

> IMHO, back reference support is an old unix mistake. I can't think of a
> time when I've wanted to actually use them, but their theoretical use is
> still a hindrance. One option would be to just deprecate them.

There are quite a few uses in Emacs.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 14:58                     ` Andreas Schwab
@ 2018-06-19 15:32                       ` Perry E. Metzger
  0 siblings, 0 replies; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 15:32 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Daniel Colascione, Stefan Monnier, emacs-devel

On Tue, 19 Jun 2018 16:58:15 +0200 Andreas Schwab <schwab@suse.de>
wrote:
> On Jun 19 2018, Daniel Colascione <dancol@dancol.org> wrote:
> 
> > IMHO, back reference support is an old unix mistake. I can't
> > think of a time when I've wanted to actually use them, but their
> > theoretical use is still a hindrance. One option would be to just
> > deprecate them.  
> 
> There are quite a few uses in Emacs.

I agree that they're a mistake, but we're a bit stuck. The right
thing, I think, is using a library like TRE that uses a fast
algorithm whenever a backreference isn't in use.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 14:48                     ` Daniel Colascione
@ 2018-06-19 15:37                       ` Perry E. Metzger
  2018-06-19 16:20                         ` Paul Eggert
  0 siblings, 1 reply; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 15:37 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Stefan Monnier, emacs-devel

On Tue, 19 Jun 2018 07:48:28 -0700 Daniel Colascione
<dancol@dancol.org> wrote:
> If we did want to adopt TRE, we'd have to add supports for
> PCRE-like callouts for implementing Emacs-specific assertions.
> (PCRE itself has the opposite problem: explicit support for
> pluggable callouts, but no support for an iterator API.)

Probably.

> I'd also like to better understand the specific remaining
> differences between POSIX regular expression semantics and what TRE
> implements, whether this difference is intentional or not.

The documentation is, I think, pretty good on this.

> And I'd also like to understand how we can give the engine
> Emacs-regex semantics instead of POSIX ones. (Very few people use
> the POSIX mode of Emacs regex matching.)
>
> I'm also not sure how copyright assignment would work for
> abandonware.

I don't think we could get a copyright assignment. It would have to be
maintained as a separate package that Emacs depended on.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 15:37                       ` Perry E. Metzger
@ 2018-06-19 16:20                         ` Paul Eggert
  2018-06-19 16:27                           ` Perry E. Metzger
                                             ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: Paul Eggert @ 2018-06-19 16:20 UTC (permalink / raw)
  To: Perry E. Metzger, Daniel Colascione; +Cc: Stefan Monnier, emacs-devel

If we're going to go to that much work, why not use glibc regex? It uses a DFA 
and falls back on backtracking only when needed. Although glibc regex isn't 
maintained that well, it's at least maintained, which TRE is not. And it does 
have some advantages: it has an API that is like Emacs src/regex.c, and it won't 
have any licensing issues. Its main disadvantage (it doesn't support split 
buffers) could be overcome fairly easily, either by adding support for that back 
into the library, or arranging for a single array whenever the regex matcher is 
called.



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-19 16:20                         ` Paul Eggert
@ 2018-06-19 16:27                           ` Perry E. Metzger
  2018-06-19 17:46                             ` Stefan Monnier
  2018-06-19 16:54                           ` John Wiegley
  2018-06-19 18:03                           ` Andreas Schwab
  2 siblings, 1 reply; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 16:27 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Daniel Colascione, Stefan Monnier, emacs-devel

On Tue, 19 Jun 2018 09:20:43 -0700 Paul Eggert <eggert@cs.ucla.edu>
wrote:
> If we're going to go to that much work, why not use glibc regex? It
> uses a DFA and falls back on backtracking only when needed.
> Although glibc regex isn't maintained that well, it's at least
> maintained, which TRE is not. And it does have some advantages: it
> has an API that is like Emacs src/regex.c, and it won't have any
> licensing issues. Its main disadvantage (it doesn't support split
> buffers) could be overcome fairly easily, either by adding support
> for that back into the library, or arranging for a single array
> whenever the regex matcher is called.

That's also an option. I really like the idea of being able to do
approximate searches in files, but it's not that big a deal. (Does
the glibc stuff have appropriate unicode support etc?)

Truthfully, my biggest interest is in seeing the default regex syntax
migrate to something much more modern, and that can be done
regardless of which engine we use.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-19 16:20                         ` Paul Eggert
  2018-06-19 16:27                           ` Perry E. Metzger
@ 2018-06-19 16:54                           ` John Wiegley
  2018-06-19 17:04                             ` Perry E. Metzger
  2018-06-19 18:04                             ` Paul Eggert
  2018-06-19 18:03                           ` Andreas Schwab
  2 siblings, 2 replies; 36+ messages in thread
From: John Wiegley @ 2018-06-19 16:54 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Daniel Colascione, emacs-devel, Stefan Monnier, Perry E. Metzger

>>>>> "PE" == Paul Eggert <eggert@cs.ucla.edu> writes:

PE> If we're going to go to that much work, why not use glibc regex? It uses a
PE> DFA and falls back on backtracking only when needed. Although glibc regex
PE> isn't maintained that well, it's at least maintained, which TRE is not.
PE> And it does have some advantages: it has an API that is like Emacs
PE> src/regex.c, and it won't have any licensing issues. Its main disadvantage
PE> (it doesn't support split buffers) could be overcome fairly easily, either
PE> by adding support for that back into the library, or arranging for a
PE> single array whenever the regex matcher is called.

If we do find a problem with it, how long will it take before the fix we need
is propagated everywhere it needs to go?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 16:54                           ` John Wiegley
@ 2018-06-19 17:04                             ` Perry E. Metzger
  2018-06-19 18:20                               ` John Wiegley
  2018-06-19 18:04                             ` Paul Eggert
  1 sibling, 1 reply; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 17:04 UTC (permalink / raw)
  To: John Wiegley; +Cc: Paul Eggert, Daniel Colascione, Stefan Monnier, emacs-devel

On Tue, 19 Jun 2018 09:54:50 -0700 "John Wiegley" <johnw@gnu.org>
wrote:
> >>>>> "PE" == Paul Eggert <eggert@cs.ucla.edu> writes:  
> 
> PE> If we're going to go to that much work, why not use glibc
> PE> regex? It uses a DFA and falls back on backtracking only when
> PE> needed. Although glibc regex isn't maintained that well, it's
> PE> at least maintained, which TRE is not. And it does have some
> PE> advantages: it has an API that is like Emacs src/regex.c, and
> PE> it won't have any licensing issues. Its main disadvantage (it
> PE> doesn't support split buffers) could be overcome fairly easily,
> PE> either by adding support for that back into the library, or
> PE> arranging for a single array whenever the regex matcher is
> PE> called.  
> 
> If we do find a problem with it, how long will it take before the
> fix we need is propagated everywhere it needs to go?

Which package was the referent for "it"?

-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-19 16:27                           ` Perry E. Metzger
@ 2018-06-19 17:46                             ` Stefan Monnier
  2018-06-19 18:18                               ` Daniel Colascione
  2018-06-19 18:26                               ` Perry E. Metzger
  0 siblings, 2 replies; 36+ messages in thread
From: Stefan Monnier @ 2018-06-19 17:46 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: Paul Eggert, Daniel Colascione, emacs-devel

> Truthfully, my biggest interest is in seeing the default regex syntax
> migrate to something much more modern, and that can be done
> regardless of which engine we use.

Not only that: changing the engine won't help in changing the syntax.


        Stefan



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-19 16:20                         ` Paul Eggert
  2018-06-19 16:27                           ` Perry E. Metzger
  2018-06-19 16:54                           ` John Wiegley
@ 2018-06-19 18:03                           ` Andreas Schwab
  2018-06-19 18:48                             ` Paul Eggert
  2 siblings, 1 reply; 36+ messages in thread
From: Andreas Schwab @ 2018-06-19 18:03 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Daniel Colascione, emacs-devel, Stefan Monnier, Perry E. Metzger

On Jun 19 2018, Paul Eggert <eggert@cs.ucla.edu> wrote:

> If we're going to go to that much work, why not use glibc regex?

It doesn't support a gap either.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 16:54                           ` John Wiegley
  2018-06-19 17:04                             ` Perry E. Metzger
@ 2018-06-19 18:04                             ` Paul Eggert
  2018-06-19 18:16                               ` Daniel Colascione
  1 sibling, 1 reply; 36+ messages in thread
From: Paul Eggert @ 2018-06-19 18:04 UTC (permalink / raw)
  To: Perry E. Metzger, Daniel Colascione, Stefan Monnier, emacs-devel

On 06/19/2018 09:54 AM, John Wiegley wrote:
> If we do find a problem with it, how long will it take before the fix we need
> is propagated everywhere it needs to go?

It shouldn't take much time at all to propagate Emacs-related regex 
changes back to Gnulib, which is commonly used by GNU applications like 
'grep' so that they can assume the same regex API everywhere. It would 
take more time to propagate the changes back into Glibc, but the 
distance between Gnulib regex and Glibc regex is relatively small (it's 
way less than the distance between Emacs regex and Glibc regex) and it's 
feasible to do that propagation (mostly, this means to jump the Glibc 
bureaucratic hurdles).




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 18:04                             ` Paul Eggert
@ 2018-06-19 18:16                               ` Daniel Colascione
  2018-06-19 18:26                                 ` Paul Eggert
  0 siblings, 1 reply; 36+ messages in thread
From: Daniel Colascione @ 2018-06-19 18:16 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Daniel Colascione, emacs-devel, Stefan Monnier, Perry E. Metzger

> On 06/19/2018 09:54 AM, John Wiegley wrote:
>> If we do find a problem with it, how long will it take before the fix we
>> need
>> is propagated everywhere it needs to go?
>
> It shouldn't take much time at all to propagate Emacs-related regex
> changes back to Gnulib, which is commonly used by GNU applications like
> 'grep' so that they can assume the same regex API everywhere. It would
> take more time to propagate the changes back into Glibc, but the
> distance between Gnulib regex and Glibc regex is relatively small (it's
> way less than the distance between Emacs regex and Glibc regex) and it's
> feasible to do that propagation (mostly, this means to jump the Glibc
> bureaucratic hurdles).
>

Do you think the glib regex maintainers would be amenable to adding 1)
external iterator support (that we'd use to deal with the gap), and 2)
user-pluggable callouts (which we'd use to implement Emacs-specific
assertions)? I'd rather not have a huge pile of ifdefs the way we do now.
I'd much prefer using maintained extension points.




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 17:46                             ` Stefan Monnier
@ 2018-06-19 18:18                               ` Daniel Colascione
  2018-06-19 18:26                               ` Perry E. Metzger
  1 sibling, 0 replies; 36+ messages in thread
From: Daniel Colascione @ 2018-06-19 18:18 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: emacs-devel, Paul Eggert, Daniel Colascione, Perry E. Metzger

>> Truthfully, my biggest interest is in seeing the default regex syntax
>> migrate to something much more modern, and that can be done
>> regardless of which engine we use.
>
> Not only that: changing the engine won't help in changing the syntax.

Right. Anyone is free to experiment with changing read-regexp today. I
think a combination of rx input with paredit* for easier editing might
work pretty well, maybe with a mode key to distinguish input modalities.

(Which gets me into more about how isearch should have multiple orthogonal
modes sharing history, not a hard distinction between the literal and
regexp cases.)

* or whatever structured editing package people use today




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-19 17:04                             ` Perry E. Metzger
@ 2018-06-19 18:20                               ` John Wiegley
  0 siblings, 0 replies; 36+ messages in thread
From: John Wiegley @ 2018-06-19 18:20 UTC (permalink / raw)
  To: Perry E. Metzger
  Cc: Paul Eggert, Daniel Colascione, Stefan Monnier, emacs-devel

>>>>> Perry E Metzger <perry@piermont.com> writes:

> Which package was the referent for "it"?

glibc regex

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match
  2018-06-19 17:46                             ` Stefan Monnier
  2018-06-19 18:18                               ` Daniel Colascione
@ 2018-06-19 18:26                               ` Perry E. Metzger
  1 sibling, 0 replies; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-19 18:26 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Paul Eggert, Daniel Colascione, emacs-devel

On Tue, 19 Jun 2018 13:46:20 -0400 Stefan Monnier
<monnier@IRO.UMontreal.CA> wrote:
> > Truthfully, my biggest interest is in seeing the default regex
> > syntax migrate to something much more modern, and that can be done
> > regardless of which engine we use.  
> 
> Not only that: changing the engine won't help in changing the
> syntax.

Precisely. So to some extent I'm less interested in the engine than I
might appear to be.

Perry
-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 18:16                               ` Daniel Colascione
@ 2018-06-19 18:26                                 ` Paul Eggert
  0 siblings, 0 replies; 36+ messages in thread
From: Paul Eggert @ 2018-06-19 18:26 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel, Stefan Monnier, Perry E. Metzger

On 06/19/2018 11:16 AM, Daniel Colascione wrote:
> Do you think the glib regex maintainers would be amenable to adding 1)
> external iterator support (that we'd use to deal with the gap), and 2)
> user-pluggable callouts (which we'd use to implement Emacs-specific
> assertions)? I'd rather not have a huge pile of ifdefs the way we do now.
> I'd much prefer using maintained extension points.

We could add those to Gnulib. I think we could also add them to Glibc 
eventually, though that would require more consensus. The main question 
to my mind is whether we'd want the extension points to be visible to 
Glibc users. If not, most likely we'd need some ifdefs, though I expect 
we wouldn't need a huge pile of them (as glibc code can assume GCC 
optimization).




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 18:03                           ` Andreas Schwab
@ 2018-06-19 18:48                             ` Paul Eggert
  0 siblings, 0 replies; 36+ messages in thread
From: Paul Eggert @ 2018-06-19 18:48 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Daniel Colascione, emacs-devel, Stefan Monnier, Perry E. Metzger

On 06/19/2018 11:03 AM, Andreas Schwab wrote:
>> If we're going to go to that much work, why not use glibc regex?
> It doesn't support a gap either.

Yes, and I noted that in my email (I called it "split buffers").

Actually, Gnulib/Glibc regex does support a gap; it's just that it's 
implemented inefficiently, and for Emacs we'd want it to be more 
efficient if we were to use it.




^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19  1:30           ` Perry E. Metzger
@ 2018-06-19 22:54             ` Richard Stallman
  2018-06-20  1:17               ` Perry E. Metzger
  0 siblings, 1 reply; 36+ messages in thread
From: Richard Stallman @ 2018-06-19 22:54 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: dancol, monnier, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's a fairly nice regular expression engine, with excellent
  > performance and the unique feature of doing approximate matching.

Sounds interesting.  I am sure we can modify the code to suit our
needs, if we want to do that.  What is its licensing?
-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-19 22:54             ` Richard Stallman
@ 2018-06-20  1:17               ` Perry E. Metzger
  2018-06-20 23:26                 ` Richard Stallman
  0 siblings, 1 reply; 36+ messages in thread
From: Perry E. Metzger @ 2018-06-20  1:17 UTC (permalink / raw)
  To: Richard Stallman; +Cc: dancol, monnier, emacs-devel

On Tue, 19 Jun 2018 18:54:37 -0400 Richard Stallman <rms@gnu.org>
wrote:
> [[[ To any NSA and FBI agents reading my email: please
> consider    ]]] [[[ whether defending the US Constitution against
> all enemies,     ]]] [[[ foreign or domestic, requires you to
> follow Snowden's example. ]]]
> 
>   > It's a fairly nice regular expression engine, with excellent
>   > performance and the unique feature of doing approximate
>   > matching.  
> 
> Sounds interesting.  I am sure we can modify the code to suit our
> needs, if we want to do that.  What is its licensing?

Two-clause BSD.
https://github.com/laurikari/tre/blob/master/LICENSE

-- 
Perry E. Metzger		perry@piermont.com



^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant;  update syntax during match
  2018-06-20  1:17               ` Perry E. Metzger
@ 2018-06-20 23:26                 ` Richard Stallman
  0 siblings, 0 replies; 36+ messages in thread
From: Richard Stallman @ 2018-06-20 23:26 UTC (permalink / raw)
  To: Perry E. Metzger; +Cc: dancol, monnier, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Two-clause BSD.
  > https://github.com/laurikari/tre/blob/master/LICENSE

Not the best choice, but it is not an obstacle to our using it.
If we make large changes we should copyleft the result.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2018-06-20 23:26 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20180616204650.8423.73499@vcs0.savannah.gnu.org>
     [not found] ` <20180616204653.86AFC203CB@vcs0.savannah.gnu.org>
2018-06-17 18:42   ` [Emacs-diffs] master 938d252 4/4: Make regex matching reentrant; update syntax during match Stefan Monnier
2018-06-17 18:51     ` Daniel Colascione
2018-06-17 19:18       ` Daniel Colascione
2018-06-17 19:34         ` Stefan Monnier
2018-06-17 19:50           ` Daniel Colascione
2018-06-17 19:30       ` Stefan Monnier
2018-06-18 15:59       ` Perry E. Metzger
2018-06-18 17:49         ` Daniel Colascione
2018-06-19 13:40           ` Perry E. Metzger
2018-06-19 13:44             ` Perry E. Metzger
2018-06-19 13:49               ` Daniel Colascione
2018-06-19 14:30                 ` Perry E. Metzger
2018-06-19 14:33                   ` Perry E. Metzger
2018-06-19 14:48                     ` Daniel Colascione
2018-06-19 15:37                       ` Perry E. Metzger
2018-06-19 16:20                         ` Paul Eggert
2018-06-19 16:27                           ` Perry E. Metzger
2018-06-19 17:46                             ` Stefan Monnier
2018-06-19 18:18                               ` Daniel Colascione
2018-06-19 18:26                               ` Perry E. Metzger
2018-06-19 16:54                           ` John Wiegley
2018-06-19 17:04                             ` Perry E. Metzger
2018-06-19 18:20                               ` John Wiegley
2018-06-19 18:04                             ` Paul Eggert
2018-06-19 18:16                               ` Daniel Colascione
2018-06-19 18:26                                 ` Paul Eggert
2018-06-19 18:03                           ` Andreas Schwab
2018-06-19 18:48                             ` Paul Eggert
2018-06-19 14:46                   ` Daniel Colascione
2018-06-19 14:58                     ` Andreas Schwab
2018-06-19 15:32                       ` Perry E. Metzger
2018-06-18 23:25         ` Richard Stallman
2018-06-19  1:30           ` Perry E. Metzger
2018-06-19 22:54             ` Richard Stallman
2018-06-20  1:17               ` Perry E. Metzger
2018-06-20 23:26                 ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.