bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17862: 24.3; regexp-opt docstring is incorrect


From: immerrr again
Subject: bug#17862: 24.3; regexp-opt docstring is incorrect
Date: Tue, 1 Jul 2014 11:15:56 +0400

On Mon, Jun 30, 2014 at 5:37 PM, Stefan Monnier
<address@hidden> wrote:
>
>
> It makes the semantics of regexp-opt much simpler/cleaner since the
> caller doesn't need to worry about the fact that the returned regexp
> might need to be surrounded by additional grouping in order for things
> like (concat (regexp-opt ..) "[ \t]+" ...) to work as intended.
>
> A few redundant shy-group wrappers are a very small price to pay for
> that, I think.  We could arrange to provide some way to avoid this
> wrapper, I guess.
>
>
>         Stefan

Sure, I'm all for reducing the number ways to shoot yourself in the foot and I
agree that not grouping by default is more error-prone.  I was rather surprised
to find the fix effectively disabling the power-user feature completely instead
of changing the default behaviour (and frustrated a bit about the docstring
becoming explicitly misguiding).

Cheers,
immerrr

PS. My apologies, I've sent this message directly to Stefan, this is
to leave it in
the tracker for reference.

On Mon, Jun 30, 2014 at 5:37 PM, Stefan Monnier
<address@hidden> wrote:
>> I'd argue that this sole change requires me to special-case (or ..) form
>> of rx macro for one arguments to avoid the unnecessary shy-grouping
>> there, but the message of said commit contains no information about the
>> background of that change, so it's hard to say if its benefits overweigh
>> the inconveniences.
>
> It makes the semantics of regexp-opt much simpler/cleaner since the
> caller doesn't need to worry about the fact that the returned regexp
> might need to be surrounded by additional grouping in order for things
> like (concat (regexp-opt ..) "[ \t]+" ...) to work as intended.
>
> A few redundant shy-group wrappers are a very small price to pay for
> that, I think.  We could arrange to provide some way to avoid this
> wrapper, I guess.
>
>
>         Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]