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

[immerrr again]

On Mon, Jun 30, 2014 at 5:37 PM, Stefan Monnier
<monnier@iro.umontreal.ca> 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
<monnier@iro.umontreal.ca> 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