From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#22118: 23.2; Hitting ^W in a search selects the wrong word. Date: Thu, 10 Dec 2015 12:10:28 +0000 Message-ID: <20151210121027.GA3978@acm.fritz.box> References: <20151210092550.6224.qmail@mail.muc.de> <56694D83.3080902@codersco.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1449749368 17603 80.91.229.3 (10 Dec 2015 12:09:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Dec 2015 12:09:28 +0000 (UTC) Cc: 22118@debbugs.gnu.org To: Jan-Mark Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 10 13:09:17 2015 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 1a7024-0000Mf-Gm for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Dec 2015 13:09:12 +0100 Original-Received: from localhost ([::1]:40665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a7023-0002fX-PM for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Dec 2015 07:09:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a701z-0002eR-0v for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2015 07:09:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a701u-0002au-1f for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2015 07:09:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a701t-0002ap-Uy for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2015 07:09:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a701t-0008BS-PM for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2015 07:09:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Dec 2015 12:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22118 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22118-submit@debbugs.gnu.org id=B22118.144974931131419 (code B ref 22118); Thu, 10 Dec 2015 12:09:01 +0000 Original-Received: (at 22118) by debbugs.gnu.org; 10 Dec 2015 12:08:31 +0000 Original-Received: from localhost ([127.0.0.1]:38640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a701L-0008Ac-C8 for submit@debbugs.gnu.org; Thu, 10 Dec 2015 07:08:31 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:58174) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a701E-0008AP-SA for 22118@debbugs.gnu.org; Thu, 10 Dec 2015 07:08:25 -0500 Original-Received: (qmail 83922 invoked by uid 3782); 10 Dec 2015 12:08:19 -0000 Original-Received: from acm.muc.de (p548A4368.dip0.t-ipconnect.de [84.138.67.104]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 10 Dec 2015 13:08:18 +0100 Original-Received: (qmail 4118 invoked by uid 1000); 10 Dec 2015 12:10:28 -0000 Content-Disposition: inline In-Reply-To: <56694D83.3080902@codersco.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:109832 Archived-At: Hello, Jan-Mark. On Thu, Dec 10, 2015 at 11:01:39AM +0100, Jan-Mark wrote: > Hi Alan, > Thanks for your swift response and all the work you do on my favorite > editor. People like you improve my life. Thanks, that's appreciated. Just one small request: when you reply, would you please leave the Cc: to the bug archive. That way, there's a full record of the bug on the public list. > >> Note that if you are not in 'last-occurrence' state, there is no > >> problem, even at the last line. This bug only manifests itself if ^S has > >> been hit until it shows "Failing the I-search" in the minibuffer. > > Why is this behaviour a bug? I think that the effect of ^W in > > "last-occurrence" state is probably undefined in the manual. Adding > > "_aap" to the search string for each ^W does give the user feedback that > > the ^W has actually been received and processed. > Depending on how you define "bug". :-) Adding "_aap" is definitely what > you would expect. > There are three problems IMHO that make this a "bug": > 1) The screen is inconsistent. The minibuffer shows a "aap_noot_aap" but > the text buffer window's highlighting is not updated, only "aap_noot" is > highlighted. Don't forget, that by this stage the text in the minibuffer indicates "not found". So the main window highlights as much text as was found, the minibuffer indicates the current search string, and any lazy highlighting shows where the current search string would be found earlier on. All of this _is_ in the manual, on page "Errors in Incremental Search". > 2) Hitting ^W again will add an other "_aap" (consistent with the end of > the highlighting) which is unexpected to say the least. The minibuffer > will contain "aap_noot_aap_aap" which is nowhere in the text. This is true: the minibuffer shows what you are searching for. This indeed is nowhere in the text, but it's what you're searching for. > 3) Not hitting ^W again, but ^S will wrap the search around looking for > what is stated in the minibuffer ("aap_noot_aap") not what is > highlighted in the text buffer window ("aap_noot"). The highlighting > however is correct again ("aap_noot_aap"). The search is ALWAYS for what's in the minibuffer. Once you hit ^S again, the search becomes wrapped, and is no longer failing: it finds "aap_noot_aap". > > What do you think should happen in these circumstances? Does the current > > behaviour actually give you problems? > Depending on how you define "problems". :-P However, there are two > different ways emacs could deal with this that would definitely improve > the ease of understanding and ease of use. > a) The most consistent behavior, IMHO, would be to update the > highlighting in the text buffer window. This way the the text buffer and > mini buffer will be consistent. This way I don't have to check both to > find out what is going on. But when the search has failed, they should be different: in the main window, you can sea the bit that matched, and in the minibuffer, in bright red, you can see the bit that didn't match. I think you're asking for the distinction between successful and failing searches to be removed. This would surely be a Bad Thing. > b) What would help me (personally) more would be if emacs would go back > into search mode, highlight the whole search text in the text buffer > window and remove the "Failing I-search:" from the mini buffer. The > rational behind this is that changing the search string kind of "resets" > the search status to the "default". Internally, Isearch does indeed do this: it searches for the complete string from the starting point each time you type a new character. But if it has already failed, it's going to stay failed unless something like a C-s make the search wrap. > I understand that if an I-search has failed extending the search string > would keep you in the same search state (I.e., the last match.) However, > by that reasoning hitting ^S should also not change the state. So I vote > for behavior b) but I could live with behavior a). > However I strongly feel, the mini buffer and the text buffer should be > consistent. They are the same as long as a search hasn't yet failed. If it has, the minibuffer shows what you're searching for, the text buffer what you have found. > If I type ^S until I find the last entry, hitting ^W appends > "_aap" and updates the text buffer window. If I type ^S until I find the > last entry, hit ^S again (going into Failing I-search) hitting ^W also > appends "_aap" but does not update the text buffer window. With the best will in the world, I honestly don't think there's a bug here. Could I ask you to have another look at that manual page ("Errors in Incremental Search" in the Emacs manual) and carefully compare what you read there with what you see on the screen. By the way, Emacs 23.2 is now pretty old. You might want to consider upgrading to a newer version. The current released version is 24.5. > Regards, > Jan-Mark -- Alan Mackenzie (Nuremberg, Germany).