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

[Vincent Lefevre]

On 2022-11-03 21:22:12 +0200, Eli Zaretskii wrote:
> > Date: Thu, 3 Nov 2022 19:52:07 +0100
> > From: Vincent Lefevre <vincent@vinc17.net>
> > Cc: 58992@debbugs.gnu.org
> > 
> > > Yes.  But in programming modes the newline didn't match.
> > 
> > Any reason why (perhaps except for shell modes)?
> 
> Because the newline's syntax is not "whitespace" in those modes.

OK, but then, the question is why the newline's syntax is not
"whitespace" in those modes...

> > In C, except for the preprocessor, a newline is similar to a space
> > character.
> 
> The syntax we give to each character in a major mode depends on what
> the mode needs to do with that character.  For example, a mode might
> have a good reason to give the newline the '>' syntax, because the
> newline ends a comment in those modes.

In C, the conventional comment is /* ... */ and the newline does not
end a comment. In any case, /* ... */ is more practical to write
multi-line comments in C (no need to repeat comment starters at the
beginning of every line), and if one wants to search in comments,
the newline should be regarded as a whitespace.

> > BTW, it actually doesn't match either for the Texinfo mode, and
> > I don't see any reason why.
> 
> In which version of Emacs, and with what value of
> search-whitespace-regexp?

Both 27.1 and 28.2 (Debian for both), with search-whitespace-regexp
set to "\\s-+". For Texinfo, it is more common to search in the
normal text (rather than comments), since this is the significant
content, so the newline character should be regarded as whitespace.

-- 
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)