bug#58992: 28.2; "lax space matching" no longer works

[Vincent Lefevre <vincent@vinc17.net>]

On 2022-11-03 19:04:31 +0200, Eli Zaretskii wrote:
> > From: Vincent Lefevre <vincent@vinc17.net>
> > Date: Thu, 03 Nov 2022 17:53:16 +0100
> > 
> > The Emacs manual says:
> > 
> > 15.9 Lax Matching During Searching
> > ==================================
> > [...]
> >    By default, search commands perform “lax space matching”: each space,
> > or sequence of spaces, matches any sequence of one or more whitespace
> > characters in the text.  (Incremental regexp search has a separate
> > default; see *note Regexp Search::.)  Hence, ‘foo bar’ matches
> > ‘foo bar’, ‘foo  bar’, ‘foo   bar’, and so on (but not ‘foobar’).  More
> > [...]
> > 
> > This is working with GNU Emacs 27, but not with GNU Emacs 28.2
> > (tested under Debian/unstable).
> 
> If it works for you by default in Emacs 27, then you either didn't
> test with "emacs -Q" there or your Emacs 27 is customized wrt the
> upstream.

I tested with "emacs -Q", and I've just tested again. I confirm the
behavior I could see: a newline character is matched. That's Debian's
package emacs-gtk 1:27.1+1-3.1+b1. So perhaps Debian has changed the
default (but no changes were announced in Debian for Emacs 28, whose
behavior is different).

BTW, for users who do not spend their time in reading the full doc,
I'd suggest to clarify the doc by saying "one or more user-configurable
whitespace characters", because AFAIK, a newline character is often
regarded as a whitespace character, in particular by Unicode:

  https://en.wikipedia.org/wiki/Whitespace_character

So the default could be very surprising.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)