[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.
- bug#58992: 28.2; "lax space matching" no longer works, (continued)
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/03
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/03
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/03
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/03
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/03
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/03
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/03
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works,
Eli Zaretskii <=
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/03
- bug#58992: 28.2; "lax space matching" no longer works, Eli Zaretskii, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Vincent Lefevre, 2022/11/04
- bug#58992: 28.2; "lax space matching" no longer works, Andreas Schwab, 2022/11/04