Excuse me but I have a question. If Gnulib is a collection of utility code to be used by all projects, why is carrying something Emacs specific? Is RE_SYNTAX_EMACS used by other projects?

On Tue, Mar 11, 2025 at 7:58 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2025-03-11 10:41, Eli Zaretskii wrote:
>> Date: Tue, 11 Mar 2025 14:28:45 +0200
>> From: Vladimir Gorsunov <gorsunov@gmail.com>
>>
>>     Before commit d904cc83 regex syntax flags used in etags were
>>
>>     RE_CHAR_CLASSES | RE_INTERVALS | RE_SHY_GROUPS | RE_FRUGAL
>>
>>     that got changed to 0. Including a patch that restores
>>     RE_CHAR_CLASSES and RE_INTERVALS and adds check for these features
>>     to the test. As far I can understand from the bug 74861, the
>>     absence of shy groups and non-greedy matching won't be fixed
>>     until Gnulib supports them
>
> Thanks.
>
> Paul, any comments?

As I understand it the original design for glibc regex was that Emacs
was the default, so a flags value of zero meant Emacs. This is why
RE_SYNTAX_EMACS is 0.

Evidently that design goal no longer holds, so it makes sense to adjust
Emacs's use of glibc flags to match the behavior of Emacs's only
regular-expression implementation in emacs/src/regex-emacs.c as best we can.

However, surely this adjustment should be made in Gnulib, not in
etags.c. That is, gnulib/lib/regex.h (aka emacs/lib/regex.h) should
#define RE_SYNTAX_EMACS to equal RE_CHAR_CLASSES | RE_INTERVALS, not
zero. And eventually this change should be migrated back to glibc.

I'll cc this to rms in case he has further comments about this.


--
Mit Respekt, Vladimir Gorsunov