|
From: | Felipe Ochoa |
Subject: | Re: Disabling imenu default of thing-at-point |
Date: | Thu, 3 Aug 2017 10:35:20 +0200 |
> One thing that cannot be fixed within ido (or completing-read)> > Sounds like Ido (or Ido Ubiquitous) needs to be fixed. There
---------- Forwarded message ----------
From: Drew Adams <address@hidden>
Date: 24 July 2017 at 20:24
Subject: RE: Disabling imenu default of thing-at-point
To: Felipe Ochoa <address@hidden>
> > 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.
> 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 theWhy 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'.
> > > 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 <address@hidden> 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 followscompleting-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 approach3. If so, offer it as a default. Otherwise, ignore it.
would mean in words:
1. Grab the symbol at point.
2. Check if it matches one of the items in the index.
[Prev in Thread] | Current Thread | [Next in Thread] |