From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Isearch: retrieve last successful search string from when you quit (`C-g') Date: Mon, 1 Oct 2012 08:17:49 -0700 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1349104765 26516 80.91.229.3 (1 Oct 2012 15:19:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Oct 2012 15:19:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Dani Moncayo'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 01 17:19:28 2012 Return-path: Envelope-to: ged-emacs-devel@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 1TIhm5-0001M1-OD for ged-emacs-devel@m.gmane.org; Mon, 01 Oct 2012 17:19:13 +0200 Original-Received: from localhost ([::1]:34350 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIhm0-0007NV-8T for ged-emacs-devel@m.gmane.org; Mon, 01 Oct 2012 11:19:08 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIhlT-0007Hj-Oh for emacs-devel@gnu.org; Mon, 01 Oct 2012 11:19:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TIhl3-0005mN-MT for emacs-devel@gnu.org; Mon, 01 Oct 2012 11:18:35 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:49112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TIhl3-0005m8-Bs for emacs-devel@gnu.org; Mon, 01 Oct 2012 11:18:09 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q91FI4Yk024539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Oct 2012 15:18:05 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q91FI4WV027575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 15:18:04 GMT Original-Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q91FI3dV003057; Mon, 1 Oct 2012 10:18:03 -0500 Original-Received: from dradamslap1 (/10.159.219.190) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Oct 2012 08:18:03 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac2fn8LGBo3sEByrSaa1JsEiAFwcrwAQRMOA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153839 Archived-At: > > I guess for a long time I've sub-thought, without > > considering it consciously, that it might be good to get > > back that last successful search string -- the one > > I was searching with when I hit `C-g' to quit searching -- > > for reuse later. But it's not saved on the search rings > > (which makes sense), so it is not available. > > `C-g' means bye-bye. > > As you say, someone might want that last successful search string to > be stored in the search ring (I've sometimes expected it). No, I did not say that. In fact, I said that it makes sense that it NOT be added to the search rings. I said that it would sometimes be useful to retrieve that string for a later search. That's not the same thing as treating it the same as the strings on the rings. > So I think that the proper solution would be to let the user decide > whether C-g from a I-search session saves the current search string in > the search ring. 1. If you mean systematically, e.g. via a user option, then that is a bad idea, IMO. I, for one, do not want abandoned searches polluting my search rings. But I do want to be able to get back the _last_ abandoned search string on demand, for reuse. What Isearch+ does is save only the last abandoned search strings (separately for simple search and regexp search). It specifically does not add those to the search rings. 2. If you instead meant that a user would signal this intention when hitting C-g (prefix arg or some such), then that would be pretty useless, IMHO. At the time you hit C-g you typically do not know whether you might later want to reuse that search string. And again, it should not be saved to the search rings. > That, IMO, would be a better (more intuitive/consistent) solution that > taking another key for retrieving the last successful search string > (which is already doable with "C-s C-s" or "C-s M-p"). This is not about the last search where you moved to a search hit and stayed there. That is what is recorded in the search rings and so is available via C-s C-s. Those are not only successful searches in terms of finding hits; they are also searches that you have accepted, i.e., used to move to a hit and stay there. That meaning for the search rings should be kept, IMO. It is what you want 99% of the time. You do not want to wade through a myriad of successful but unused/unaccepted searches on the ring, to find and reuse a search that you actually followed. This is about retrieving the last successful search string where you canceled searching using C-g, and so did not stay at any of its hits. It's about letting you insert that string later, adding (appending) it to the current search string. It is very simple. Just hit `M-g' to yank the string into the current search. This is a one-off, occasional thing - nowhere near as frequent as reusing a search that you actually followed. Just imagine saving your search rings persistently (e.g. via savehist.el), to see the folly of saving each successful but abandoned search string.