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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 03 Nov 2022 19:04:31 +0200

> From: Vincent Lefevre <[email-masked]>
> 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.  For me, Emacs 26, Emacs 27, and all the later versions
behave the same.

> To reproduce with emacs -Q, consider a file with
> 
> ab
> cd
> ab cd
> 
> and search for "b c" with
> 
>   C-s b c
> 
> Only the one in the 3rd line is found.

Yes.  Because the default value of search-whitespace-regexp is
"[ \t]+".  And the Emacs manual which comes with Emacs 28 says:

     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
  precisely, Emacs matches each sequence of space characters in the search
  string to a regular expression specified by the variable
  ‘search-whitespace-regexp’.  For example, to make spaces match sequences
  of newlines as well as spaces, set it to the regular expression
  ‘[[:space:]\n]+’.  The default value of this variable considers any
  sequence of spaces and tab characters as whitespace.

So I see no bug here.