From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Felipe Ochoa Newsgroups: gmane.emacs.devel Subject: Re: Disabling imenu default of thing-at-point Date: Tue, 25 Jul 2017 11:21:08 +0200 Message-ID: References: <87vamhg3r2.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403043ec134090c75055520da8f" X-Trace: blaine.gmane.org 1500989392 26461 195.159.176.226 (25 Jul 2017 13:29:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Jul 2017 13:29:52 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 25 15:29:47 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dZzuD-0006LC-5g for ged-emacs-devel@m.gmane.org; Tue, 25 Jul 2017 15:29:45 +0200 Original-Received: from localhost ([::1]:60778 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZzuF-0000Bs-Ki for ged-emacs-devel@m.gmane.org; Tue, 25 Jul 2017 09:29:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZw1f-0003tE-Qf for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:21:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dZw1d-0001TG-Vj for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:21:11 -0400 Original-Received: from mail-ua0-x229.google.com ([2607:f8b0:400c:c08::229]:37293) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dZw1d-0001T7-NV for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:21:09 -0400 Original-Received: by mail-ua0-x229.google.com with SMTP id f9so98515497uaf.4 for ; Tue, 25 Jul 2017 02:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FbFMAMfbt2JarSzWA26qvCGfu03JKkjfRjAz+FT0K70=; b=sU1K5c+mIDNoSA5+HdCz9QaDkMm99NqYZYwW5L5WPW092tD78uOoZJAZrzXPPmEqan ZkD2qrR+FUcKVOawCMNrBc8O3igxaQvphbhsNTP9SUp3b+tamuXno0B7N81TeeD9HBdu EJsTlQ2T9KYi6reuKWSoJ7I2eXn9TJxtmjApNBN8ETMdV6XY+VOS8U/K8pKqD+O99nMj rarWqdmkvsvdJCKYFthFIKLFUKH+QGfmSvMsj3DxmVKY+A6pclopSVmJ2NdbIJ/7DEAM Xt8+R+fKL3U4dE+Ss93XdN/ZohAdc1aw6H3hN08y6ViluECEazqRC48nUn5Nc2FnxmvP OcLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FbFMAMfbt2JarSzWA26qvCGfu03JKkjfRjAz+FT0K70=; b=kcZNg6VChm8+PpHWjMTfFB+6Azy+bWwfOYj33kVIia8pAEDQRtFUmDhd1C9MA7TXUY GaLZHDyUovlBGLdOzekODQtm2zX0TC/kfN81WnPBwtLiLGIngBGmPp6F9fnvxQz8/qBb vE2LHpIkCThdVlBRTapsvgiNn/qgAdfiT4ytqCqVCctQSeDYKsa1W2y/2MO1HtMTZuj8 sQl7kzDcJVdQWMUWcIELCQuagfIqRClOeTRhkVF1pngwLvCWbOpZE38WAoWLWjXhb2P5 ei2sRl3e9Lclo1iEuQAin3rnzv/d/DaHISEjdL0iddibZ3nZJBJHuuCdT14nsNo6JiW2 5pMA== X-Gm-Message-State: AIVw113WvJInf2mCZhjcLXWfV5i8XAiZIZI6xK+IjNB/VYqvdpWtHdyu vVd6IPSmer54vkGYY+fATJVdGO+ycElm X-Received: by 10.176.9.75 with SMTP id c11mr12486819uah.145.1500974468892; Tue, 25 Jul 2017 02:21:08 -0700 (PDT) Original-Received: by 10.176.71.148 with HTTP; Tue, 25 Jul 2017 02:21:08 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400c:c08::229 X-Mailman-Approved-At: Tue, 25 Jul 2017 09:29:34 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:217017 Archived-At: --f403043ec134090c75055520da8f Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message ---------- From: Drew Adams Date: 24 July 2017 at 20:24 Subject: RE: Disabling imenu default of thing-at-point To: Felipe Ochoa > > Sounds like Ido (or Ido Ubiquitous) needs to be fixed. There > > should not be a problem with providing a default value, even > > when that default value might not always be helpful. > I think this could also be an option, but note that ido follows > completing-read-default in its handling of invalid defaults. E.g., > evaluate the following and hit RET without selecting anything: > (completing-read-default "Complete: " '("abc" "def" "ghi") nil t nil nil "jkl") > The result will be "jkl". That's the case also for the Imenu code you cited, no? NAME is the default value to `completing-read', and you get it in that case by hitting RET with no input. And there is nothing "invalid" about the "jkl" value. `completing-read' has multiple uses. It is not just for picking one of a set of completion candidates. When `t' is specified as the REQUIRED arg it means that either (a) one of those candidates must be picked *or* (2) the default value can be picked. The list of candidates might be predefined, and the default value might be computed dynamically (e.g. thing at point), for example. > One thing that cannot be fixed within ido (or completing-read) > is the prompt. Currently all users see "Index item (default %s): ", > even when the default is bogus, instead of "Index item: ". Why is it bogus? If a different behavior were desired, where a user could not pick the default value but had to pick one of the completion candidates, then the `completing-read' call would be different. Perhaps Ido Ubiquitous does not provide for or handle such a use case (?). But it is a common and useful use case of `completing-read'. > > > It breaks everyone's ability to pick up what was previously the > > > default value as a default value. > > > > > > > - (setq name (or (imenu-find-default name prepared-index-alist) name))) > > > > + (setq name (imenu-find-default name prepared-index-alist))) > > > > (cond (prompt) > > > > ((and name (imenu--in-alist name prepared-index-alist)) > > > > (setq prompt (format "Index item (default %s): " name))) > > > > > > If you make that change then what is the sense of binding `name' to > > > `(thing-at-point 'symbol)' in the first place? It's only purpose > > > could then be to return a string so that `imenu-find-default' is > > > used at all. This doesn't make any sense (to me). > > The code does not do away with defaults. To me, the new approach > would mean in words: > > 1. Grab the symbol at point. > 2. Check if it matches one of the items in the index. > 3. If so, offer it as a default. Otherwise, ignore it. I understand that that's what you proposed. (There's a simpler way to code that, if that's what's desired.) But is that what was intended for the Imenu code? Does it make no sense (in this case) for a user to pick the default value if it is not one of the completion candidates? On 25 July 2017 at 11:05, Felipe Ochoa wrote: > (Apologies, forgot to CC the list) > > > > Sounds like Ido (or Ido Ubiquitous) needs to be fixed. There > > should not be a problem with providing a default value, even > > when that default value might not always be helpful. > > I think this could also be an option, but note that ido follows > completing-read-default in its handling of invalid defaults. E.g., > evaluate the following and hit RET without selecting anything: > > (completing-read-default > "Complete: " '("abc" "def" "ghi") > nil t nil nil "jkl") > > The result will be "jkl". > > One thing that cannot be fixed within ido (or completing-read) > is the prompt. Currently all users see "Index item (default %s): ", > even when the default is bogus, instead of "Index item: ". > > > It breaks everyone's ability to pick up what was previously the > > default value as a default value. > > > > > - (setq name (or (imenu-find-default name prepared-index-alist) > name))) > > > + (setq name (imenu-find-default name prepared-index-alist))) > > > (cond (prompt) > > > ((and name (imenu--in-alist name prepared-index-alist)) > > > (setq prompt (format "Index item (default %s): " name))) > > > > If you make that change then what is the sense of binding `name' to > > `(thing-at-point 'symbol)' in the first place? It's only purpose > > could then be to return a string so that `imenu-find-default' is > > used at all. This doesn't make any sense (to me). > > The code does not do away with defaults. To me, the new approach > would mean in words: > > 1. Grab the symbol at point. > 2. Check if it matches one of the items in the index. > 3. If so, offer it as a default. Otherwise, ignore it. > > > --f403043ec134090c75055520da8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div>


