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:13:17 +0200 Message-ID: References: <87vamhg3r2.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113ed596efb51e055520bd8a" X-Trace: blaine.gmane.org 1500989458 6007 195.159.176.226 (25 Jul 2017 13:30:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Jul 2017 13:30:58 +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:30:51 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 1dZzvF-00014V-8G for ged-emacs-devel@m.gmane.org; Tue, 25 Jul 2017 15:30:49 +0200 Original-Received: from localhost ([::1]:60777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZzvK-0000Bk-F1 for ged-emacs-devel@m.gmane.org; Tue, 25 Jul 2017 09:30:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZvu4-0001DU-A7 for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:13:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dZvu2-0005Sk-GF for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:13:20 -0400 Original-Received: from mail-ua0-x230.google.com ([2607:f8b0:400c:c08::230]:36536) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dZvu2-0005Sd-A2 for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:13:18 -0400 Original-Received: by mail-ua0-x230.google.com with SMTP id k43so61535277uaf.3 for ; Tue, 25 Jul 2017 02:13:18 -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=ftPovI2S79wFq9VhwDNHbRLnXPxaQhWvkQiCs6+z5fo=; b=fqfrmu2EfEyidMycacemyCwM009IddAselOBGheJ3jaVGCXtLMmP1CfNj66UCQ2mWx Ja67PyMaLtQTFFEY69/HbLWPinktG2t1aZC2Tr5bPboOJwv1CW5/r+PyywXPM0GTapn8 fsjJrPVGoF9Nk5kbMFJgqCme+dt3usj1EQnAuaGORbH0XHV+13q44rC8vUOqHqn8Gv7v ETS52ljXs7mSuF1BM/Hmi9R8JD1uVfG4Wrj2mtacYoqo1M+G/3cmtjsjAHlLu23RiojN wfUXPZ6a0yKbhCYiku9yUa6jGmH3G1Vr42rOA48Rxr4+eP7pEmxs9qQnhOZa/TyRnC+T 701Q== 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=ftPovI2S79wFq9VhwDNHbRLnXPxaQhWvkQiCs6+z5fo=; b=WmKxNDh0aEii+nEMPqFxkV/9G3Dh1hWcL6ZVfBt68mfNmQNwBgaOQU/7+jVv2hjmYV DLBztpTxWvOXxozSpfgO7FpNp2kIFbmuenXCjph/PWTaAyUjpRzkXuaUCRkiUN0FqiM0 qbor7lAkvszXSTvdFQLtKMiDQicDP+C7zD2pY67SEK6Qmk+10d8PVuZtFyxa6yBcWSO+ tTyN8ZjmtYJHSZ992G5V8IkGSe2cFQHD8z0h4WAplv/NjbHOeuVLXoY6jWs/gQl50Qnd mjOiDuvs/8IMCZFeAerzmlBGd/F58W5XVpgBukCGAJedc1JTX2K6cUuZlgiafcpMGtei BKSA== X-Gm-Message-State: AIVw113o048tVrirCWb5g5MUbWCXwItx384v4sjQEherhjoAWuFb3duD CEQrLVEXoMYNnH2TgSET684EAzXJI7ZPOHE= X-Received: by 10.31.41.204 with SMTP id p195mr5553740vkp.80.1500973997469; Tue, 25 Jul 2017 02:13:17 -0700 (PDT) Original-Received: by 10.176.71.148 with HTTP; Tue, 25 Jul 2017 02:13:17 -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::230 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:217018 Archived-At: --001a113ed596efb51e055520bd8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: Drew Adams Date: 25 July 2017 at 00:57 Subject: RE: Disabling imenu default of thing-at-point To: Felipe Ochoa > > `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. > The documentation doesn't say this, but since it has worked this way for 15+ years, I believe you :-) The doc (`C-h f') says: REQUIRE-MATCH can take the following values: - t means that the user is not allowed to exit unless the input is (or completes to) an element of COLLECTION or is null. If the input is null, =E2=80=98completing-read=E2=80=99 returns DEF, or the= first element of the list of default values, or an empty string if DEF is nil, regardless of the value of REQUIRE-MATCH. > > 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. > I think this is exactly what I'm suggesting (That we use a different `completing-read' call). > I think this type of default is bogus, because of what imenu is supposed to do. From *info*: "The Imenu facility offers a way to find the major definitions in a file by name... If you type =E2=80=98M-x imenu=E2=80=99, i= t reads the name of a definition using the minibuffer, then moves point to that definition." Offering as default a non-existent definition is bogus in my mind, since where should point move to in that case? OK, that makes sense. You can do that easier, with clearer code - just test whether the default returned by thing-at-point is one of the completion candidates. > > 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'. > To the contrary, ido works just like `completing-read'. I can see how it might be useful in general for completing-read, but I just don't think it's useful for its use imenu. (And hence why I think imenu should be fixed) I'm OK with that. I think that a previous thread with the Ido Ubiquitous developer expressed the desire to remove that use case from `completing-read' because I.U. does *not* support it (jumps through some hoops to work around it). But perhaps I misunderstood. > > 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? > Stefan would have to comment on the code's intent (from 2001). As mentioned above, I don't think this makes sense. But others may have uses for imenu that I don't know of where this behavior is useful. I guess that's the question: is there any use here for a value that is not one of the completion candidates. If not, what you suggest sounds good. - Drew 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. > > > --001a113ed596efb51e055520bd8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
From: Drew Adams <drew.adams@oracle.com>
Date: 25 July 2017 at 00:57
Subject: RE: Disabling imenu default= of thing-at-point
To: Felipe Ochoa <felipe.nospam.ochoa@gmail.com&g= t;

