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: inputting characters by hexadigit Date: Thu, 24 Jul 2008 10:00:15 -0700 Message-ID: <005a01c8edae$beff6480$0ab32382@us.oracle.com> References: <868ww3vydn.fsf@lifelogs.com> <87myki6fqp.fsf@jurta.org> <87mykhz6tf.fsf@jurta.org> <87tzeokrku.fsf@jurta.org> <87od4wgg8p.fsf@catnip.gol.com><86od4vmi5i.fsf@lifelogs.com> <873am6n21q.fsf@jurta.org> <87sku5if8t.fsf_-_@jurta.org> <87od4sti4g.fsf@jurta.org><867ibcekf3.fsf@lifelogs.com> <86tzegcq15.fsf@lifelogs.com> <86bq0nctbv.fsf@lifelogs.com> <86r69jb8z2.fsf@lifelogs.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 1216918974 28602 80.91.229.12 (24 Jul 2008 17:02:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Jul 2008 17:02:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Stefan Monnier'" , "'Ted Zlatanov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 24 19:03:43 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 1KM4DY-0001Zc-Mg for ged-emacs-devel@m.gmane.org; Thu, 24 Jul 2008 19:03:04 +0200 Original-Received: from localhost ([127.0.0.1]:60466 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KM4Ce-0006PR-N6 for ged-emacs-devel@m.gmane.org; Thu, 24 Jul 2008 13:02:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KM4CK-00066f-HZ for emacs-devel@gnu.org; Thu, 24 Jul 2008 13:01:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KM4CI-00064q-Ju for emacs-devel@gnu.org; Thu, 24 Jul 2008 13:01:48 -0400 Original-Received: from [199.232.76.173] (port=36938 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KM4CI-00064g-FQ for emacs-devel@gnu.org; Thu, 24 Jul 2008 13:01:46 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:43754) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KM4CH-0000FE-UL for emacs-devel@gnu.org; Thu, 24 Jul 2008 13:01:46 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m6OH1eMc031844; Thu, 24 Jul 2008 12:01:40 -0500 Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m6OGNTCI031086; Thu, 24 Jul 2008 11:01:39 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt354.oracle.com with ESMTP id 11024368121216918814; Thu, 24 Jul 2008 10:00:14 -0700 Original-Received: from dradamslap1 (/130.35.179.10) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Jul 2008 10:00:13 -0700 X-Mailer: Microsoft Office Outlook 11 thread-index: AcjtqJdgNMX5YLckQ/mk4VXvn86d4QAAEQuQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: 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:101407 Archived-At: > So, it's like a substring search (like what you get with * A P L TAB), > except that the substring is anchored at the beginning of words, and > that *Completions* only lists the words rather than actual completion > candidates (on the assumption that there is a fair bit of > redundancy in the list of words). It sounds interesting. > > The "anchored substring search" should be fairly easy to implement as > a new completion-style. The *Completions* change would require less > "modular/configurable" changes, I suspect, but it's worth trying it out. I can't believe this. So now we're going to muck with existing completion mechanisms even more, trying out new features, just for this Unicode character input thing? How about finishing what you were doing to move the completion code to Lisp, and adding the `completing-read-function' variable we've been waiting for? Pings about this get no reply, but you are apparently considering trying out new completion features. The so-called translation to Lisp has already resulted in adding new "features" with no discussion here. The addition of `completing-read-function', unlike those changes, will not require users to change their code in any way. How about it? Can you please bring `completing-read' into line with `read-file-name' by giving it a `completing-read-function' variable? Thanks. ------- > > >> > >> How about having `completing-read' just call a > > >> > >> `completing-read-function' variable if non-nil? > > >> > >> This is the same thing that `read-file-name' does, with > > >> > >> `read-file-name-function'. > > >> > > > > >> > > It sounds useful to authors of Emacs extensions and > > >> > > might even be useful directly for end users, letting > > >> > > them decide what completing-read function they feel > > >> > > like using on any particular day. > > >> > > > >> > I agree. Is there any reason not to add > > >> > completing-read-function? > > >> > > >> No one has objected to the idea. > > >> Could someone please implement this? > > > > > > Any news on this? > > > > Let's wait when Stefan moves completing-read to > > minibuffer.el and then just add > > (if completing-read-function > > (funcall completing-read-function ;-) > > Any news?