From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: should search ring contain duplicates? Date: Mon, 15 May 2006 11:54:01 +0200 Message-ID: References: <200605030727.k437R2Wx009975@amrm2.ics.uci.edu> <87bqufwbls.fsf@jurta.org> <8764kezswj.fsf@jurta.org> <87ejz1mqvg.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 1147686968 10451 80.91.229.2 (15 May 2006 09:56:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 May 2006 09:56:08 +0000 (UTC) Cc: Juri Linkov , dann@ics.uci.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 15 11:56:05 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 1FfZnw-0003cr-PR for ged-emacs-devel@m.gmane.org; Mon, 15 May 2006 11:55:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FfZnw-0006WT-0Y for ged-emacs-devel@m.gmane.org; Mon, 15 May 2006 05:55:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FfZnj-0006Ua-Dp for emacs-devel@gnu.org; Mon, 15 May 2006 05:55:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FfZni-0006Su-79 for emacs-devel@gnu.org; Mon, 15 May 2006 05:55:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FfZni-0006Sn-3X for emacs-devel@gnu.org; Mon, 15 May 2006 05:55:42 -0400 Original-Received: from [195.41.46.235] (helo=pfepa.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FfZq3-0006rJ-Sp; Mon, 15 May 2006 05:58:08 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (unknown [80.165.4.124]) by pfepa.post.tele.dk (Postfix) with SMTP id 56B8EFAC059; Mon, 15 May 2006 11:55:37 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sun, 14 May 2006 19:29:59 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:54498 Archived-At: Richard Stallman writes: > > BTW, add-to-history should probably be fixed to _not_ add an element > > which is already at the head of the history. > > Then it becomes a complete duplicate of C code. Isn't then better > to call the Lisp function add-to-history from the C implementation of > read_minibuf? > > Looking at the code of add-to-history, it appears to me that it > already behaves as requested here. If the new element matches the > head of the history list, add-to-history does not add another copy. By default, it does, since history-delete-duplicates is nil. > > More precisely, it does not preserve the old head. > Instead it deletes that and then adds a new element. > But the result is, all the same, to have just one, not two. > This is all that matters, as far as I can see. It depends on the setting of history-delete-duplicates, whereas the code in read-from-minibuffer does not. > Is there a real issue here? Yes. I looked closer at the code in read_minibuf and add-to-history, and there are a couple of other inconsistencies, which should be fixed. The following version of add-to-history which obeys the same rules as read-from-minibuffer, including the keep-all arg. (defun add-to-history (history-var newelt &optional maxelt keep-all) "Add NEWELT to the history list stored in the variable HISTORY-VAR. Return the new history list. If MAXELT is non-nil, it specifies the maximum length of the history. Otherwise, the maximum history length is the value of the `history-length' property on symbol HISTORY-VAR, if set, or the value of the `history-length' variable. Remove duplicates of NEWELT unless `history-delete-duplicates' is nil. If optional fourth arg KEEP-ALL is non-nil, add NEWELT to history even if it is empty or a duplicate." (unless maxelt (setq maxelt (or (get history-var 'history-length) history-length))) (let ((history (symbol-value history-var)) tail) (when (and (listp history) (or keep-all (not (stringp newelt)) (> (length newelt) 0)) (or keep-all (not (equal (car history) newelt)))) (if history-delete-duplicates (delete newelt history)) (setq history (cons newelt history)) (when (integerp maxelt) (if (= 0 maxelt) (setq history nil) (setq tail (nthcdr (1- maxelt) history)) (when (consp tail) (setcdr tail nil))))) (set history-var history))) [It accepts a non-string element, so it can be used in more cases which are not directly related to a minibuffer history variable, such as the kmacro-kill-ring, which already uses it]. Can I install this, so we can get on with the release :-) -- Kim F. Storm http://www.cua.dk