From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: query-replace in isearch (was Re: should search ring contain duplicates?) Date: Fri, 12 May 2006 00:52:38 +0300 Organization: JURTA Message-ID: <87slng8c5p.fsf@jurta.org> References: <200605030727.k437R2Wx009975@amrm2.ics.uci.edu> <87bqufwbls.fsf@jurta.org> <200605031504.k43F49hr001544@scanner2.ics.uci.edu> <87wtcslqoj.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1147384831 10122 80.91.229.2 (11 May 2006 22:00:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 11 May 2006 22:00:31 +0000 (UTC) Cc: dann@ics.uci.edu, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 12 00:00:30 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FeJCs-0002P4-E5 for ged-emacs-devel@m.gmane.org; Fri, 12 May 2006 00:00:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FeJCs-0001Eg-1f for ged-emacs-devel@m.gmane.org; Thu, 11 May 2006 18:00:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FeJC9-0000U2-B5 for emacs-devel@gnu.org; Thu, 11 May 2006 17:59:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FeJC7-0000Qy-CM for emacs-devel@gnu.org; Thu, 11 May 2006 17:59:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FeJC7-0000Qi-5E for emacs-devel@gnu.org; Thu, 11 May 2006 17:59:39 -0400 Original-Received: from [217.25.160.1] (helo=relay1.binet.com.ua) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FeJDh-0004Ku-4r; Thu, 11 May 2006 18:01:17 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by relay1.binet.com.ua (Postfix) with ESMTP id 00B3D77C88; Fri, 12 May 2006 00:59:36 +0300 (EEST) Original-Received: from mail.binet.com.ua (i19.dialup.binet.com.ua [217.25.161.83]) by relay1.binet.com.ua (Postfix) with ESMTP id 42E0077D3F; Fri, 12 May 2006 00:59:33 +0300 (EEST) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Thu, 11 May 2006 16:10:12 +0200") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: by ClamAv at binet.com.ua X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:54289 Archived-At: >> This requires adding a new >> argument KEEP-ALL to `add-to-history'. Its meaning is the same as the >> argument KEEP-ALL of `read-from-minibuffer'. > > That makes sense for the same reason as it makes sense > in read-from-minibuffer. > > But didn't you just argue that we could remove keep-all from that > function? `read-from-minibuffer' already has too many arguments, and I think adding a new very specific argument (used for a special history handling just in one specific place in Emacs) to this general function was not a good thing. I'm trying to find a better replacement for KEEP-ALL. There are currently two alternative variants of keeping empty and duplicate elements in the history: 1. Instead of using the KEEP-ALL argument bind `history-delete-duplicates' to a special value `keep-all' before calling `read-from-minibuffer'. 2. Tell `read-from-minibuffer' not to add a new element to the history list, and add it later by calling `add-to-history' with the KEEP-ALL argument. I like the latter. In my latest patch I preserve the original history list before calling `read-from-minibuffer', and overwrite the history list modified by `read-from-minibuffer' with the old original value. After that, `add-to-history' adds a new element to the original history list. However, I admit such preserving is not a good solution, because in the minibuffer the user can use own commands to modify the history list, and this modified history list gets overwritten with the old value. What about a special value of `history-length' (e.g. nil) to tell `read-from-minibuffer' not to add a new element to the history list (with the intention to add it later by `add-to-history')? -- Juri Linkov http://www.jurta.org/emacs/