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: read-face-name PROMPT arg should be self-contained, including ": " Date: Mon, 19 Mar 2007 07:29:06 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1174314674 16420 80.91.229.12 (19 Mar 2007 14:31:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 19 Mar 2007 14:31:14 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 19 15:31:09 2007 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 1HTIt5-0002nq-Dz for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2007 15:31:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HTIuZ-0000mQ-Ew for ged-emacs-devel@m.gmane.org; Mon, 19 Mar 2007 09:32:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HTIuW-0000lu-7A for emacs-devel@gnu.org; Mon, 19 Mar 2007 10:32:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HTIuT-0000lV-VD for emacs-devel@gnu.org; Mon, 19 Mar 2007 10:32:31 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HTIuT-0000lS-Sw for emacs-devel@gnu.org; Mon, 19 Mar 2007 09:32:29 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HTIt0-0005Yy-TM for emacs-devel@gnu.org; Mon, 19 Mar 2007 10:30:59 -0400 Original-Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l2JEUuYC018627 for ; Mon, 19 Mar 2007 08:30:56 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2JEQmAb020301 for ; Mon, 19 Mar 2007 08:30:55 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-73-182.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2542545521174314550; Mon, 19 Mar 2007 07:29:10 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: 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:68100 Archived-At: > >> `read-face-name' still blindly appends ": " to the prompt it > >> is supplied. > >> > >> I thought of `read-face-name' as an internal function, not for > >> users to use. > >> But I agree that it could be useful for user code to call. > >> So I'm not against making this change. I see that all the callers > >> within Emacs are easy to change. > >> > >> If someone wants to do it, please do it. > > > Thanks, I hope someone does. > > > BTW, for sometime after the release, we might consider adding > > an optional history-list arg to `read-face-name', so accessing > > history entries doesn't include non-face stuff. > > I was recently thinking that rather than adding new history vars > everywhere > all the time, we could change the history navigation to automatically skip > entries which are not completion candidates (at least for those cases that > are `must-match'). Hmm, maybe. It's worth thinking about, anyway. Considerations: . That would tie history cycling to the current typed input, rather than letting you access any history entry. That is, history cycling would be among matches only. Would that be good or bad? For non-`must-match', at least, that might be a nuisance, requiring you to first clear the minibuffer. . We already have one way to match against the history, though it is limited, giving you only the first match. . It would not really be "rather than", because a history var, if available, is more efficient. IOW, it would be good, in any case, to _allow_ use of a history var.