From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dani Moncayo Newsgroups: gmane.emacs.bugs Subject: bug#9185: 24.0.50; "C-s M-p" does not bring the tip of the search ring Date: Thu, 25 Aug 2011 12:10:14 +0200 Message-ID: References: <87oc0c176d.fsf@mail.jurta.org> <87fwkuppz3.fsf@mail.jurta.org> <8739gtg0wp.fsf@mail.jurta.org> <87liukxxtj.fsf@mail.jurta.org> <87ei0aizl8.fsf@mail.jurta.org> <878vqid5qe.fsf@mail.jurta.org> <87aaaxq35c.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1314267035 6072 80.91.229.12 (25 Aug 2011 10:10:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 25 Aug 2011 10:10:35 +0000 (UTC) Cc: 9185@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 25 12:10:31 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QwWtK-00038H-5v for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Aug 2011 12:10:30 +0200 Original-Received: from localhost ([::1]:52379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwWtJ-0002Gh-Km for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Aug 2011 06:10:29 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwWtG-0002DF-60 for bug-gnu-emacs@gnu.org; Thu, 25 Aug 2011 06:10:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwWtE-0003K8-Ci for bug-gnu-emacs@gnu.org; Thu, 25 Aug 2011 06:10:26 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwWtE-0003K1-AI for bug-gnu-emacs@gnu.org; Thu, 25 Aug 2011 06:10:24 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QwWvl-0005T6-Pk; Thu, 25 Aug 2011 06:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dani Moncayo Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 25 Aug 2011 10:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9185 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9185-submit@debbugs.gnu.org id=B9185.131426717721009 (code B ref 9185); Thu, 25 Aug 2011 10:13:01 +0000 Original-Received: (at 9185) by debbugs.gnu.org; 25 Aug 2011 10:12:57 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QwWvf-0005Sn-OW for submit@debbugs.gnu.org; Thu, 25 Aug 2011 06:12:56 -0400 Original-Received: from mail-yw0-f44.google.com ([209.85.213.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QwWvd-0005Sf-4r for 9185@debbugs.gnu.org; Thu, 25 Aug 2011 06:12:53 -0400 Original-Received: by ywe9 with SMTP id 9so1506882ywe.3 for <9185@debbugs.gnu.org>; Thu, 25 Aug 2011 03:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yflE6mE9DSkFERY6dNy8GvhxqlFcbtOKDdSDc5Iug4Q=; b=dCBTdHR5ELBPrOChnCtUL6bA/tEESNByiCOFbbRwrrq5qI19BLFKdxsIkbsoiNm5FI 7ncqSgITjGShCs74Avgx/a1jNqjJopKd3m61i/UmF1yS8KP1nj096uqymplNDTCyD7id vPZ9ZHYiANuDtDDyOfDBg0d440OMuRhrpyolk= Original-Received: by 10.236.136.41 with SMTP id v29mr39351714yhi.80.1314267014473; Thu, 25 Aug 2011 03:10:14 -0700 (PDT) Original-Received: by 10.236.202.129 with HTTP; Thu, 25 Aug 2011 03:10:14 -0700 (PDT) In-Reply-To: <87aaaxq35c.fsf@mail.jurta.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 25 Aug 2011 06:13:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) 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:50332 Archived-At: >> [*] FWIW: This is indeed the current behavior (use the last entry if >> the minibuffer is empty), but I don't find it very suitable. =A0If the >> user wanted to use the last entry, s?he would have typed M-p. >> Therefore, IMO TRT here would be to return to Isearch with an empty >> string. > > I suppose the last entry is used because otherwise an empty search > string makes no sense. It makes sense, I think: by "to set an empty search string" I mean to return to the same state that had at the very beginning the Isearch session, i.e., as if the user had deleted the current search string by typing repeatedly. >=A0I have nothing against this functionality > because I never exit from the M-e minibuffer with empty input. Neither me. So this is not a very important issue (at least to us), and we can leave it for now. But I believe that setting an empty search string would be TRT in that case. >> Another failing use-case: >> 0. C-s a C-s b C-s c C-s d >> 1. C-s C-s =A0=A0 =A0 =A0 --> "d" is selected (ok). >> 2. M-p M-p =A0--> "b" is selected (ok). >> 3. M-p =A0 =A0 =A0 =A0 =A0 =A0--> "a" should have been selected, but I s= ee that >> "b" remains selected instead. > > We can't reliably count the number of typed M-p in `read-from-minibuffer' > in `isearch-edit-string' to adjust the index accordingly and to add the > same number of typed M-p to the index. =A0There is no reliable way to do = this: As you know, I still lack the knowledge of Elisp to help you in implementation details, so I can say very little about this. But I think I should be possible to implement, since the intended behavior is well defined and relatively simple: * At the beggining of the Isearch session, the index would start at the top of the ring (as does now). * During the Isearch session, each typed M-p/M-n should use the index to retrieve the suitable entry, and then should update the index, regardless of whether we are in the minibuffer or outside it. IMO, this is the behaviour most users would expect. But if you find it difficult to implement, you can adopt (by now) the alternative behavior you've pointed out: > Since `read-from-minibuffer' can't return the exact number of typed `M-p' > then I think that M-p after `M-e M-p M-p ' should start from the > top of of the search ring, so `C-s C-s M-p M-p RET M-p' should select "d"= . > This will provide a predictable result. Since this is a different issue than the original one of this bug report, I could file a separate bug asking for the wanted behavior. WDYT? --=20 Dani Moncayo