From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Date: Wed, 20 Feb 2013 12:49:04 +0200 Organization: JURTA Message-ID: <87ip5nql4v.fsf@mail.jurta.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361360884 21198 80.91.229.3 (20 Feb 2013 11:48:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2013 11:48:04 +0000 (UTC) Cc: 13402@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Feb 20 12:48:27 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U889w-0004K8-A5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Feb 2013 12:48:24 +0100 Original-Received: from localhost ([::1]:52185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U889c-0001Ei-1o for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Feb 2013 06:48:04 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U889U-0001Cc-KO for bug-gnu-emacs@gnu.org; Wed, 20 Feb 2013 06:48:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U889Q-0005y7-9X for bug-gnu-emacs@gnu.org; Wed, 20 Feb 2013 06:47:56 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U889Q-0005xx-63 for bug-gnu-emacs@gnu.org; Wed, 20 Feb 2013 06:47:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U88AY-0003sg-7s for bug-gnu-emacs@gnu.org; Wed, 20 Feb 2013 06:49:02 -0500 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 13402-submit@debbugs.gnu.org id=B13402.136136089814864 (code B ref 13402); Wed, 20 Feb 2013 11:49:02 +0000 Original-Received: (at 13402) by debbugs.gnu.org; 20 Feb 2013 11:48:18 +0000 Original-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 Original-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 Original-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) In-Reply-To: <20130219145057.GA4377@acm.acm> (Alan Mackenzie's message of "Tue, 19 Feb 2013 14:50:57 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:71555 Archived-At: > 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.