From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jan 2013 13:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 13402@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.135782476232739 (code B ref -1); Thu, 10 Jan 2013 13:33:01 +0000 Received: (at submit) by debbugs.gnu.org; 10 Jan 2013 13:32:42 +0000 Received: from localhost ([127.0.0.1]:53522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtIFL-0008Vx-Pi for submit@debbugs.gnu.org; Thu, 10 Jan 2013 08:32:41 -0500 Received: from eggs.gnu.org ([208.118.235.92]:50775) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtIFG-0008VX-Sx for submit@debbugs.gnu.org; Thu, 10 Jan 2013 08:32:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtIF9-00023Q-I6 for submit@debbugs.gnu.org; Thu, 10 Jan 2013 08:32:28 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-100.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, URIBL_BLACK, USER_IN_WHITELIST autolearn=no version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:60752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIF9-00023K-FZ for submit@debbugs.gnu.org; Thu, 10 Jan 2013 08:32:27 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIF7-0000Fo-GR for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 08:32:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtIF2-00022R-QW for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 08:32:25 -0500 Received: from colin.muc.de ([193.149.48.1]:45908 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIF2-000228-JV for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 08:32:20 -0500 Received: (qmail 11315 invoked by uid 3782); 10 Jan 2013 13:32:18 -0000 Received: from acm.muc.de (pD951B0C4.dip.t-dialin.net [217.81.176.196]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 10 Jan 2013 14:32:17 +0100 Received: (qmail 2920 invoked by uid 1000); 10 Jan 2013 13:25:30 -0000 Date: Thu, 10 Jan 2013 13:25:30 +0000 Message-ID: <20130110132530.GA2805@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.4 (----) Emacs 24.2.92. emacs -Q C-u C-h i Enter path/to/elisp.info g Syntax Table Internals 1. Place point at the start of the first paragraph ("Syntax tables are implemented ..."). Attempt C-s M-s C-e (isearch-yank-line). This produces the error message: Failing I-search: syntax tables are implemented as char-tables (*note char-tables::), but [end of node] This is a bug. 2. Place point at the start of the second paragraph ("Each entry in a ...."). Attempt C-s M-s C-e (isearch-yeank-line). This works, but wrongly highlights the gap preceding the paragraph with lazy-highlight face. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page Resent-From: Andreas Schwab Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Jan 2013 18:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.135784209531342 (code B ref 13402); Thu, 10 Jan 2013 18:22:02 +0000 Received: (at 13402) by debbugs.gnu.org; 10 Jan 2013 18:21:35 +0000 Received: from localhost ([127.0.0.1]:54429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtMkw-00089Q-FT for submit@debbugs.gnu.org; Thu, 10 Jan 2013 13:21:35 -0500 Received: from mail-out.m-online.net ([212.18.0.10]:45431) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtMku-00089J-LT for 13402@debbugs.gnu.org; Thu, 10 Jan 2013 13:21:34 -0500 Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3YhwWs3h1Yz3hhcb; Thu, 10 Jan 2013 19:21:29 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.68]) by mail.m-online.net (Postfix) with ESMTP id 3YhwWs2Q40zbbs2; Thu, 10 Jan 2013 19:21:29 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.180]) by localhost (dynscan1.mail.m-online.net [192.168.6.68]) (amavisd-new, port 10024) with ESMTP id 9T9gU5v1XyqV; Thu, 10 Jan 2013 19:21:26 +0100 (CET) X-Auth-Info: TYtEN8BZkuvC1uvh6z+ZZrcYegP+dhMxI5zwsZI0CH0= Received: from igel.home (ppp-93-104-155-170.dynamic.mnet-online.de [93.104.155.170]) by mail.mnet-online.de (Postfix) with ESMTPA; Thu, 10 Jan 2013 19:21:28 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id D8FEE11200A; Thu, 10 Jan 2013 19:21:27 +0100 (CET) From: Andreas Schwab References: <20130110132530.GA2805@acm.acm> X-Yow: Now that we're in LOVE, you can BUY this GOLDFISH for a 48% DISCOUNT. Date: Thu, 10 Jan 2013 19:21:27 +0100 In-Reply-To: <20130110132530.GA2805@acm.acm> (Alan Mackenzie's message of "Thu, 10 Jan 2013 13:25:30 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Alan Mackenzie writes: > 2. Place point at the start of the second paragraph ("Each entry in a > ...."). Attempt C-s M-s C-e (isearch-yeank-line). This works, but > wrongly highlights the gap preceding the paragraph with lazy-highlight > face. That's due to isearch-lax-whitespace (try M-s SPC). Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jan 2013 01:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.13578659888598 (code B ref 13402); Fri, 11 Jan 2013 01:00:02 +0000 Received: (at 13402) by debbugs.gnu.org; 11 Jan 2013 00:59:48 +0000 Received: from localhost ([127.0.0.1]:54771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtSyK-0002Ed-FM for submit@debbugs.gnu.org; Thu, 10 Jan 2013 19:59:48 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:57824 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtSyH-0002EU-Ea for 13402@debbugs.gnu.org; Thu, 10 Jan 2013 19:59:47 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id D437F229B0FDC8; Thu, 10 Jan 2013 16:59:39 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> Date: Fri, 11 Jan 2013 02:43:16 +0200 In-Reply-To: <20130110132530.GA2805@acm.acm> (Alan Mackenzie's message of "Thu, 10 Jan 2013 13:25:30 +0000") Message-ID: <87k3rktu9v.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > C-u C-h i > Enter path/to/elisp.info > g Syntax Table Internals > > 1. Place point at the start of the first paragraph ("Syntax tables are > implemented ..."). Attempt C-s M-s C-e (isearch-yank-line). This > produces the error message: > > Failing I-search: syntax tables are implemented as char-tables (*note char-tables::), but [end of node] [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: elisp.info] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4860] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > C-u C-h i > Enter path/to/elisp.info > g Syntax Table Internals > > 1. Place point at the start of the first paragraph ("Syntax tables are > implemented ..."). Attempt C-s M-s C-e (isearch-yank-line). This > produces the error message: > > Failing I-search: syntax tables are implemented as char-tables (*note char-tables::), but [end of node] [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: elisp.info] -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5% [score: 0.0153] > C-u C-h i > Enter path/to/elisp.info > g Syntax Table Internals > > 1. Place point at the start of the first paragraph ("Syntax tables are > implemented ..."). Attempt C-s M-s C-e (isearch-yank-line). This > produces the error message: > > Failing I-search: syntax tables are implemented as char-tables (*note char-tables::), but [end of node] Info hides the text "*note Char-Tables::" and uses the text property `display' to put another text "(see Char-Tables)" instead. Some users complained when isearch-yank-line yanked invisible text "*note", so now it ignores invisible text. But it seems ignoring invisible text is worse than yanking. So perhaps `Info-isearch-filter' shouldn't skip invisible text. From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Feb 2013 09:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.13607489168209 (code B ref 13402); Wed, 13 Feb 2013 09:49:01 +0000 Received: (at 13402) by debbugs.gnu.org; 13 Feb 2013 09:48:36 +0000 Received: from localhost ([127.0.0.1]:53285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5Yx9-00028M-TP for submit@debbugs.gnu.org; Wed, 13 Feb 2013 04:48:36 -0500 Received: from colin.muc.de ([193.149.48.1]:65017 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5Yx6-00028C-Kb for 13402@debbugs.gnu.org; Wed, 13 Feb 2013 04:48:34 -0500 Received: (qmail 22339 invoked by uid 3782); 13 Feb 2013 09:48:00 -0000 Received: from acm.muc.de (pD951A532.dip.t-dialin.net [217.81.165.50]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 13 Feb 2013 10:47:59 +0100 Received: (qmail 9926 invoked by uid 1000); 13 Feb 2013 09:47:24 -0000 Date: Wed, 13 Feb 2013 09:47:24 +0000 Message-ID: <20130213094724.GA9907@acm.acm> References: <20130110132530.GA2805@acm.acm> <87k3rktu9v.fsf@mail.jurta.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k3rktu9v.fsf@mail.jurta.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 1.8 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello, Juri. On Fri, Jan 11, 2013 at 02:43:16AM +0200, Juri Linkov wrote: > > C-u C-h i > > Enter path/to/elisp.info > > g Syntax Table Internals > > 1. Place point at the start of the first paragraph ("Syntax tables are > > implemented ..."). Attempt C-s M-s C-e (isearch-yank-line). This > > produces the error message: [...] Content analysis details: (1.8 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [193.149.48.1 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: elisp.info] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4491] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.5 (/) Hello, Juri. On Fri, Jan 11, 2013 at 02:43:16AM +0200, Juri Linkov wrote: > > C-u C-h i > > Enter path/to/elisp.info > > g Syntax Table Internals > > 1. Place point at the start of the first paragraph ("Syntax tables are > > implemented ..."). Attempt C-s M-s C-e (isearch-yank-line). This > > produces the error message: > > Failing I-search: syntax tables are implemented as char-tables (*note char-tables::), but [end of node] > Info hides the text "*note Char-Tables::" and uses the text property `display' > to put another text "(see Char-Tables)" instead. Some users complained > when isearch-yank-line yanked invisible text "*note", so now it ignores > invisible text. But it seems ignoring invisible text is worse than yanking. > So perhaps `Info-isearch-filter' shouldn't skip invisible text. I think it should either skip it properly, or not at all. There is an inconsistency here between parts of isearch. C-s C-w also produces these error messages, and the "[end of node]" is just wierd, from a user's point of view. I think this should be fixed, somehow, for Emacs 24.3. I would agree with your suggestion that isearch should simply yank the invisible text. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Feb 2013 17:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136077816122586 (code B ref 13402); Wed, 13 Feb 2013 17:56:01 +0000 Received: (at 13402) by debbugs.gnu.org; 13 Feb 2013 17:56:01 +0000 Received: from localhost ([127.0.0.1]:54496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5gYq-0005sF-Ia for submit@debbugs.gnu.org; Wed, 13 Feb 2013 12:56:00 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:42447 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5gYm-0005s0-At for 13402@debbugs.gnu.org; Wed, 13 Feb 2013 12:55:59 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id F2A59201D27A29; Wed, 13 Feb 2013 09:55:21 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> <87k3rktu9v.fsf@mail.jurta.org> <20130213094724.GA9907@acm.acm> Date: Wed, 13 Feb 2013 19:53:28 +0200 In-Reply-To: <20130213094724.GA9907@acm.acm> (Alan Mackenzie's message of "Wed, 13 Feb 2013 09:47:24 +0000") Message-ID: <87621ww23b.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.0 (/) > I think it should either skip it properly, or not at all. There is an > inconsistency here between parts of isearch. This can be fixed by the patch below that takes into account the default value `open' of `search-invisible' and treats it the same as its value `t', i.e. matches hidden text (but it still can't "open" it in a meaningful way). > C-s C-w also produces these error messages, and the "[end of node]" > is just wierd, from a user's point of view. I have no idea for a better error message. > I think this should be fixed, somehow, for Emacs 24.3. I would agree > with your suggestion that isearch should simply yank the invisible text. This is not a regression, so this patch is intended for trunk: === modified file 'lisp/info.el' --- lisp/info.el 2013-02-12 07:57:04 +0000 +++ lisp/info.el 2013-02-13 17:52:53 +0000 @@ -2162,7 +2162,7 @@ (defun Info-isearch-filter (beg-found fo (let ((backward (< found beg-found))) (not (or - (and (not (eq search-invisible t)) + (and (null search-invisible) (if backward (or (text-property-not-all found beg-found 'invisible nil) (text-property-not-all found beg-found 'display nil)) From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Feb 2013 22:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136079285312026 (code B ref 13402); Wed, 13 Feb 2013 22:01:02 +0000 Received: (at 13402) by debbugs.gnu.org; 13 Feb 2013 22:00:53 +0000 Received: from localhost ([127.0.0.1]:54644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5kNo-00037t-4l for submit@debbugs.gnu.org; Wed, 13 Feb 2013 17:00:53 -0500 Received: from colin.muc.de ([193.149.48.1]:23389 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5kNk-00037k-Ug for 13402@debbugs.gnu.org; Wed, 13 Feb 2013 17:00:50 -0500 Received: (qmail 82690 invoked by uid 3782); 13 Feb 2013 22:00:13 -0000 Received: from acm.muc.de (pD951A532.dip.t-dialin.net [217.81.165.50]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 13 Feb 2013 23:00:10 +0100 Received: (qmail 5354 invoked by uid 1000); 13 Feb 2013 21:59:36 -0000 Date: Wed, 13 Feb 2013 21:59:36 +0000 Message-ID: <20130213215936.GA5084@acm.acm> References: <20130110132530.GA2805@acm.acm> <87k3rktu9v.fsf@mail.jurta.org> <20130213094724.GA9907@acm.acm> <87621ww23b.fsf@mail.jurta.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87621ww23b.fsf@mail.jurta.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) Hi, Juri. On Wed, Feb 13, 2013 at 07:53:28PM +0200, Juri Linkov wrote: > > I think it should either skip it properly, or not at all. There is an > > inconsistency here between parts of isearch. > This can be fixed by the patch below that takes into account > the default value `open' of `search-invisible' and treats it the same > as its value `t', i.e. matches hidden text (but it still can't "open" it > in a meaningful way). OK. The patch seems to work. > > I think this should be fixed, somehow, for Emacs 24.3. I would agree > > with your suggestion that isearch should simply yank the invisible text. > This is not a regression, so this patch is intended for trunk: Indeed, I tried it on some older Emacsen. It does go back some way. > === modified file 'lisp/info.el' > --- lisp/info.el 2013-02-12 07:57:04 +0000 > +++ lisp/info.el 2013-02-13 17:52:53 +0000 > @@ -2162,7 +2162,7 @@ (defun Info-isearch-filter (beg-found fo > (let ((backward (< found beg-found))) > (not > (or > - (and (not (eq search-invisible t)) > + (and (null search-invisible) > (if backward > (or (text-property-not-all found beg-found 'invisible nil) > (text-property-not-all found beg-found 'display nil)) -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Alan Mackenzie Subject: bug#13402: closed (Re: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page) Message-ID: References: <87mwv7qmqp.fsf@mail.jurta.org> <20130110132530.GA2805@acm.acm> X-Gnu-PR-Message: they-closed 13402 X-Gnu-PR-Package: emacs Reply-To: 13402@debbugs.gnu.org Date: Thu, 14 Feb 2013 09:25:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1360833903-11465-1" This is a multi-part message in MIME format... ------------=_1360833903-11465-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #13402: 24.2.92 pretest: bugs in isearch-yank-line in info page which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 13402@debbugs.gnu.org. --=20 13402: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D13402 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1360833903-11465-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 13402-done) by debbugs.gnu.org; 14 Feb 2013 09:24:39 +0000 Received: from localhost ([127.0.0.1]:55109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5v3W-0002xZ-Hc for submit@debbugs.gnu.org; Thu, 14 Feb 2013 04:24:38 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:46536 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U5v3T-0002xL-F1 for 13402-done@debbugs.gnu.org; Thu, 14 Feb 2013 04:24:36 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 8FB8B20199352F; Thu, 14 Feb 2013 01:23:57 -0800 (PST) From: Juri Linkov To: Alan Mackenzie Subject: Re: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page Organization: JURTA References: <20130110132530.GA2805@acm.acm> <87k3rktu9v.fsf@mail.jurta.org> <20130213094724.GA9907@acm.acm> <87621ww23b.fsf@mail.jurta.org> <20130213215936.GA5084@acm.acm> Date: Thu, 14 Feb 2013 11:16:16 +0200 In-Reply-To: <20130213215936.GA5084@acm.acm> (Alan Mackenzie's message of "Wed, 13 Feb 2013 21:59:36 +0000") Message-ID: <87mwv7qmqp.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 13402-done Cc: 13402-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) >> > I think it should either skip it properly, or not at all. >> > There is an inconsistency here between parts of isearch. >> >> This can be fixed by the patch below that takes into account >> the default value `open' of `search-invisible' and treats it the same >> as its value `t', i.e. matches hidden text (but it still can't "open" it >> in a meaningful way). > > OK. The patch seems to work. Thanks for confirmation. This is now installed in trunk and the bug closed. ------------=_1360833903-11465-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 10 Jan 2013 13:32:42 +0000 Received: from localhost ([127.0.0.1]:53522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtIFL-0008Vx-Pi for submit@debbugs.gnu.org; Thu, 10 Jan 2013 08:32:41 -0500 Received: from eggs.gnu.org ([208.118.235.92]:50775) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtIFG-0008VX-Sx for submit@debbugs.gnu.org; Thu, 10 Jan 2013 08:32:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtIF9-00023Q-I6 for submit@debbugs.gnu.org; Thu, 10 Jan 2013 08:32:28 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-100.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, URIBL_BLACK, USER_IN_WHITELIST autolearn=no version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:60752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIF9-00023K-FZ for submit@debbugs.gnu.org; Thu, 10 Jan 2013 08:32:27 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIF7-0000Fo-GR for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 08:32:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtIF2-00022R-QW for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 08:32:25 -0500 Received: from colin.muc.de ([193.149.48.1]:45908 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtIF2-000228-JV for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 08:32:20 -0500 Received: (qmail 11315 invoked by uid 3782); 10 Jan 2013 13:32:18 -0000 Received: from acm.muc.de (pD951B0C4.dip.t-dialin.net [217.81.176.196]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 10 Jan 2013 14:32:17 +0100 Received: (qmail 2920 invoked by uid 1000); 10 Jan 2013 13:25:30 -0000 Date: Thu, 10 Jan 2013 13:25:30 +0000 To: bug-gnu-emacs@gnu.org Subject: 24.2.92 pretest: bugs in isearch-yank-line in info page Message-ID: <20130110132530.GA2805@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.4 (----) Emacs 24.2.92. emacs -Q C-u C-h i Enter path/to/elisp.info g Syntax Table Internals 1. Place point at the start of the first paragraph ("Syntax tables are implemented ..."). Attempt C-s M-s C-e (isearch-yank-line). This produces the error message: Failing I-search: syntax tables are implemented as char-tables (*note char-tables::), but [end of node] This is a bug. 2. Place point at the start of the second paragraph ("Each entry in a ...."). Attempt C-s M-s C-e (isearch-yeank-line). This works, but wrongly highlights the gap preceding the paragraph with lazy-highlight face. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1360833903-11465-1-- From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Feb 2013 20:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: emacs-devel@gnu.org Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136087265812022 (code B ref 13402); Thu, 14 Feb 2013 20:11:02 +0000 Received: (at 13402) by debbugs.gnu.org; 14 Feb 2013 20:10:58 +0000 Received: from localhost ([127.0.0.1]:56588 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6590-00037q-0X for submit@debbugs.gnu.org; Thu, 14 Feb 2013 15:10:58 -0500 Received: from colin.muc.de ([193.149.48.1]:18301 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U658v-00037d-Q1 for 13402@debbugs.gnu.org; Thu, 14 Feb 2013 15:10:56 -0500 Received: (qmail 73341 invoked by uid 3782); 14 Feb 2013 20:10:13 -0000 Received: from acm.muc.de (pD955724F.dip.t-dialin.net [217.85.114.79]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 14 Feb 2013 21:10:12 +0100 Received: (qmail 3578 invoked by uid 1000); 14 Feb 2013 20:09:38 -0000 Date: Thu, 14 Feb 2013 20:09:38 +0000 Message-ID: <20130214200937.GA3336@acm.acm> References: <20130110132530.GA2805@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130110132530.GA2805@acm.acm> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Thu, Jan 10, 2013 at 01:25:30PM +0000, Alan Mackenzie wrote: > Emacs 24.2.92. > emacs -Q > C-u C-h i > Enter path/to/elisp.info > g Syntax Table Internals [ .... ] > 2. Place point at the start of the second paragraph ("Each entry in a > ...."). Attempt C-s M-s C-e (isearch-yeank-line). This works, but > wrongly highlights the gap preceding the paragraph with lazy-highlight > face. This wrong highlighting is a regression, introduced when a space in a normal isearch was made to match any sequence of WS characters. The bug's mechanism is that the current match in the buffer is redundantly given lazy highlighting, although it is already highlighted with isearch-face. Sometimes the region being lazy-highlit is bigger than the current match, and the lazy highlighting spills into the surrounding area. This is what is happening here. The solution I propose is NOT to lazy-highlight when the LH region overlaps with the current match. Here is a patch for this change: === modified file 'lisp/isearch.el' *** lisp/isearch.el 2013-02-01 23:38:41 +0000 --- lisp/isearch.el 2013-02-14 19:49:37 +0000 *************** *** 2862,2867 **** --- 2862,2868 ---- (defvar isearch-lazy-highlight-end-limit nil) (defvar isearch-lazy-highlight-start nil) (defvar isearch-lazy-highlight-end nil) + (defvar isearch-lazy-highlight-point nil) (defvar isearch-lazy-highlight-timer nil) (defvar isearch-lazy-highlight-last-string nil) (defvar isearch-lazy-highlight-window nil) *************** *** 2938,2943 **** --- 2939,2945 ---- isearch-lazy-highlight-window-end (window-end) isearch-lazy-highlight-start (point) isearch-lazy-highlight-end (point) + isearch-lazy-highlight-point (point) isearch-lazy-highlight-wrapped nil isearch-lazy-highlight-last-string isearch-string isearch-lazy-highlight-case-fold-search isearch-case-fold-search *************** *** 3014,3033 **** (if found (let ((mb (match-beginning 0)) (me (match-end 0))) ! (if (= mb me) ;zero-length match ! (if isearch-lazy-highlight-forward ! (if (= mb (if isearch-lazy-highlight-wrapped ! isearch-lazy-highlight-start ! (window-end))) ! (setq found nil) ! (forward-char 1)) (if (= mb (if isearch-lazy-highlight-wrapped ! isearch-lazy-highlight-end ! (window-start))) (setq found nil) ! (forward-char -1))) ! ! ;; non-zero-length match (let ((ov (make-overlay mb me))) (push ov isearch-lazy-highlight-overlays) ;; 1000 is higher than ediff's 100+, --- 3016,3041 ---- (if found (let ((mb (match-beginning 0)) (me (match-end 0))) ! (cond ! ((= mb me) ;zero-length match ! (if isearch-lazy-highlight-forward (if (= mb (if isearch-lazy-highlight-wrapped ! isearch-lazy-highlight-start ! (window-end))) (setq found nil) ! (forward-char 1)) ! (if (= mb (if isearch-lazy-highlight-wrapped ! isearch-lazy-highlight-end ! (window-start))) ! (setq found nil) ! (forward-char -1)))) ! ! ((if isearch-lazy-highlight-forward ! (or (<= me isearch-other-end) ! (>= mb isearch-lazy-highlight-point)) ! (or (<= me isearch-lazy-highlight-point) ! (>= mb isearch-other-end))) ! ;; non-zero-length match not overlapping found string (let ((ov (make-overlay mb me))) (push ov isearch-lazy-highlight-overlays) ;; 1000 is higher than ediff's 100+, *************** *** 3035,3040 **** --- 3043,3052 ---- (overlay-put ov 'priority 1000) (overlay-put ov 'face lazy-highlight-face) (overlay-put ov 'window (selected-window)))) + + ; (t nil) ; the match overlaps current found string. + ) + (if isearch-lazy-highlight-forward (setq isearch-lazy-highlight-end (point)) (setq isearch-lazy-highlight-start (point))))) > -- > Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Glenn Morris Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Feb 2013 23:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136088605711170 (code B ref 13402); Thu, 14 Feb 2013 23:55:01 +0000 Received: (at 13402) by debbugs.gnu.org; 14 Feb 2013 23:54:17 +0000 Received: from localhost ([127.0.0.1]:56739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U68d6-0002u6-Ng for submit@debbugs.gnu.org; Thu, 14 Feb 2013 18:54:17 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:33589) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U68d4-0002ty-La for 13402@debbugs.gnu.org; Thu, 14 Feb 2013 18:54:15 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1U68cQ-0003Tt-8k; Thu, 14 Feb 2013 18:53:34 -0500 From: Glenn Morris References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> X-Spook: diwn constitution ASO enigma Venezuela Europol X-Ran: =rx%r^OdZTV_h=">XP>&,^9.fUQU(-|H\)M-q4/!%3jo[|G0>}FEuE{yzVtYC*{nP&x0%t X-Hue: cyan X-Attribution: GM Date: Thu, 14 Feb 2013 18:53:34 -0500 In-Reply-To: <20130214200937.GA3336@acm.acm> (Alan Mackenzie's message of "Thu, 14 Feb 2013 20:09:38 +0000") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.2 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.5 (-----) (No need to cc emacs-devel.) This seems like a minor cosmetic issue to me, so personally I would just fix it in trunk. But if it bothers you and you are sure the fix is safe, put it in emacs-24. From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Feb 2013 07:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136091463423992 (code B ref 13402); Fri, 15 Feb 2013 07:51:02 +0000 Received: (at 13402) by debbugs.gnu.org; 15 Feb 2013 07:50:34 +0000 Received: from localhost ([127.0.0.1]:57026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6G40-0006Eu-Oq for submit@debbugs.gnu.org; Fri, 15 Feb 2013 02:50:33 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:57714 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6G3w-0006Ej-4w for 13402@debbugs.gnu.org; Fri, 15 Feb 2013 02:50:30 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 31FD3201F6650C; Thu, 14 Feb 2013 23:49:45 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> Date: Fri, 15 Feb 2013 09:47:10 +0200 In-Reply-To: <20130214200937.GA3336@acm.acm> (Alan Mackenzie's message of "Thu, 14 Feb 2013 20:09:38 +0000") Message-ID: <87d2w2ggsh.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > This wrong highlighting is a regression, introduced when a space in a > normal isearch was made to match any sequence of WS characters. Actually this is not a regression. You can see the same in Emacs 23.1 and earlier versions. emacs -Q C-u C-h i Enter path/to/elisp.info g Syntax Table Internals Place point at the start of the second paragraph ("Each entry in a ...."). Attempt C-M-s C-y (isearch-yank-line). The difference is that in Emacs 23.1 it was observable in regexp isearch and now in non-regexp normal isearch. > The solution I propose is NOT to lazy-highlight when the LH region > overlaps with the current match. > > Here is a patch for this change: Thanks, I'll test your patch now. Sometimes I've seen lazy-highlighting under point when the current match was not highlighted. I'll try to recall such test cases (probably occurs when switching to word mode). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Feb 2013 10:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136092433812182 (code B ref 13402); Fri, 15 Feb 2013 10:33:02 +0000 Received: (at 13402) by debbugs.gnu.org; 15 Feb 2013 10:32:18 +0000 Received: from localhost ([127.0.0.1]:57140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6IaX-0003AQ-1k for submit@debbugs.gnu.org; Fri, 15 Feb 2013 05:32:17 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:53011 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6IaU-0003AI-Db for 13402@debbugs.gnu.org; Fri, 15 Feb 2013 05:32:15 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 9D92F201F76C2F; Fri, 15 Feb 2013 02:31:30 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> Date: Fri, 15 Feb 2013 12:10:45 +0200 In-Reply-To: <87d2w2ggsh.fsf@mail.jurta.org> (Juri Linkov's message of "Fri, 15 Feb 2013 09:47:10 +0200") Message-ID: <87liapan32.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.0 (/) >> Here is a patch for this change: > > Thanks, I'll test your patch now. I noticed one problem: going to the next match with `C-s' (isearch-repeat-forward) doesn't lazy-highlight the previous match that was unhighlighted. The previous match needs to be re-highlighted and the next match unhighlighted. But this requires performing the complete round of lazy-highlighting all of lazy-matches on every `C-s' key press that will cause significant slow down in lazy-highlighting because it will remove the current optimization where `C-s' doesn't cause re-highlighting of lazy-matches most of the time (when there is no scrolling or toggling of search parameters). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Feb 2013 11:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136092938819617 (code B ref 13402); Fri, 15 Feb 2013 11:57:01 +0000 Received: (at 13402) by debbugs.gnu.org; 15 Feb 2013 11:56:28 +0000 Received: from localhost ([127.0.0.1]:57193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6Jtz-00056L-CD for submit@debbugs.gnu.org; Fri, 15 Feb 2013 06:56:28 -0500 Received: from colin.muc.de ([193.149.48.1]:28751 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6Jtw-00056B-1G for 13402@debbugs.gnu.org; Fri, 15 Feb 2013 06:56:25 -0500 Received: (qmail 40690 invoked by uid 3782); 15 Feb 2013 11:55:40 -0000 Received: from acm.muc.de (pD951B3CC.dip.t-dialin.net [217.81.179.204]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 15 Feb 2013 12:55:37 +0100 Received: (qmail 2925 invoked by uid 1000); 15 Feb 2013 11:55:02 -0000 Date: Fri, 15 Feb 2013 11:55:02 +0000 Message-ID: <20130215115502.GA2907@acm.acm> References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87liapan32.fsf@mail.jurta.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) Hi, Juri. On Fri, Feb 15, 2013 at 12:10:45PM +0200, Juri Linkov wrote: > >> Here is a patch for this change: > > Thanks, I'll test your patch now. > I noticed one problem: going to the next match with `C-s' > (isearch-repeat-forward) doesn't lazy-highlight the previous match > that was unhighlighted. The previous match needs to be re-highlighted > and the next match unhighlighted. OK. Sorry I didn't spot this. > But this requires performing the complete round of lazy-highlighting > all of lazy-matches on every `C-s' key press that will cause > significant slow down in lazy-highlighting because it will remove the > current optimization where `C-s' doesn't cause re-highlighting of > lazy-matches most of the time (when there is no scrolling or toggling > of search parameters). Not necessarily. Another approach, which I'm going to try, is to create the "lazy" overlay for the current match, but not to give it the face property. On C-s, that overlay can get its face, and the overlay for the current match can lose its "lazy face". That way, each match will have exactly one isearch overlay face active. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Feb 2013 13:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136093449630385 (code B ref 13402); Fri, 15 Feb 2013 13:22:02 +0000 Received: (at 13402) by debbugs.gnu.org; 15 Feb 2013 13:21:36 +0000 Received: from localhost ([127.0.0.1]:57236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6LEJ-0007ty-7I for submit@debbugs.gnu.org; Fri, 15 Feb 2013 08:21:35 -0500 Received: from colin.muc.de ([193.149.48.1]:39836 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6LEC-0007tj-ID for 13402@debbugs.gnu.org; Fri, 15 Feb 2013 08:21:30 -0500 Received: (qmail 46656 invoked by uid 3782); 15 Feb 2013 13:20:40 -0000 Received: from acm.muc.de (pD951B3CC.dip.t-dialin.net [217.81.179.204]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 15 Feb 2013 14:20:38 +0100 Received: (qmail 3240 invoked by uid 1000); 15 Feb 2013 13:20:04 -0000 Date: Fri, 15 Feb 2013 13:20:04 +0000 Message-ID: <20130215132004.GB2907@acm.acm> References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87liapan32.fsf@mail.jurta.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi, Juri. On Fri, Feb 15, 2013 at 12:10:45PM +0200, Juri Linkov wrote: > >> Here is a patch for this change: > > Thanks, I'll test your patch now. > I noticed one problem: going to the next match with `C-s' > (isearch-repeat-forward) doesn't lazy-highlight the previous match > that was unhighlighted. The previous match needs to be re-highlighted > and the next match unhighlighted. But this requires performing the complete > round of lazy-highlighting all of lazy-matches on every `C-s' key press > that will cause significant slow down in lazy-highlighting because it will > remove the current optimization where `C-s' doesn't cause re-highlighting > of lazy-matches most of the time (when there is no scrolling or toggling > of search parameters). OK, here's a better patch. As already suggested, every match now has its lazy-highlight overlay, just that the one overlapping the current match no longer has the 'face property set. I don't think there can be more than one overlapping match. This approach preserves the optimisation with `C-s'. === modified file 'lisp/isearch.el' *** lisp/isearch.el 2013-02-01 23:38:41 +0000 --- lisp/isearch.el 2013-02-15 13:09:26 +0000 *************** *** 2862,2867 **** --- 2862,2869 ---- (defvar isearch-lazy-highlight-end-limit nil) (defvar isearch-lazy-highlight-start nil) (defvar isearch-lazy-highlight-end nil) + (defvar isearch-lazy-highlight-point nil) + (defvar isearch-lazy-highlight-shadowed nil) (defvar isearch-lazy-highlight-timer nil) (defvar isearch-lazy-highlight-last-string nil) (defvar isearch-lazy-highlight-window nil) *************** *** 2881,2891 **** is nil. This function is called when exiting an incremental search if `lazy-highlight-cleanup' is non-nil." (interactive '(t)) ! (if (or force lazy-highlight-cleanup) ! (while isearch-lazy-highlight-overlays ! (delete-overlay (car isearch-lazy-highlight-overlays)) ! (setq isearch-lazy-highlight-overlays ! (cdr isearch-lazy-highlight-overlays)))) (when isearch-lazy-highlight-timer (cancel-timer isearch-lazy-highlight-timer) (setq isearch-lazy-highlight-timer nil))) --- 2883,2894 ---- is nil. This function is called when exiting an incremental search if `lazy-highlight-cleanup' is non-nil." (interactive '(t)) ! (when (or force lazy-highlight-cleanup) ! (while isearch-lazy-highlight-overlays ! (delete-overlay (car isearch-lazy-highlight-overlays)) ! (setq isearch-lazy-highlight-overlays ! (cdr isearch-lazy-highlight-overlays))) ! (setq isearch-lazy-highlight-shadowed nil)) (when isearch-lazy-highlight-timer (cancel-timer isearch-lazy-highlight-timer) (setq isearch-lazy-highlight-timer nil))) *************** *** 2894,2955 **** 'lazy-highlight-cleanup "22.1") (defun isearch-lazy-highlight-new-loop (&optional beg end) "Cleanup any previous `lazy-highlight' loop and begin a new one. BEG and END specify the bounds within which highlighting should occur. This is called when `isearch-update' is invoked (which can cause the search string to change or the window to scroll). It is also used by other Emacs features." ! (when (and (null executing-kbd-macro) ! (sit-for 0) ;make sure (window-start) is credible ! (or (not (equal isearch-string ! isearch-lazy-highlight-last-string)) ! (not (eq (selected-window) ! isearch-lazy-highlight-window)) ! (not (eq isearch-lazy-highlight-case-fold-search ! isearch-case-fold-search)) ! (not (eq isearch-lazy-highlight-regexp ! isearch-regexp)) ! (not (eq isearch-lazy-highlight-word ! isearch-word)) ! (not (eq isearch-lazy-highlight-lax-whitespace ! isearch-lax-whitespace)) ! (not (eq isearch-lazy-highlight-regexp-lax-whitespace ! isearch-regexp-lax-whitespace)) ! (not (= (window-start) ! isearch-lazy-highlight-window-start)) ! (not (= (window-end) ; Window may have been split/joined. ! isearch-lazy-highlight-window-end)) ! (not (eq isearch-forward ! isearch-lazy-highlight-forward)) ! ;; In case we are recovering from an error. ! (not (equal isearch-error ! isearch-lazy-highlight-error)))) ! ;; something important did indeed change ! (lazy-highlight-cleanup t) ;kill old loop & remove overlays ! (setq isearch-lazy-highlight-error isearch-error) ! ;; It used to check for `(not isearch-error)' here, but actually ! ;; lazy-highlighting might find matches to highlight even when ! ;; `isearch-error' is non-nil. (Bug#9918) ! (setq isearch-lazy-highlight-start-limit beg ! isearch-lazy-highlight-end-limit end) ! (setq isearch-lazy-highlight-window (selected-window) ! isearch-lazy-highlight-window-start (window-start) ! isearch-lazy-highlight-window-end (window-end) ! isearch-lazy-highlight-start (point) ! isearch-lazy-highlight-end (point) ! isearch-lazy-highlight-wrapped nil ! isearch-lazy-highlight-last-string isearch-string ! isearch-lazy-highlight-case-fold-search isearch-case-fold-search ! isearch-lazy-highlight-regexp isearch-regexp ! isearch-lazy-highlight-lax-whitespace isearch-lax-whitespace ! isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace ! isearch-lazy-highlight-word isearch-word ! isearch-lazy-highlight-forward isearch-forward) ! (unless (equal isearch-string "") ! (setq isearch-lazy-highlight-timer ! (run-with-idle-timer lazy-highlight-initial-delay nil ! 'isearch-lazy-highlight-update))))) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. --- 2897,2979 ---- 'lazy-highlight-cleanup "22.1") + (defun isearch-lazy-highlight-move-shadow () + "Move the lazy highlight \"shadow\" to the current match position." + (if isearch-lazy-highlight-shadowed + (overlay-put isearch-lazy-highlight-shadowed 'face lazy-highlight-face)) + (let ((ovs (if isearch-forward + (overlays-in isearch-other-end (point)) + (overlays-in (point) isearch-other-end))) + ov) + (while ovs + (setq ov (car ovs) + ovs (cdr ovs)) + (when (memq ov isearch-lazy-highlight-overlays) + (overlay-put ov 'face nil) + (setq isearch-lazy-highlight-shadowed ov))))) + (defun isearch-lazy-highlight-new-loop (&optional beg end) "Cleanup any previous `lazy-highlight' loop and begin a new one. BEG and END specify the bounds within which highlighting should occur. This is called when `isearch-update' is invoked (which can cause the search string to change or the window to scroll). It is also used by other Emacs features." ! (if (and (null executing-kbd-macro) ! (sit-for 0) ;make sure (window-start) is credible ! (or (not (equal isearch-string ! isearch-lazy-highlight-last-string)) ! (not (eq (selected-window) ! isearch-lazy-highlight-window)) ! (not (eq isearch-lazy-highlight-case-fold-search ! isearch-case-fold-search)) ! (not (eq isearch-lazy-highlight-regexp ! isearch-regexp)) ! (not (eq isearch-lazy-highlight-word ! isearch-word)) ! (not (eq isearch-lazy-highlight-lax-whitespace ! isearch-lax-whitespace)) ! (not (eq isearch-lazy-highlight-regexp-lax-whitespace ! isearch-regexp-lax-whitespace)) ! (not (= (window-start) ! isearch-lazy-highlight-window-start)) ! (not (= (window-end) ; Window may have been split/joined. ! isearch-lazy-highlight-window-end)) ! (not (eq isearch-forward ! isearch-lazy-highlight-forward)) ! ;; In case we are recovering from an error. ! (not (equal isearch-error ! isearch-lazy-highlight-error)))) ! ;; something important did indeed change ! (progn ! (lazy-highlight-cleanup t) ;kill old loop & remove overlays ! (setq isearch-lazy-highlight-error isearch-error) ! ;; It used to check for `(not isearch-error)' here, but actually ! ;; lazy-highlighting might find matches to highlight even when ! ;; `isearch-error' is non-nil. (Bug#9918) ! (setq isearch-lazy-highlight-start-limit beg ! isearch-lazy-highlight-end-limit end) ! (setq isearch-lazy-highlight-window (selected-window) ! isearch-lazy-highlight-window-start (window-start) ! isearch-lazy-highlight-window-end (window-end) ! isearch-lazy-highlight-start (point) ! isearch-lazy-highlight-end (point) ! isearch-lazy-highlight-point (point) ! isearch-lazy-highlight-shadowed nil ! isearch-lazy-highlight-wrapped nil ! isearch-lazy-highlight-last-string isearch-string ! isearch-lazy-highlight-case-fold-search isearch-case-fold-search ! isearch-lazy-highlight-regexp isearch-regexp ! isearch-lazy-highlight-lax-whitespace isearch-lax-whitespace ! isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace ! isearch-lazy-highlight-word isearch-word ! isearch-lazy-highlight-forward isearch-forward) ! (unless (equal isearch-string "") ! (setq isearch-lazy-highlight-timer ! (run-with-idle-timer lazy-highlight-initial-delay nil ! 'isearch-lazy-highlight-update)))) ! ! ;; Swap the previously "shadowed" lazy highlight overlay for the new one. ! (isearch-lazy-highlight-move-shadow))) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. *************** *** 3033,3039 **** ;; 1000 is higher than ediff's 100+, ;; but lower than isearch main overlay's 1001 (overlay-put ov 'priority 1000) ! (overlay-put ov 'face lazy-highlight-face) (overlay-put ov 'window (selected-window)))) (if isearch-lazy-highlight-forward (setq isearch-lazy-highlight-end (point)) --- 3057,3069 ---- ;; 1000 is higher than ediff's 100+, ;; but lower than isearch main overlay's 1001 (overlay-put ov 'priority 1000) ! (if (if isearch-lazy-highlight-forward ! (or (<= me isearch-other-end) ! (>= mb isearch-lazy-highlight-point)) ! (or (<= me isearch-lazy-highlight-point) ! (>= mb isearch-other-end))) ! (overlay-put ov 'face lazy-highlight-face) ! (setq isearch-lazy-highlight-shadowed ov)) (overlay-put ov 'window (selected-window)))) (if isearch-lazy-highlight-forward (setq isearch-lazy-highlight-end (point)) -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Feb 2013 22:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136105380613876 (code B ref 13402); Sat, 16 Feb 2013 22:31:01 +0000 Received: (at 13402) by debbugs.gnu.org; 16 Feb 2013 22:30:06 +0000 Received: from localhost ([127.0.0.1]:59553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6qGk-0003bk-5P for submit@debbugs.gnu.org; Sat, 16 Feb 2013 17:30:06 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:38465 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U6qGh-0003b5-BP for 13402@debbugs.gnu.org; Sat, 16 Feb 2013 17:30:04 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 6754A201B6C820; Sat, 16 Feb 2013 14:29:11 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> Date: Sat, 16 Feb 2013 23:50:39 +0200 In-Reply-To: <20130215132004.GB2907@acm.acm> (Alan Mackenzie's message of "Fri, 15 Feb 2013 13:20:04 +0000") Message-ID: <87ip5s3tq8.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > OK, here's a better patch. As already suggested, every match now has its > lazy-highlight overlay, just that the one overlapping the current match > no longer has the 'face property set. I don't think there can be more > than one overlapping match. This approach preserves the optimisation > with `C-s'. Yes, this is a more reliable approach, and it works correctly now in isearch. It fails only in `replace-highlight', i.e. after running `query-replace' and answering `n' to skip to the next match, it doesn't re-highlight the previous skipped match. But in principle I don't oppose your approach provided it's working correctly in all cases. While testing I noticed an interesting effect. Test case: emacs -Q Eval (info "(elisp) Syntax Table Internals") Place point at the start of the second paragraph (" Each entry in a ...."). Type `C-s C-w C-w' that puts " each" to the search string. Type another C-s (isearch-repeat-forward) that will go to the second match of " each" (try to use a smaller font to be able to see both matches of the string " each" on the same screen). As soon as the cursor leaves the first match, its highlighting (with a different color for a lazy match) grows to a wider region previously hidden by your patch. This indicates that surprises will remain even after using your approach. Another case surprising to users is reversing the search direction - e.g. when the cursor is on the second match, type `C-r' and see how the lazy-highlighted first match shrinks from multi-line to single-line. It seems nothing can be done to fix this case. From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Feb 2013 10:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.1361095890388 (code B ref 13402); Sun, 17 Feb 2013 10:12:01 +0000 Received: (at 13402) by debbugs.gnu.org; 17 Feb 2013 10:11:30 +0000 Received: from localhost ([127.0.0.1]:60078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U71DV-00006D-QY for submit@debbugs.gnu.org; Sun, 17 Feb 2013 05:11:30 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:37057 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U71DS-00005v-KM for 13402@debbugs.gnu.org; Sun, 17 Feb 2013 05:11:28 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id EE54D201F82E3A; Sun, 17 Feb 2013 02:10:31 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> <87ip5s3tq8.fsf@mail.jurta.org> Date: Sun, 17 Feb 2013 12:03:45 +0200 In-Reply-To: <87ip5s3tq8.fsf@mail.jurta.org> (Juri Linkov's message of "Sat, 16 Feb 2013 23:50:39 +0200") Message-ID: <871ucfz3gp.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > It fails only in `replace-highlight', i.e. after running `query-replace' > and answering `n' to skip to the next match, it doesn't re-highlight > the previous skipped match. Also I noticed that typing `C-s M-s SPC C-s' quickly causes the error: Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p nil) overlays-in(nil 244) (if isearch-forward (overlays-in isearch-other-end (point)) (overlays-in = (point) isearch-other-end)) (let ((ovs (if isearch-forward (overlays-in isearch-other-end (point)) (o= verlays-in (point) isearch-other-end))) ov) (while ovs (setq ov (car ovs) o= vs (cdr ovs)) (if (memq ov isearch-lazy-highlight-overlays) (progn (overlay= -put ov (quote face) nil) (setq isearch-lazy-highlight-shadowed ov))))) isearch-lazy-highlight-move-shadow() (if (and (null executing-kbd-macro) (sit-for 0) (or (not (equal isearch-s= tring isearch-lazy-highlight-last-string)) (not (eq (selected-window) isear= ch-lazy-highlight-window)) (not (eq isearch-lazy-highlight-case-fold-search= isearch-case-fold-search)) (not (eq isearch-lazy-highlight-regexp isearch-= regexp)) (not (eq isearch-lazy-highlight-word isearch-word)) (not (eq isear= ch-lazy-highlight-lax-whitespace isearch-lax-whitespace)) (not (eq isearch-= lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace)) (not (= =3D (window-start) isearch-lazy-highlight-window-start)) (not (=3D (window-= end) isearch-lazy-highlight-window-end)) (not (eq isearch-forward isearch-l= azy-highlight-forward)) (not (equal isearch-error isearch-lazy-highlight-er= ror)))) (progn (lazy-highlight-cleanup t) (setq isearch-lazy-highlight-erro= r isearch-error) (setq isearch-lazy-highlight-start-limit beg isearch-lazy-= highlight-end-limit end) (setq isearch-lazy-highlight-window (selected-wind= ow) isearch-lazy-highlight-window-start (window-start) isearch-lazy-highlig= ht-window-end (window-end) isearch-lazy-highlight-start (point) isearch-laz= y-highlight-end (point) isearch-lazy-highlight-point (point) isearch-lazy-h= ighlight-shadowed nil isearch-lazy-highlight-wrapped nil isearch-lazy-highl= ight-last-string isearch-string isearch-lazy-highlight-case-fold-search ise= arch-case-fold-search isearch-lazy-highlight-regexp isearch-regexp isearch-= lazy-highlight-lax-whitespace isearch-lax-whitespace isearch-lazy-highlight= -regexp-lax-whitespace isearch-regexp-lax-whitespace isearch-lazy-highlight= -word isearch-word isearch-lazy-highlight-forward isearch-forward) (if (equ= al isearch-string "") nil (setq isearch-lazy-highlight-timer (run-with-idle= -timer lazy-highlight-initial-delay nil (quote isearch-lazy-highlight-updat= e))))) (isearch-lazy-highlight-move-shadow)) isearch-lazy-highlight-new-loop() isearch-update() isearch-toggle-lax-whitespace() call-interactively(isearch-toggle-lax-whitespace nil nil) Oh, and another problem: after customizing `lazy-highlight-cleanup' to `nil= ', exiting isearch doesn't leave the current match lazy-highlighted. The problem is that other features are expecting that _all_ matches are lazy-highlighted, so I'm starting to doubt whether it's worth the trouble trying to improve such cosmetic issue? From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Feb 2013 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136128556716753 (code B ref 13402); Tue, 19 Feb 2013 14:53:02 +0000 Received: (at 13402) by debbugs.gnu.org; 19 Feb 2013 14:52:47 +0000 Received: from localhost ([127.0.0.1]:36260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7oYo-0004M6-HD for submit@debbugs.gnu.org; Tue, 19 Feb 2013 09:52:47 -0500 Received: from colin.muc.de ([193.149.48.1]:42037 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U7oYk-0004Lp-B3 for 13402@debbugs.gnu.org; Tue, 19 Feb 2013 09:52:44 -0500 Received: (qmail 50865 invoked by uid 3782); 19 Feb 2013 14:51:35 -0000 Received: from acm.muc.de (pD955791A.dip.t-dialin.net [217.85.121.26]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 19 Feb 2013 15:51:29 +0100 Received: (qmail 4615 invoked by uid 1000); 19 Feb 2013 14:50:57 -0000 Date: Tue, 19 Feb 2013 14:50:57 +0000 Message-ID: <20130219145057.GA4377@acm.acm> References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> <87ip5s3tq8.fsf@mail.jurta.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ip5s3tq8.fsf@mail.jurta.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -3.2 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) Hi, Juri. I'm answering both your last two emails together, here. On Sat, Feb 16, 2013 at 11:50:39PM +0200, Juri Linkov wrote: > > OK, here's a better patch. As already suggested, every match now has its > > lazy-highlight overlay, just that the one overlapping the current match > > no longer has the 'face property set. I don't think there can be more > > than one overlapping match. This approach preserves the optimisation > > with `C-s'. > Yes, this is a more reliable approach, and it works correctly now in isearch. > It fails only in `replace-highlight', i.e. after running `query-replace' > and answering `n' to skip to the next match, it doesn't re-highlight > the previous skipped match. Fixed, see patch below. > But in principle I don't oppose your approach provided it's working > correctly in all cases. .../textmodes/ispell.el also uses the lazy highlighting, so it will need amending too. > While testing I noticed an interesting effect. Test case: > emacs -Q > Eval (info "(elisp) Syntax Table Internals") > Place point at the start of the second paragraph > (" Each entry in a ...."). > Type `C-s C-w C-w' that puts " each" to the search string. > Type another C-s (isearch-repeat-forward) that will go to the second > match of " each" (try to use a smaller font to be able to see both > matches of the string " each" on the same screen). > As soon as the cursor leaves the first match, its highlighting > (with a different color for a lazy match) grows to a wider region > previously hidden by your patch. Yes. This is logical - the (extended) lazy highlighting indicates what would get fully highlighted on a future (wrapped) repeated search. I'm not saying it's a feature, but it's certainly logical. ;-) > This indicates that surprises will remain even after using your approach. > Another case surprising to users is reversing the search direction - > e.g. when the cursor is on the second match, type `C-r' and see how > the lazy-highlighted first match shrinks from multi-line to single-line. > It seems nothing can be done to fix this case. This is present even without my patch. This shrunk lazy highlight indicates precisely what would be matched on a repeated backward search. This is sort of logical too. It would be too much work to make the backward search match all the whitespace greedily. > Also I noticed that typing `C-s M-s SPC C-s' quickly causes the error: > Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p > nil) > overlays-in(nil 244) [ .... ] This is now fixed, too. It seems that `run-with-idle-timer' doesn't retain the current `let'-bindings when it runs, even though the documentation doesn't mention this. This is the reason for all these isearch-lazy-highlight-.... static variables shadowing dynamic ones. I've learnt something today. :-) > Oh, and another problem: after customizing `lazy-highlight-cleanup' to > `nil', exiting isearch doesn't leave the current match > lazy-highlighted. Yuck, what a variable! I've fixed this, too. > The problem is that other features are expecting that _all_ matches > are lazy-highlighted, so I'm starting to doubt whether it's worth the > trouble trying to improve such cosmetic issue? It made me seriously unhappy, to the point where I would have disabled whatever was causing it. It looks very scrappy, unlike the rest of Emacs. I predict, if we don't fix it, there will be quite a few angry bug reports, a bit like when the "fringe" was introduced in 21.1 with no way of disabling it, but probably not as bad. And this _is_ a regression, maybe not in the code, but certainly from the point of view of a user. It is true that this effect can be disabled by `isearch-toggle-lax-whitespace' but there is no way a normal user can find this out, apart from stumbling on it by luck. We can't really document this either. I'm surprised how difficult the fix is. Maybe lazy-highlighting should be refactored out of isearch.el and given a better interface. Here's the latest patch, which I think now works, apart from ispell.el. === modified file 'lisp/isearch.el' *** lisp/isearch.el 2013-02-01 23:38:41 +0000 --- lisp/isearch.el 2013-02-19 13:05:44 +0000 *************** *** 2862,2867 **** --- 2862,2870 ---- (defvar isearch-lazy-highlight-end-limit nil) (defvar isearch-lazy-highlight-start nil) (defvar isearch-lazy-highlight-end nil) + (defvar isearch-lazy-highlight-point nil) + (defvar isearch-lazy-highlight-shadowed nil) + (defvar isearch-lazy-highlight-other-end nil) (defvar isearch-lazy-highlight-timer nil) (defvar isearch-lazy-highlight-last-string nil) (defvar isearch-lazy-highlight-window nil) *************** *** 2882,2891 **** `lazy-highlight-cleanup' is non-nil." (interactive '(t)) (if (or force lazy-highlight-cleanup) ! (while isearch-lazy-highlight-overlays ! (delete-overlay (car isearch-lazy-highlight-overlays)) ! (setq isearch-lazy-highlight-overlays ! (cdr isearch-lazy-highlight-overlays)))) (when isearch-lazy-highlight-timer (cancel-timer isearch-lazy-highlight-timer) (setq isearch-lazy-highlight-timer nil))) --- 2885,2898 ---- `lazy-highlight-cleanup' is non-nil." (interactive '(t)) (if (or force lazy-highlight-cleanup) ! (progn ! (while isearch-lazy-highlight-overlays ! (delete-overlay (car isearch-lazy-highlight-overlays)) ! (setq isearch-lazy-highlight-overlays ! (cdr isearch-lazy-highlight-overlays))) ! (setq isearch-lazy-highlight-shadowed nil)) ! (when isearch-lazy-highlight-shadowed ! (overlay-put isearch-lazy-highlight-shadowed 'face lazy-highlight-face))) (when isearch-lazy-highlight-timer (cancel-timer isearch-lazy-highlight-timer) (setq isearch-lazy-highlight-timer nil))) *************** *** 2894,2955 **** 'lazy-highlight-cleanup "22.1") (defun isearch-lazy-highlight-new-loop (&optional beg end) "Cleanup any previous `lazy-highlight' loop and begin a new one. BEG and END specify the bounds within which highlighting should occur. This is called when `isearch-update' is invoked (which can cause the search string to change or the window to scroll). It is also used by other Emacs features." ! (when (and (null executing-kbd-macro) ! (sit-for 0) ;make sure (window-start) is credible ! (or (not (equal isearch-string ! isearch-lazy-highlight-last-string)) ! (not (eq (selected-window) ! isearch-lazy-highlight-window)) ! (not (eq isearch-lazy-highlight-case-fold-search ! isearch-case-fold-search)) ! (not (eq isearch-lazy-highlight-regexp ! isearch-regexp)) ! (not (eq isearch-lazy-highlight-word ! isearch-word)) ! (not (eq isearch-lazy-highlight-lax-whitespace ! isearch-lax-whitespace)) ! (not (eq isearch-lazy-highlight-regexp-lax-whitespace ! isearch-regexp-lax-whitespace)) ! (not (= (window-start) ! isearch-lazy-highlight-window-start)) ! (not (= (window-end) ; Window may have been split/joined. ! isearch-lazy-highlight-window-end)) ! (not (eq isearch-forward ! isearch-lazy-highlight-forward)) ! ;; In case we are recovering from an error. ! (not (equal isearch-error ! isearch-lazy-highlight-error)))) ! ;; something important did indeed change ! (lazy-highlight-cleanup t) ;kill old loop & remove overlays ! (setq isearch-lazy-highlight-error isearch-error) ! ;; It used to check for `(not isearch-error)' here, but actually ! ;; lazy-highlighting might find matches to highlight even when ! ;; `isearch-error' is non-nil. (Bug#9918) ! (setq isearch-lazy-highlight-start-limit beg ! isearch-lazy-highlight-end-limit end) ! (setq isearch-lazy-highlight-window (selected-window) ! isearch-lazy-highlight-window-start (window-start) ! isearch-lazy-highlight-window-end (window-end) ! isearch-lazy-highlight-start (point) ! isearch-lazy-highlight-end (point) ! isearch-lazy-highlight-wrapped nil ! isearch-lazy-highlight-last-string isearch-string ! isearch-lazy-highlight-case-fold-search isearch-case-fold-search ! isearch-lazy-highlight-regexp isearch-regexp ! isearch-lazy-highlight-lax-whitespace isearch-lax-whitespace ! isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace ! isearch-lazy-highlight-word isearch-word ! isearch-lazy-highlight-forward isearch-forward) ! (unless (equal isearch-string "") ! (setq isearch-lazy-highlight-timer ! (run-with-idle-timer lazy-highlight-initial-delay nil ! 'isearch-lazy-highlight-update))))) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. --- 2901,2984 ---- 'lazy-highlight-cleanup "22.1") + (defun isearch-lazy-highlight-move-shadow () + "Move the lazy highlight \"shadow\" to the current match position." + (overlay-put isearch-lazy-highlight-shadowed 'face lazy-highlight-face) + (let ((ovs (if isearch-forward + (overlays-in isearch-other-end (point)) + (overlays-in (point) isearch-other-end))) + ov) + (while ovs + (setq ov (car ovs) + ovs (cdr ovs)) + (when (memq ov isearch-lazy-highlight-overlays) + (overlay-put ov 'face nil) + (setq isearch-lazy-highlight-shadowed ov))))) + (defun isearch-lazy-highlight-new-loop (&optional beg end) "Cleanup any previous `lazy-highlight' loop and begin a new one. BEG and END specify the bounds within which highlighting should occur. This is called when `isearch-update' is invoked (which can cause the search string to change or the window to scroll). It is also used by other Emacs features." ! (if (and (null executing-kbd-macro) ! (sit-for 0) ;make sure (window-start) is credible ! (or (not (equal isearch-string ! isearch-lazy-highlight-last-string)) ! (not (eq (selected-window) ! isearch-lazy-highlight-window)) ! (not (eq isearch-lazy-highlight-case-fold-search ! isearch-case-fold-search)) ! (not (eq isearch-lazy-highlight-regexp ! isearch-regexp)) ! (not (eq isearch-lazy-highlight-word ! isearch-word)) ! (not (eq isearch-lazy-highlight-lax-whitespace ! isearch-lax-whitespace)) ! (not (eq isearch-lazy-highlight-regexp-lax-whitespace ! isearch-regexp-lax-whitespace)) ! (not (= (window-start) ! isearch-lazy-highlight-window-start)) ! (not (= (window-end) ; Window may have been split/joined. ! isearch-lazy-highlight-window-end)) ! (not (eq isearch-forward ! isearch-lazy-highlight-forward)) ! ;; In case we are recovering from an error. ! (not (equal isearch-error ! isearch-lazy-highlight-error)))) ! ;; something important did indeed change ! (progn ! (lazy-highlight-cleanup t) ;kill old loop & remove overlays ! (setq isearch-lazy-highlight-error isearch-error) ! ;; It used to check for `(not isearch-error)' here, but actually ! ;; lazy-highlighting might find matches to highlight even when ! ;; `isearch-error' is non-nil. (Bug#9918) ! (setq isearch-lazy-highlight-start-limit beg ! isearch-lazy-highlight-end-limit end) ! (setq isearch-lazy-highlight-window (selected-window) ! isearch-lazy-highlight-window-start (window-start) ! isearch-lazy-highlight-window-end (window-end) ! isearch-lazy-highlight-start (point) ! isearch-lazy-highlight-end (point) ! isearch-lazy-highlight-point (point) ! isearch-lazy-highlight-shadowed nil ! isearch-lazy-highlight-other-end isearch-other-end ! isearch-lazy-highlight-wrapped nil ! isearch-lazy-highlight-last-string isearch-string ! isearch-lazy-highlight-case-fold-search isearch-case-fold-search ! isearch-lazy-highlight-regexp isearch-regexp ! isearch-lazy-highlight-lax-whitespace isearch-lax-whitespace ! isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace ! isearch-lazy-highlight-word isearch-word ! isearch-lazy-highlight-forward isearch-forward) ! (unless (equal isearch-string "") ! (setq isearch-lazy-highlight-timer ! (run-with-idle-timer lazy-highlight-initial-delay nil ! 'isearch-lazy-highlight-update)))) ! ! ;; Swap the previously "shadowed" lazy highlight overlay for the new one. ! (when isearch-lazy-highlight-shadowed ! (isearch-lazy-highlight-move-shadow)))) (defun isearch-lazy-highlight-search () "Search ahead for the next or previous match, for lazy highlighting. *************** *** 3033,3039 **** ;; 1000 is higher than ediff's 100+, ;; but lower than isearch main overlay's 1001 (overlay-put ov 'priority 1000) ! (overlay-put ov 'face lazy-highlight-face) (overlay-put ov 'window (selected-window)))) (if isearch-lazy-highlight-forward (setq isearch-lazy-highlight-end (point)) --- 3062,3074 ---- ;; 1000 is higher than ediff's 100+, ;; but lower than isearch main overlay's 1001 (overlay-put ov 'priority 1000) ! (if (if isearch-lazy-highlight-forward ! (or (<= me isearch-lazy-highlight-other-end) ! (>= mb isearch-lazy-highlight-point)) ! (or (<= me isearch-lazy-highlight-point) ! (>= mb isearch-lazy-highlight-other-end))) ! (overlay-put ov 'face lazy-highlight-face) ! (setq isearch-lazy-highlight-shadowed ov)) (overlay-put ov 'window (selected-window)))) (if isearch-lazy-highlight-forward (setq isearch-lazy-highlight-end (point)) === modified file 'lisp/replace.el' *** lisp/replace.el 2013-02-01 23:38:41 +0000 --- lisp/replace.el 2013-02-17 22:16:38 +0000 *************** *** 2198,2203 **** --- 2198,2204 ---- replace-regexp-lax-whitespace) (isearch-case-fold-search case-fold-search) (isearch-forward t) + (isearch-other-end match-beg) (isearch-error nil)) (isearch-lazy-highlight-new-loop range-beg range-end)))) -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Feb 2013 11:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136136089814864 (code B ref 13402); Wed, 20 Feb 2013 11:49:02 +0000 Received: (at 13402) by debbugs.gnu.org; 20 Feb 2013 11:48:18 +0000 Received: from localhost ([127.0.0.1]:38769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U889p-0003rh-R7 for submit@debbugs.gnu.org; Wed, 20 Feb 2013 06:48:18 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:57269 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U889m-0003rY-Hl for 13402@debbugs.gnu.org; Wed, 20 Feb 2013 06:48:15 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 3FD66201F76C20; Wed, 20 Feb 2013 03:47:02 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> <87ip5s3tq8.fsf@mail.jurta.org> <20130219145057.GA4377@acm.acm> Date: Wed, 20 Feb 2013 12:49:04 +0200 In-Reply-To: <20130219145057.GA4377@acm.acm> (Alan Mackenzie's message of "Tue, 19 Feb 2013 14:50:57 +0000") Message-ID: <87ip5nql4v.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > I predict, if we don't fix it, there will be quite a few angry > bug reports, a bit like when the "fringe" was introduced in 21.1 > with no way of disabling it, but probably not as bad. Unlike fringes in 21.1, it's easy to disable this feature by customizing `search-whitespace-regexp' to nil. > And this _is_ a regression, maybe not in the code, but certainly from the > point of view of a user. It is true that this effect can be disabled by > `isearch-toggle-lax-whitespace' but there is no way a normal user can > find this out, apart from stumbling on it by luck. I think you are overestimating the seriousness of the problem. The highlighting effect that you don't like might seem peculiar but it has a logical explanation. Trying to change its logic to more complicated will introduce other problems that might seem illogical to other users. For example, consider the following test case: With `search-whitespace-regexp' customized to nil, try to put the cursor to the second space character in the string " Each entry" and type `C-M-s SPC'. It lazy-highlights the previous space character too (it's the first space character in the string). This is right. Now with your patch applied, add the character "+" to the search regexp, so that a complete search regexp is " +" and the cursor is on the second space character in the string " Each entry". The result is that the first space character is not lazy-highlighted. I think this is wrong. If you assume that the boundary of the current match should begin only from the leading character of the search string, then you have to allow the preceding match to be lazy-highlighted separately in its own right (in the above case the first space character in the string) because it matches the search regexp. IOW, what is more logical to do according to your approach is not to hide the lazy-highlighted match under point, but split it to two matches where the match preceding the current search position is lazy-highlighted and the second match under point is hidden. > We can't really document this either. Actually, documenting this effect is a very good idea that in any case should be done in emacs-24. > I'm surprised how difficult the fix is. That's is why I prefer to refrain from making hasty changes that might cause more problems in unexpected places making other users unhappy. From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Feb 2013 22:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136139999014219 (code B ref 13402); Wed, 20 Feb 2013 22:40:01 +0000 Received: (at 13402) by debbugs.gnu.org; 20 Feb 2013 22:39:50 +0000 Received: from localhost ([127.0.0.1]:40714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8IKL-0003hI-VC for submit@debbugs.gnu.org; Wed, 20 Feb 2013 17:39:50 -0500 Received: from colin.muc.de ([193.149.48.1]:13739 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8IKI-0003h7-2n for 13402@debbugs.gnu.org; Wed, 20 Feb 2013 17:39:47 -0500 Received: (qmail 28317 invoked by uid 3782); 20 Feb 2013 22:38:31 -0000 Received: from acm.muc.de (pD955714E.dip.t-dialin.net [217.85.113.78]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 20 Feb 2013 23:38:30 +0100 Received: (qmail 4336 invoked by uid 1000); 20 Feb 2013 22:37:59 -0000 Date: Wed, 20 Feb 2013 22:37:59 +0000 Message-ID: <20130220223759.GA2644@acm.acm> References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> <87ip5s3tq8.fsf@mail.jurta.org> <20130219145057.GA4377@acm.acm> <87ip5nql4v.fsf@mail.jurta.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ip5nql4v.fsf@mail.jurta.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -3.2 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) Hello again, Juri. On Wed, Feb 20, 2013 at 12:49:04PM +0200, Juri Linkov wrote: > I think you are overestimating the seriousness of the problem. It is going to be a big problem for a small number of users. I dare say the majority won't notice. > The highlighting effect that you don't like might seem peculiar > but it has a logical explanation. Trying to change its logic to > more complicated will introduce other problems that might seem illogical > to other users. Just as activating `search-whitespace-regexp' has done, you mean. ;-) > For example, consider the following test case: > With `search-whitespace-regexp' customized to nil, try to put the cursor > to the second space character in the string " Each entry" and type > `C-M-s SPC'. It lazy-highlights the previous space character too > (it's the first space character in the string). This is right. > Now with your patch applied, add the character "+" to the search regexp, > so that a complete search regexp is " +" and the cursor is on the second > space character in the string " Each entry". The result is that > the first space character is not lazy-highlighted. I think this is wrong. :-). I'm not sure. It has a certain logic behind it. I think a missing lazy-highlight is much less disturbing than an obtrusive one. > If you assume that the boundary of the current match should begin only > from the leading character of the search string, then you have to allow > the preceding match to be lazy-highlighted separately in its own right > (in the above case the first space character in the string) because > it matches the search regexp. That match overlaps the current match. > IOW, what is more logical to do according to your approach is not to hide > the lazy-highlighted match under point, but split it to two matches > where the match preceding the current search position is lazy-highlighted > and the second match under point is hidden. I don't agree. I think a match should either be highlighted completely or not at all. But we might be splitting hairs at this point. > > We can't really document this either. > Actually, documenting this effect is a very good idea > that in any case should be done in emacs-24. > > I'm surprised how difficult the fix is. > That's is why I prefer to refrain from making hasty changes that might > cause more problems in unexpected places making other users unhappy. I think I must now reluctantly agree with you here. There just aren't enough pretests left before Emacs 24.3 to test it properly. I grepped -l isearch, and it came up with over 70 matching files. grepping for isearch-lazy-highlight produced just 4 matches, the already identified files plus .../lisp/cedet/semantic/senator.el. How about installing the change in the trunk so that people can try it out? Anyhow, just for the sake of completeness, here is the part of the patch which fixes ispell.e: === modified file 'lisp/textmodes/ispell.el' *** lisp/textmodes/ispell.el 2013-01-01 09:11:05 +0000 --- lisp/textmodes/ispell.el 2013-02-20 21:11:47 +0000 *************** *** 2491,2506 **** (delete-overlay ispell-overlay))) (if (and ispell-lazy-highlight (boundp 'lazy-highlight-cleanup)) (if highlight ! (let ((isearch-string ! (concat ! "\\b" ! (regexp-quote (buffer-substring-no-properties start end)) ! "\\b")) ! (isearch-regexp t) ! (isearch-case-fold-search nil)) ! (isearch-lazy-highlight-new-loop ! (if (boundp 'reg-start) reg-start) ! (if (boundp 'reg-end) reg-end))) (lazy-highlight-cleanup lazy-highlight-cleanup) (setq isearch-lazy-highlight-last-string nil)))) --- 2491,2509 ---- (delete-overlay ispell-overlay))) (if (and ispell-lazy-highlight (boundp 'lazy-highlight-cleanup)) (if highlight ! (save-excursion ! (goto-char start) ! (let ((isearch-string ! (concat ! "\\b" ! (regexp-quote (buffer-substring-no-properties start end)) ! "\\b")) ! (isearch-regexp t) ! (isearch-case-fold-search nil) ! (isearch-other-end end)) ! (isearch-lazy-highlight-new-loop ! (if (boundp 'reg-start) reg-start) ! (if (boundp 'reg-end) reg-end)))) (lazy-highlight-cleanup lazy-highlight-cleanup) (setq isearch-lazy-highlight-last-string nil)))) -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Feb 2013 01:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136140882227284 (code B ref 13402); Thu, 21 Feb 2013 01:08:01 +0000 Received: (at 13402) by debbugs.gnu.org; 21 Feb 2013 01:07:02 +0000 Received: from localhost ([127.0.0.1]:40865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8Kcj-00075f-An for submit@debbugs.gnu.org; Wed, 20 Feb 2013 20:07:02 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:36151 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8Kcc-00075R-Ar for 13402@debbugs.gnu.org; Wed, 20 Feb 2013 20:06:55 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id C27072019AA326; Wed, 20 Feb 2013 17:05:34 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> <87ip5s3tq8.fsf@mail.jurta.org> <20130219145057.GA4377@acm.acm> <87ip5nql4v.fsf@mail.jurta.org> <20130220223759.GA2644@acm.acm> Date: Thu, 21 Feb 2013 02:45:31 +0200 In-Reply-To: <20130220223759.GA2644@acm.acm> (Alan Mackenzie's message of "Wed, 20 Feb 2013 22:37:59 +0000") Message-ID: <871ucaiirw.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> The result is that the first space character is not lazy-highlighted. >> I think this is wrong. > > :-). I'm not sure. It has a certain logic behind it. I think a missing > lazy-highlight is much less disturbing than an obtrusive one. Alan, I completely agree with you. Your logic makes perfect sense. An obtrusive lazy-highlight is too disturbing. But I also think that my logic makes sense as well since a missing lazy-highlight is too bad. Fortunately, it is possible to combine both logics with a small patch that you can see below. The key point is that the lazy-highlighting loop should start from the same position where the main search function found the beginning of the match! Currently the boundary of the lazy-highlighting loop starts at the end of the found match (the value of `(point)'). But the match found by the main search function (and highlighted by the primary face `isearch') begins at `isearch-other-end'. So currently they are mutually inconsistent. This patch moves the boundary of lazy-highlighting from the end of the found match to its beginning - like in the main search function. Thus it brings the logic of `isearch-lazy-highlight-search' closer to the logic of the main search function in `isearch-search'. In the result of removing this inconsistency, this patch passes the test case that you posted in your original bug report, i.e. placing point at the start of the second paragraph (" Each entry in a ....") and typing `C-s M-s C-e' (isearch-yank-line) doesn't highlight the gap preceding the paragraph with lazy-highlight face. And it also passes other tests that I tried. === modified file 'lisp/isearch.el' --- lisp/isearch.el 2013-02-01 23:38:41 +0000 +++ lisp/isearch.el 2013-02-21 00:45:05 +0000 @@ -2936,8 +2936,8 @@ (defun isearch-lazy-highlight-new-loop ( (setq isearch-lazy-highlight-window (selected-window) isearch-lazy-highlight-window-start (window-start) isearch-lazy-highlight-window-end (window-end) - isearch-lazy-highlight-start (point) - isearch-lazy-highlight-end (point) + isearch-lazy-highlight-start (or isearch-other-end (point)) + isearch-lazy-highlight-end (or isearch-other-end (point)) isearch-lazy-highlight-wrapped nil isearch-lazy-highlight-last-string isearch-string isearch-lazy-highlight-case-fold-search isearch-case-fold-search From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Feb 2013 12:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136144977526042 (code B ref 13402); Thu, 21 Feb 2013 12:30:02 +0000 Received: (at 13402) by debbugs.gnu.org; 21 Feb 2013 12:29:35 +0000 Received: from localhost ([127.0.0.1]:41613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8VHL-0006lz-6h for submit@debbugs.gnu.org; Thu, 21 Feb 2013 07:29:35 -0500 Received: from colin.muc.de ([193.149.48.1]:29468 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8VHH-0006lq-Vy for 13402@debbugs.gnu.org; Thu, 21 Feb 2013 07:29:33 -0500 Received: (qmail 90254 invoked by uid 3782); 21 Feb 2013 12:28:13 -0000 Received: from acm.muc.de (pD9519D48.dip.t-dialin.net [217.81.157.72]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 21 Feb 2013 13:28:11 +0100 Received: (qmail 4235 invoked by uid 1000); 21 Feb 2013 12:27:40 -0000 Date: Thu, 21 Feb 2013 12:27:40 +0000 Message-ID: <20130221122739.GA3647@acm.acm> References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> <87ip5s3tq8.fsf@mail.jurta.org> <20130219145057.GA4377@acm.acm> <87ip5nql4v.fsf@mail.jurta.org> <20130220223759.GA2644@acm.acm> <871ucaiirw.fsf@mail.jurta.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871ucaiirw.fsf@mail.jurta.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.3 (---) Hi, Juri. On Thu, Feb 21, 2013 at 02:45:31AM +0200, Juri Linkov wrote: > Fortunately, it is possible to combine both logics > with a small patch that you can see below. > The key point is that the lazy-highlighting loop should start > from the same position where the main search function found > the beginning of the match! Hey, that's brilliant! It simply works, without all the added (or alternative) complexity of my patch. > Currently the boundary of the lazy-highlighting loop starts at the end > of the found match (the value of `(point)'). But the match found by > the main search function (and highlighted by the primary face `isearch') > begins at `isearch-other-end'. So currently they are mutually inconsistent. > This patch moves the boundary of lazy-highlighting from the end > of the found match to its beginning - like in the main search function. > Thus it brings the logic of `isearch-lazy-highlight-search' closer to > the logic of the main search function in `isearch-search'. > In the result of removing this inconsistency, this patch passes > the test case that you posted in your original bug report, > i.e. placing point at the start of the second paragraph > (" Each entry in a ....") and typing `C-s M-s C-e' (isearch-yank-line) > doesn't highlight the gap preceding the paragraph with lazy-highlight face. > And it also passes other tests that I tried. It seems to work for ispell too. What more could one ask for? Can we install this into the emacs-24 branch? It satisfies Glenn's criterion of a week ago, "...and you are sure the fix is safe". -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Glenn Morris Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Feb 2013 17:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Juri Linkov , 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136146665025880 (code B ref 13402); Thu, 21 Feb 2013 17:11:01 +0000 Received: (at 13402) by debbugs.gnu.org; 21 Feb 2013 17:10:50 +0000 Received: from localhost ([127.0.0.1]:42704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8ZfV-0006jN-NC for submit@debbugs.gnu.org; Thu, 21 Feb 2013 12:10:49 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:36910) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8ZfS-0006jE-Vg for 13402@debbugs.gnu.org; Thu, 21 Feb 2013 12:10:47 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1U8ZeC-0005ir-Hp; Thu, 21 Feb 2013 12:09:28 -0500 From: Glenn Morris References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> <87ip5s3tq8.fsf@mail.jurta.org> <20130219145057.GA4377@acm.acm> <87ip5nql4v.fsf@mail.jurta.org> <20130220223759.GA2644@acm.acm> <871ucaiirw.fsf@mail.jurta.org> <20130221122739.GA3647@acm.acm> X-Spook: ISEC UOP Peking lynch FBI United Nations Aladdin advisors X-Ran: \h(qdrCt30,Z387JkLkX%9;o$3\%7PxA/Y-L]XsGH(HtJ.A*=KtZ\L\IM+^UEM27:wYaeh X-Hue: green X-Attribution: GM Date: Thu, 21 Feb 2013 12:09:28 -0500 In-Reply-To: <20130221122739.GA3647@acm.acm> (Alan Mackenzie's message of "Thu, 21 Feb 2013 12:27:40 +0000") Message-ID: <8lfw0pfvav.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -5.7 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.6 (-------) Alan Mackenzie wrote: > Can we install this into the emacs-24 branch? It satisfies Glenn's > criterion of a week ago, "...and you are sure the fix is safe". If you and Juri both agree on that, OK. From unknown Sun Jun 22 00:53:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Feb 2013 17:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13402 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Glenn Morris Cc: Alan Mackenzie , 13402@debbugs.gnu.org Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136146902629540 (code B ref 13402); Thu, 21 Feb 2013 17:51:01 +0000 Received: (at 13402) by debbugs.gnu.org; 21 Feb 2013 17:50:26 +0000 Received: from localhost ([127.0.0.1]:42738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8aHp-0007gP-Rh for submit@debbugs.gnu.org; Thu, 21 Feb 2013 12:50:26 -0500 Received: from ps18281.dreamhost.com ([69.163.218.105]:41243 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U8aHn-0007gH-2h for 13402@debbugs.gnu.org; Thu, 21 Feb 2013 12:50:24 -0500 Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 5D8F72000BBD60; Thu, 21 Feb 2013 09:49:03 -0800 (PST) From: Juri Linkov Organization: JURTA References: <20130110132530.GA2805@acm.acm> <20130214200937.GA3336@acm.acm> <87d2w2ggsh.fsf@mail.jurta.org> <87liapan32.fsf@mail.jurta.org> <20130215132004.GB2907@acm.acm> <87ip5s3tq8.fsf@mail.jurta.org> <20130219145057.GA4377@acm.acm> <87ip5nql4v.fsf@mail.jurta.org> <20130220223759.GA2644@acm.acm> <871ucaiirw.fsf@mail.jurta.org> <20130221122739.GA3647@acm.acm> <8lfw0pfvav.fsf@fencepost.gnu.org> Date: Thu, 21 Feb 2013 19:48:04 +0200 In-Reply-To: <8lfw0pfvav.fsf@fencepost.gnu.org> (Glenn Morris's message of "Thu, 21 Feb 2013 12:09:28 -0500") Message-ID: <874nh5blt7.fsf@mail.jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.0 (/) >> Can we install this into the emacs-24 branch? It satisfies Glenn's >> criterion of a week ago, "...and you are sure the fix is safe". > > If you and Juri both agree on that, OK. So I installed into the emacs-24 branch. I had to add more comments because in `isearch-lazy-highlight-start' there is a similar assignment of `point' to `isearch-lazy-highlight-start' that shouldn't be changed, because it's used for other purposes. I've explained the difference in the comments. Also the 1-line change in replace.el like in Alan's patch was still necessary. The change in ispell.el is not necessary but I added the let-bindings like in other places that use lazy-highlighting as a precaution against potential problems.