From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#58992: 28.2; "lax space matching" no longer works Date: Fri, 04 Nov 2022 09:14:57 +0200 Message-ID: <83wn8b5gy6.fsf@gnu.org> References: <87tu3gasjn.fsf@zira.vinc17.org> <83iljw6kbk.fsf@gnu.org> <20221103172157.GB9807@zira.vinc17.org> <83h6zf7w53.fsf@gnu.org> <20221103183316.GH9807@zira.vinc17.org> <837d0b7uce.fsf@gnu.org> <20221103185207.GI9807@zira.vinc17.org> <835yfv7sij.fsf@gnu.org> <20221104022950.GJ9807@zira.vinc17.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12178"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58992@debbugs.gnu.org To: Vincent Lefevre Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 04 08:38:26 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oqrHV-0002xO-MY for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Nov 2022 08:38:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqrEt-00089M-TF; Fri, 04 Nov 2022 03:35:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqqvs-0007C5-1M for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 03:16:14 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oqqvq-0001OY-JH for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 03:16:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oqqvq-0000CO-0b for bug-gnu-emacs@gnu.org; Fri, 04 Nov 2022 03:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Nov 2022 07:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58992 X-GNU-PR-Package: emacs Original-Received: via spool by 58992-submit@debbugs.gnu.org id=B58992.1667546114684 (code B ref 58992); Fri, 04 Nov 2022 07:16:01 +0000 Original-Received: (at 58992) by debbugs.gnu.org; 4 Nov 2022 07:15:14 +0000 Original-Received: from localhost ([127.0.0.1]:51479 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqqv4-0000Aw-8W for submit@debbugs.gnu.org; Fri, 04 Nov 2022 03:15:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqquy-0000Ad-Kt for 58992@debbugs.gnu.org; Fri, 04 Nov 2022 03:15:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqqut-00013m-3s; Fri, 04 Nov 2022 03:15:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tTQN4mDKGO1X08RCU9SmdATZmkR6Fg5w/gUGn5VO/1I=; b=jVAWglE6EqqT IZnYdbfCYYUICR6lOrswxVxZ19QgNgkyU8gMDvMrFEGe2SgIqLZsMrAGLbB43mTr8w6CbMP7NtoQx +lnA4+1Y6mpZJKwW9f5YAIASFYqDZIzIVqQX4rXWbwl/t8LNtPKLkkV4Cubo+b2BykxeLdHVBQqOh R+REhHzl/IKHcVvoq9PS8DvpwGMqrjFG5upP8voj1VUFcFFUCRGJzHmHrSNX1cDkP9rD+6JRQTIv/ zyjLvOzhR3z/i/L0IHrBmzZWf8X4l00pVfAhYaUILj4842szOrCNDQzXm/N3zqYjM9TYEOZ/+l0u2 swgxA0XstlcIv/J/3gFb1Q==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqqus-0004lQ-Jf; Fri, 04 Nov 2022 03:15:02 -0400 In-Reply-To: <20221104022950.GJ9807@zira.vinc17.org> (message from Vincent Lefevre on Fri, 4 Nov 2022 03:29:50 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247047 Archived-At: > Date: Fri, 4 Nov 2022 03:29:50 +0100 > From: Vincent Lefevre > 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.