=C2=A0

> = > `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 ar= g it means that either (a) one of those candidates must be picked or (2)=20 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.

> The documentation doesn't say this, but since it has worked t= his way for 15+ years, I believe you :-)

=C2=A0

= The doc (`C-h f') says:

<= p class=3D"MsoNormal">=C2=A0

=

REQUIRE-MATCH can take the following values:

=C2=A0=

- t means that the user is not allowed to exit unless th= e input is (or completes to) an element of COLLECTION or is null.

=C2=A0

If the input is null, =E2=80=98completing-re= ad=E2=80=99 returns DEF, or the first element of the list of default values= , or an empty string if DEF is nil, r= egardless of the value of REQUIRE-MATCH.


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

> I think thi= s is exactly what I'm suggesting (That we use a different `completing-r= ead' call).

> I think this type of default is bogus, because of what imenu is supposed=20 to do. From *info*: "The Imenu facility offers a way to find the major= =20 definitions in a file by name... If you type =E2=80=98M-x imenu=E2=80=99, i= t reads the=20 name of a definition using the minibuffer, then moves point to that=20 definition." Offering as default a non-existent definition is bogus in= =20 my mind, since where should point move to in that case?

OK, that makes sense.=C2=A0 You can do that easier, with clearer code - just= =20 test whether the default returned by thing-at-point is one of the=20 completion candidates.

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

> To the contrary, ido works just like `completing-read'. I can see how it= =20 might be useful in general for completing-read, but I just don't think= =20 it's useful for its use imenu. (And hence why I think imenu should be= =20 fixed)

=C2=A0=


> = > 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?

> Stefan would have to comment on the code's intent (from 2001). As mentioned= =20 above, I don't think this makes sense. But others may have uses for=20 imenu that I don't know of where this behavior is useful.

I guess that's the question: is there any use here for a value that is= =20 not one of the completion candidates. If not, what you suggest sounds=20 good.

<= /div>

- Drew=


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


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

I think this could also be an option, but note that ido fol= lows
completing-read-default in its handling of invalid defau= lts. E.g.,
evaluate the following and hit RET without selecti= ng anything:

(completing-read-default
=C2=A0"Complete: "= ; '("abc" "def" "ghi")
=C2=A0nil 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 ite= m (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.>
> > - =C2=A0 =C2=A0 =C2=A0(setq name (or (imenu-find-defaul= t name prepared-index-alist) name)))
> > + =C2=A0 =C2=A0 =C2=A0(se= tq 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(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?=C2=A0 It's only purpose
> could then be to re= turn a string so that `imenu-find-default' 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 approach
would mean in words:
<= br>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.



--001a113ed596efb51e055520bd8a--