From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Mon, 30 Dec 2013 15:35:07 -0500 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0117729d2afa6104eec6616f X-Trace: ger.gmane.org 1388435707 15683 80.91.229.3 (30 Dec 2013 20:35:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Dec 2013 20:35:07 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 30 21:35:14 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VxjYP-0000iq-Cm for ged-emacs-devel@m.gmane.org; Mon, 30 Dec 2013 21:35:13 +0100 Original-Received: from localhost ([::1]:59723 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VxjYO-0005Ld-TZ for ged-emacs-devel@m.gmane.org; Mon, 30 Dec 2013 15:35:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VxjYM-0005LV-3J for emacs-devel@gnu.org; Mon, 30 Dec 2013 15:35:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VxjYL-0005Q7-5S for emacs-devel@gnu.org; Mon, 30 Dec 2013 15:35:10 -0500 Original-Received: from mail-oa0-x235.google.com ([2607:f8b0:4003:c02::235]:56770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VxjYK-0005Oy-W7 for emacs-devel@gnu.org; Mon, 30 Dec 2013 15:35:09 -0500 Original-Received: by mail-oa0-f53.google.com with SMTP id m1so12413479oag.40 for ; Mon, 30 Dec 2013 12:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BNGpgDa8n3jsvPJpzzVVS5xU0DcHwcYs5tVOJumI31c=; b=b/nrPWXQiz3bEfWWOCpDVe4cIakv8oEuQ2vWV6+F+wm2ZQcGP8YK8TbbaUEtywjTip Y7SJFDCAvVQfg+AbIo27eDw91v2aj19p0iRSh65wKGsDStnnoA2uNvF7USAwQvzWiGSf bm1/0ZPJaBWCL60BUgIDIwSWlWrNv5MVgTICDOCQprkm15dSRNCF17p2HlYEdu8FMoZe gcKzR5pGL3GXWnjQDCkBIAxde3JMB5kD6PcRT93T3/ZTPh+Iq/tzDKjcLkrcegIVuoio EekftOiQl3kA5H/f1UuXccwhhAPqLjOX9qy+fq0EvgcqjobLDFpbjdjvPFxur6vm6GoZ 4AyA== X-Received: by 10.60.38.35 with SMTP id d3mr45747349oek.37.1388435707982; Mon, 30 Dec 2013 12:35:07 -0800 (PST) Original-Received: by 10.76.156.103 with HTTP; Mon, 30 Dec 2013 12:35:07 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:166999 Archived-At: --089e0117729d2afa6104eec6616f Content-Type: text/plain; charset=ISO-8859-1 Stefan: > Ah, right, the conflict is in the meaning of the TAB key. > There are two issues there: > 1- the fact that there's no standard way to *extend* the meaning of > TAB, so autocomplete and yasnippet may both *redefine* the key instead. > 2- even if the two manage to redefine TAB "at the same time", the > resulting behavior may prove too DWIMish. Stefan: > Yes. We should make it easier to extend indent-for-tab-command. It would be good to clarify whether the fallback mechanism should be for the key sequence or the command. That is: should calling the command via M-x cause the fallback behavior? I suspect what these commands want is to indicate that the search in active keymaps should continue. The problem with using the command's return is that determining whether to fall back risks side effects. key-binding and other functions might require no side effects. A possible idea is to allow the interactive spec to specify Lisp code that evaluates to whether to fall back or not. It would probably make sense to pass that non nil result to the command as an argument if it is called. If nil, then the search through active keymaps would continue. --089e0117729d2afa6104eec6616f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Stefan:
> Ah, right, the conflict is in the meaning = of the TAB key.
> There are two issues there:
> 1- the fact tha= t there's no standard way to *extend* the meaning of
>=A0=A0=A0 T= AB, so autocomplete and yasnippet may both *redefine* the key instead.
> 2- even if the two manage to redefine TAB "at the same time"= , the
>=A0=A0=A0 resulting behavior may prove too DWIMish.

Ste= fan:
> Yes.=A0 We should make it easier to extend indent-for-tab-comm= and.

It would be good to clarify whether the fallback mechanism should befor the key sequence or the command. That is: should calling the
comman= d via M-x cause the fallback behavior?

I suspect what these commands= want is to indicate that the search in
active keymaps should continue. The problem with using the command'sreturn is that determining whether to fall back risks side effects.
key= -binding and other functions might require no side effects. A
possible i= dea is to allow the interactive spec to specify Lisp code
that evaluates to whether to fall back or not. It would probably make
se= nse to pass that non nil result to the command as an argument if it
is c= alled. If nil, then the search through active keymaps would
continue.

--089e0117729d2afa6104eec6616f--