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: case-insensitive if no insensitive dups? Date: Sun, 8 Jun 2008 16:49:39 -0700 Message-ID: <000c01c8c9c2$5131dd80$0200a8c0@us.oracle.com> References: <002201c8c986$68802b90$0200a8c0@us.oracle.com><002501c8c98f$d66552d0$0200a8c0@us.oracle.com><85lk1f94vr.fsf@lola.goethe.zz><85hcc39455.fsf@lola.goethe.zz><000101c8c99c$db56a930$0200a8c0@us.oracle.com> <000301c8c9a1$486e87a0$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1212969006 25367 80.91.229.12 (8 Jun 2008 23:50:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Jun 2008 23:50:06 +0000 (UTC) To: "'Emacs-Devel'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 09 01:50:49 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K5Uet-0003zk-Ft for ged-emacs-devel@m.gmane.org; Mon, 09 Jun 2008 01:50:47 +0200 Original-Received: from localhost ([127.0.0.1]:35583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5Ue6-0001Ca-D4 for ged-emacs-devel@m.gmane.org; Sun, 08 Jun 2008 19:49:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K5Ue1-0001BD-8H for emacs-devel@gnu.org; Sun, 08 Jun 2008 19:49:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K5Ue0-0001Ax-IR for emacs-devel@gnu.org; Sun, 08 Jun 2008 19:49:52 -0400 Original-Received: from [199.232.76.173] (port=44902 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5Ue0-0001As-Bc for emacs-devel@gnu.org; Sun, 08 Jun 2008 19:49:52 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:12562) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K5Ue0-0005gQ-M5 for emacs-devel@gnu.org; Sun, 08 Jun 2008 19:49:52 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m58Nnk7r018164 for ; Sun, 8 Jun 2008 17:49:47 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m58Knscg023297 for ; Sun, 8 Jun 2008 17:49:46 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3688202331212968973; Sun, 08 Jun 2008 16:49:33 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Jun 2008 16:49:33 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <000301c8c9a1$486e87a0$0200a8c0@us.oracle.com> Thread-Index: AcjJlQt7PhYtq56QQMqC6I4jbciAHQABa7aAAAEyBwAAA0024A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:98739 Archived-At: Here's a crazy idea. Whenever there are no completion candidates that differ only by case, treat completion as case-insensitive. Even when the governing variables (e.g. `case-fold-search', `completion-ignores-case') say it needs to be case-sensitive. IOW, treat the variables as only a worst-case guideline. Dunno how performant this would be in some cases, or even how feasible it would be in some cases. But where possible and performant, it could be handy. In cases where case couldn't possibly make any difference, users would be able to complete without bothering with the Shift key. Users could configure the variables, in effect, to have case sensitivity turn on (only) whenever it makes sense. On the other hand, a user might sometimes want to be able to test whether particular case-sensitive candidates are available - s?he might then want to use case-sensitive matching even when there weren't any alternative candidates with the same spelling, modulo case. Perhaps another user option? `completion-ignore-case-unless-dups-flag' or whatever. This idea could even be used beyond completion: `case-fold-generously' or whatever. That is, let matching try to find a case-insensitive match, unless that leads to some matches that differ only by case. On the down side, such an approach might sometimes be confusing. Suppose the first thing you type is `ab', and there are candidates `abcd' and `abcD'. Assuming case sensitivity is required by the governing variables, it would be imposed in this case, because of the insensitivity duplicates. If you then hit `e', however, and there are only the matches `abexyz' and `abeLincoln', then completion would automatically switch to being case-insensitive. We could of course choose to never let your input affect things. That is, just decide once and for all, based on the current domain of candidates, whether it allows for case-insensitivity. In this case, the fact that your input is `abe' (or anything else) would have no effect: completion would remain case-sensitive because of the insensitivity duplicates `abcd' and `abcD'. That would be quite conservative and much less handy, however. Personally, I'd opt for allowing the potential confusion of an automatic switch from sensitive to insensitive, because it would let me complete `*m' to `*Messages*' even if there were also two buffers `foo' and `FoO'. (There could of course never be a switch from insensitive to sensitive.) The performance in the conservative case would be better, because the test would only be made once (using all domain candidates); it wouldn't be updated for each character you type (or when you hit `TAB', if there is no incremental completion). On the other hand, if the first few characters were allowed to be typed before making any test, and if your input were used in the test, then performance would be improved, due to the smaller search space. To me, that would probably be the way to go: have either a minimum number of chars (e.g. 1) or a tiny delay, after which your input would be matched against the candidates to see whether or not matching could be insensitive. If the minimum were 1 char, then typing `*' would limit the set of buffers to check for duplicates to just a few. If a delay were used instead, then you might need to type `*m' a little slowly, to automatically switch to case-insensitive matching against `*Messages*'. Just some food for thought.