From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: CVS directories in completion-ignored-extensions Date: 05 Jan 2004 08:59:58 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87u13bjmdd.fsf@tc-1-100.kawasaki.gol.ne.jp> References: <1892-Tue30Dec2003100155+0200-eliz@elta.co.il> <87n099j2fb.fsf@offby1.atm01.sea.blarg.net> <200312310108.hBV18Xj28227@raven.dms.auburn.edu> <20031231013407.GC19084@fencepost> <7137-Sat03Jan2004135259+0200-eliz@elta.co.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073262314 16362 80.91.224.253 (5 Jan 2004 00:25:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2004 00:25:14 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jan 05 01:25:11 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AdIYR-0000YX-00 for ; Mon, 05 Jan 2004 01:25:11 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AdIYR-0007Xk-00 for ; Mon, 05 Jan 2004 01:25:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AdJV6-0002kv-Kk for emacs-devel@quimby.gnus.org; Sun, 04 Jan 2004 20:25:48 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AdJTw-0001he-8Q for emacs-devel@gnu.org; Sun, 04 Jan 2004 20:24:36 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AdJTp-0001d1-Fg for emacs-devel@gnu.org; Sun, 04 Jan 2004 20:24:34 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AdJTp-0001cp-2E for emacs-devel@gnu.org; Sun, 04 Jan 2004 20:24:29 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AdIA7-0001L2-00 for ; Mon, 05 Jan 2004 01:00:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AdIA5-0001Ka-00 for ; Mon, 05 Jan 2004 01:00:01 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AdIA5-0003gF-00 for ; Mon, 05 Jan 2004 01:00:01 +0100 Original-Lines: 32 Original-X-Complaints-To: usenet@sea.gmane.org System-Type: i686-pc-linux-gnu X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19001 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19001 Stefan Monnier writes: > So instead of completion-ignored-names I'd suggest completion-ignored-regexp > (or completion-ignored-regexps if people feel like having a list of regexps > instead of a single one is worth the trouble). I've always thought it would be nice, instead of having multiple variables each of which contain a different types of entry, to have something like `completion-ignored-names', where each element could be either: a string (which is matched using just `equal'), or a list like (regexp REGEXP), which the matcher would treat accordingly. So for CVS, we'd just add "CVS/" to the list, but you could also add (regexp "#.*") to ignore backup files. This sort of situation happens often in emacs, so we've ended up with many sets of related variables, FOO-ignored-buffers, FOO-ignored-regexps, etc.). I think having separate variables which do almost the same thing is more confusing that having a single variable in which the elements of the list can have various meanings, as long as the notation used for indicating the meaning of each element is sufficiently clear -- and I think "STRING" => exact match, (regexp "REGEXP") => regexp match, etc., meets that criterion. The actual mechanics of the matching could probably be done by a single common function, so it need not be an implementation burden. [BTW, even in the case of a regexp-only variable, it's a lot nicer for the user to be able to add elements to a list than to add to a regexp...] -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia