bug#41155: 26.3; regexp 99% locks up emacs

[jan via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

I've had more of a play, I see what you're saying and it makes sense.

It locks up because it's a pathological, but C-g *will* interrupt it.
My mistake was thinking it would cancel the highlight-regexp, but of
course it doesn't, emacs handles a few keyboard events then goes right
back to its inefficient scanning.

So I get a self-inflicted denial of service. That may be a problem but
it isn't the one I originally reported.

I'm not sure the regexp is in fact working correctly but I'll leave it for now.

Would someone consider this closing this issue please?

thanks

jan

On 12/05/2020, jan <rtm443x@googlemail.com> wrote:
> I'm not sure that's the whole issue though
>
> 1. C-g does not break out.   If emacs simply hands off to a
> C-language-based regex engine and waits for it to return then that
> *may* be inevitable but I don't know.
>
> 2. I've done a bit of experimenting just now and something doesn't add
> up, I'll try to reproduce that tomorrow, draw some conclusions and
> post here.
>
> Thanks for the feedback. And the equation solver weirdness, which I'll
> read in detail later!
>
> thanks
>
> jan
>
> On 12/05/2020, Paul Eggert <eggert@cs.ucla.edu> wrote:
>>> I originally put it down to the regexp being clearly pathalogical
>>
>> Yes, that's pretty much it. Emacs uses a backtracking matcher and its
>> worst
>> case
>> performance is exponential. You can even use the matcher to solve
>> Diophantine
>> integer equations ... verrrryy slowly; see:
>>
>> http://blog.stevenlevithan.com/archives/algebra-with-regexes
>>
>> So, don't do that. (Or if you *do* want to do that, fix the matcher - but
>> good
>> luck with that....)
>>
>