Re: Disabling imenu default of thing-at-point

[Felipe Ochoa <felipe.nospam.ochoa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

(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.

[-- Attachment #2: Type: text/html, Size: 2356 bytes --]