----------= Forwarded message ----------
From: Drew A= dams <drew.adams@oracle.com>
Date: 24 July 2017 a= t 20:24
Subject: RE: Disabling imenu default of thing-at-point
To: Fe= lipe Ochoa <felipe.nospam.ochoa@gmail.com>

> > Sounds like = Ido (or Ido Ubiquitous) needs to be fixed.=C2=A0 There
> > should = not be a problem with providing a default value, even
> > when tha= t default value might not always be helpful.

> I think this could= also be an option, but note that ido follows
> completing-read-defau= lt in its handling of invalid defaults. E.g.,
> evaluate the followin= g and hit RET without selecting anything:

> (completing-read-defa= ult "Complete: " '("abc" "def" "ghi&= quot;) nil t nil nil "jkl")

> The result will be "= jkl".

That's the case also for the Imenu code you cited, no? NAME is the default=20 value to `completing-read', and you get it in that case by hitting RET= =20 with no input.

And there is nothing "invalid&qu= ot; about the "jkl" value.

`completing-rea= d' has multiple uses. It is not just for picking one of a set of=20 completion candidates. When `t' is specified as the REQUIRED arg it=20 means that either (a) one of those candidates must be picked or=20 (2) the default value can be picked. The list of candidates might be=20 predefined, and the default value might be computed dynamically (e.g.=20 thing at point), for example.

> One t= hing that cannot be fixed within ido (or completing-read)
> is the pr= ompt. Currently all users see "Index item (default %s): ",
&g= t; even when the default is bogus, instead of "Index item: ".

Why is it bogus? If a different behavior were desired, where a user could=20 not pick the default value but had to pick one of the completion=20 candidates, then the `completing-read' call would be different.<= /p>

=C2=A0=

Perhaps Ido Ubiquitous does not provide for or handle such a use case (?). But=20 it is a common and useful use case of `completing-read'.


> > > It breaks everyone's ability to pick up what was previo= usly the
> > > default value as a default value.
> > &= gt;
> > > > - =C2=A0 =C2=A0 =C2=A0(setq name (or (imenu-find= -default name prepared-index-alist) name)))
> > > > + =C2=A0= =C2=A0 =C2=A0(setq name (imenu-find-default name prepared-index-alist)))> > > > =C2=A0 =C2=A0 =C2=A0(cond (prompt)
> > > = > =C2=A0 =C2=A0 =C2=A0 =C2=A0 ((and name (imenu--in-alist name prepared-= index-alist))
> > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(set= q prompt (format "Index item (default %s): " name)))
> >= >
> > > If you make that change then what is the sense of b= inding `name' to
> > > `(thing-at-point 'symbol)' i= n the first place?=C2=A0 It's only purpose
> > > could then= be to return a string so that `imenu-find-default' is
> > >= ; used at all.=C2=A0 This doesn't make any sense (to me).

=C2=A0=
>
> The code does not do away with defaults. To me, the new ap= proach
> would mean in words:
>
> 1. Grab the symbol at p= oint.
> 2. Check if it matches one of the items in the index.
>= 3. If so, offer it as a default. Otherwise, ignore it.

=C2=A0


On 25 July 2017 at 11= :05, Felipe Ochoa <felipe.nospam.ochoa@gmail.com> wrote:
(Apologies, for= got to CC the list)


> Sounds like Ido (or Ido Ubiquitous) = needs to be fixed.=C2=A0 There
> should not be a problem with providi= ng a default value, even
> when that default value might not always b= e helpful.

I think this could also b= e an option, but note that ido follows
completing-read-defaul= t in its handling of invalid defaults. E.g.,
evaluate the fol= lowing and hit RET without selecting anything:

(completing-read-defa= ult
=C2=A0"Complete: " '("abc" "def" &= quot;ghi")
=C2=A0nil t nil nil "jkl")

T= he result will be "jkl".

One thing that cannot = be fixed within ido (or completing-read)
is the prompt. Curre= ntly all users see "Index item (default %s): ",
even whe= n the default is bogus, instead of "Index item: ".

> It= breaks everyone's ability to pick up what was previously the
> d= efault value as a default value.
>
> > - =C2=A0 =C2=A0 =C2= =A0(setq name (or (imenu-find-default name prepared-index-alist) name)))> > + =C2=A0 =C2=A0 =C2=A0(setq name (imenu-find-default name prepar= ed-index-alist)))
> > =C2=A0 =C2=A0 =C2=A0(cond (prompt)
> &= gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 ((and name (imenu--in-alist name prepared-i= ndex-alist))
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq prompt (f= ormat "Index item (default %s): " name)))
>
> If you = make that change then what is the sense of binding `name' to
> `(= thing-at-point 'symbol)' in the first place?=C2=A0 It's only pu= rpose
> could then be to return a string so that `imenu-find-default&= #39; is
> used at all.=C2=A0 This doesn't make any sense (to me).=

The code does not do away with defaults. To me, the new approa= ch
would mean in words:

1. Grab the symbol at point.
2. Check = if it matches one of the items in the index.
3. If so, offer it a= s a default. Otherwise, ignore it.



--f403043ec134090c75055520da8f--