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

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

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


From: Eli Zaretskii
Subject: bug#58992: 28.2; "lax space matching" no longer works
Date: Fri, 04 Nov 2022 09:14:57 +0200

> Date: Fri, 4 Nov 2022 03:29:50 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 58992@debbugs.gnu.org
> 
> > 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...

Because the mode sets up its syntax tables for various needs, none of
which is Isearch.

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

This is not really relevant.  Major modes set up their syntax tables
as they consider relevant, and we won't change that for the benefit of
search-whitespace-regexp.  The lesson to learn here is not to base
Isearch-related regexps on character syntax, because that changes its
meaning with the major mode, something many users will not expect.

> > > 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-+".

Then don't use "\\s-+".  The manual suggests a different regexp for
your preference, and it does so for a good reason.  Why are you using
a regexp that we already concluded to be problematic and stopped
using?  You will get yourself in the same problems we decided to
avoid.





reply via email to

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