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: Thu, 3 Aug 2017 10:35:20 +0200 Message-ID: References: <87vamhg3r2.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11439156d58e140555d542cd" X-Trace: blaine.gmane.org 1501749344 31269 195.159.176.226 (3 Aug 2017 08:35:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 3 Aug 2017 08:35:44 +0000 (UTC) To: emacs-devel@gnu.org, Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 03 10:35:38 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 1ddBbT-0007UI-JG for ged-emacs-devel@m.gmane.org; Thu, 03 Aug 2017 10:35:35 +0200 Original-Received: from localhost ([::1]:46386 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddBbW-0007ty-HC for ged-emacs-devel@m.gmane.org; Thu, 03 Aug 2017 04:35:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddBbJ-0007ra-Qu for emacs-devel@gnu.org; Thu, 03 Aug 2017 04:35:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ddBbH-0006H9-So for emacs-devel@gnu.org; Thu, 03 Aug 2017 04:35:25 -0400 Original-Received: from mail-vk0-x22e.google.com ([2607:f8b0:400c:c05::22e]:33110) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ddBbH-0006Fk-KB for emacs-devel@gnu.org; Thu, 03 Aug 2017 04:35:23 -0400 Original-Received: by mail-vk0-x22e.google.com with SMTP id x10so2618770vkd.0 for ; Thu, 03 Aug 2017 01:35:22 -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=R0nh97C5bMnR6SWUVxFhdO6aAxJ4hE49nAagl+oC/YM=; b=XS24aC9EKcLKVkqkPfu98A4SFQ8LnmT6w7Bgv+H9oxHT/lRDKmrHfjz4o29ikk8z/O DHWQpt7xmi3Be4/tV5Eg3Cpo3liqQRcBE7Ax9yNQD2bYbIxHNWJqlgmH0jqtVV/CgQrS M7I/wxG/3+ZXllVTBd8JvjVNC1w4fV4opjfRFogOSGBPXLK47aTD6GNCtiDk2vDzfAca iRFPCWMUDIP9WZBH7ZPdih5CSn7XRD1WkVDdStGSVxv0pZiur8NIicR579DsBuDdflMg rJi9mGn/Nv4SuSVrdxgkfy8N4Ykq6GFB+0je+0JI4FzZrr0b0tnoJCLkDT4k76jmX4Qv i9LQ== 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=R0nh97C5bMnR6SWUVxFhdO6aAxJ4hE49nAagl+oC/YM=; b=LR/QYZ+bscGH+vX07HwyFv0pL/Jo60gGO8YKlkg5fR7dzVBzPjPJYGNI02oVnmlJrM o+Ia3C6fa4H9UTAFp4i4+BvFV0VymqtI3tZRa3stOBbRD6vJ7bBd6IHxrEVLyGwkH0PD lij5NU/p7IoZFdI23/4huD4FqNZu0RSnsf2VIpaYjPeAscPCKvVJggfUl1HvNPeu7X8/ L7yg5IRvFLYFMZfWEkNMqSQIQ+AnRk88PN8z3n8fvD4zOMECrFdsp6ZGBdtfuNVCNwWA vBlEgiLkbaJwBFSdjwp2UiueGzAQTLXa+YOc0QL/03LPyWooBnv+goMt/f+rxBEaOF0Y aH5Q== X-Gm-Message-State: AIVw113z1UCneeImsp7b7EJHnY7oqjHCS3v6IJVTWskFYzZF/vFcoWAN 7uK6LMz89a09GWOJ4Vs/jKHGwLaMtPrWkmE= X-Received: by 10.31.171.129 with SMTP id u123mr511965vke.82.1501749321238; Thu, 03 Aug 2017 01:35:21 -0700 (PDT) Original-Received: by 10.176.91.155 with HTTP; Thu, 3 Aug 2017 01:35:20 -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:c05::22e 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:217255 Archived-At: --001a11439156d58e140555d542cd Content-Type: text/plain; charset="UTF-8" I realize this thread is probably hard to follow, so wanted to offer a brief recap (Drew, please correct me where necessary). Core issue: Felipe> imenu currently uses (thing-at-point 'symbol) to offer a default in completing read. It's very helpful when symbol at point is one of the options, but not really useful when not. It's particularly inconvenient when using ido for completing read Possible workaround: Noam suggested I use C-j to skip the default automagic in ido, but this does not work because of some imenu trickery (plus I think imenu is the place to fix this) Drew and I had a back-and-forth about whether the hypothetical fix belongs in ido/completing-read or imenu. The conclusion was it would belong in imenu, but he's still unclear whether a fix is necessary at all. Drew> 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:21, Felipe Ochoa wrote: > > ---------- 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. >> >> >> > --001a11439156d58e140555d542cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I realize this thread is probably hard= to follow, so wanted to offer a brief recap (Drew, please correct me where= necessary).

