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: should search ring contain duplicates? Date: Wed, 3 May 2006 16:08:18 -0700 Message-ID: References: <87lktirgzy.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1146697721 23631 80.91.229.2 (3 May 2006 23:08:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 3 May 2006 23:08:41 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 04 01:08:38 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 1FbQST-0004nt-Gg for ged-emacs-devel@m.gmane.org; Thu, 04 May 2006 01:08:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FbQST-0000UU-3X for ged-emacs-devel@m.gmane.org; Wed, 03 May 2006 19:08:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FbQSG-0000Ti-JM for emacs-devel@gnu.org; Wed, 03 May 2006 19:08:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FbQSF-0000So-CD for emacs-devel@gnu.org; Wed, 03 May 2006 19:08:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FbQSF-0000Sl-66 for emacs-devel@gnu.org; Wed, 03 May 2006 19:08:23 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FbQSi-0006xL-Il for emacs-devel@gnu.org; Wed, 03 May 2006 19:08:52 -0400 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k43N8Lrh005122 for ; Wed, 3 May 2006 18:08:21 -0500 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k43N8JIW015433 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 3 May 2006 17:08:20 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87lktirgzy.fsf@jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:53877 Archived-At: > I think that for most uses of a history it makes no sense to keep > duplicates. I'd vote for making the default value be t and > letting those few > modes where duplicates might make sense (e.g. shell-mode?) > bind it to nil > unless the user has explicitly specified otherwise. > > IOW the option values could be: > > nil - means never remove duplicates > t (default) - means remove duplicates, but this can be > overridden by a mode (e.g. shell-mode) > non-nil, non-t - means always remove duplicates (never override) > > This would require code changes only for those few modes that want to > override the default (t). Plus a change to the defcustom. A related feature that specifies the maximum length of the history list uses the `history-length' _property_ of the history list _symbol_ to override the default value of the _variable_ `history-length' for a particular history list. Exactly the same thing could be implemented for `history-delete-duplicates', i.e. the property `history-delete-duplicates' would override its default value for a particular history list. Clever, but maybe too clever. Non-lisper end users should be able to easily change options, and they should be able to do so using Customize (and save such preferences). Making users use property lists to override default values is not a good way to go, IMO.