Core issue:
Felipe> imenu currently uses (= thing-at-point 'symbol) to offer a default in completing read. It's= very helpful when symbol at point is one of the options, but not really us= eful when not. It's particularly inconvenient when using ido for comple= ting read

Possible workaround:
Noam suggested I = use C-j to skip the default automagic in ido, but this does not work becaus= e of some imenu trickery (plus I think imenu is the place to fix this)
<= br>
Drew and I had a back-and-forth about whether the hypothetical fix= belongs in ido/completing-read or imenu. The conclusion was it would belon= g in imenu, but he's still unclear whether a fix is necessary at all.
Drew> 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?

<= /div>

On 25 July 2017 at 11:21, Felipe Ochoa = <feli= pe.nospam.ochoa@gmail.com> wrote:


---------- Forwarded message ----------=
From: Drew Adams &l= t;drew.adams@ora= cle.com>
Date: 24 July 2017 at 20:= 24
Subject: RE: Disabling imenu default of thing-at-point
To: Felipe = 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 that default value might not always be helpful.

>= I think this could also be an option, but note that ido follows
> co= mpleting-read-default in its handling of invalid defaults. E.g.,
> ev= aluate the following and hit RET without selecting anything:

> (c= ompleting-read-default "Complete: " '("abc" "d= ef" "ghi") nil t nil nil "jkl")

> The re= sult will be "jkl".

T= hat'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.

`complet= ing-read' 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)<= br>> 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=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 u= p what was previously the
> > > default value as a default valu= e.
> > >
> > > > - =C2=A0 =C2=A0 =C2=A0(setq nam= e (or (imenu-find-default name prepared-index-alist) name)))
> > &= gt; > + =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-ali= st name prepared-index-alist))
> > > > =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0(setq prompt (format "Index item (default %s): " nam= e)))
> > >
> > > If you make that change then what = is the sense of binding `name' to
> > > `(thing-at-point &#= 39;symbol)' in 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 m= e).

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

=C2=A0

I understand that that's what you proposed. (There's a simpler way t= o=20 code that, if that's what's desired.) But is that what was intended= for=20 the Imenu code? Does it make no sense (in this case) for a user to pick=20 the default value if it is not one of the completion candidates?
On 2= 5 July 2017 at 11:05, Felipe Ochoa <felipe.nospam.ochoa@gmail.= com> wrote:
(Apologies, forgot to CC the list)


> Sounds like Ido (or Ido Ubiquitous) n= eeds to be fixed.=C2=A0 There
> should not be a problem with providin= g 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 foll= owing and hit RET without selecting anything:

(completing-read-defau= lt
=C2=A0"Complete: " '("abc" "def" &q= uot;ghi")
=C2=A0nil t nil nil "jkl")

Th= e result will be "jkl".

One thing that cannot b= e fixed within ido (or completing-read)
is the prompt. Curren= tly 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
> de= fault value as a default value.
>
> > - =C2=A0 =C2=A0 =C2=A0= (setq name (or (imenu-find-default name prepared-index-alist) name)))
&g= t; > + =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-inde= x-alist))
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq prompt (form= at "Index item (default %s): " name)))
>
> If you mak= e that change then what is the sense of binding `name' to
> `(thi= ng-at-point 'symbol)' in the first place?=C2=A0 It's only purpo= se
> 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).
The code does not do away with defaults. To me, the new approach<= br>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.




--001a11439156d58e140555d542cd--