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:05:24 +0200 Message-ID: References: <87vamhg3r2.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403043ec134bfe99e055520a110" X-Trace: blaine.gmane.org 1500989387 25600 195.159.176.226 (25 Jul 2017 13:29:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Jul 2017 13:29:47 +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:42 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 1dZzu9-0006JS-CT for ged-emacs-devel@m.gmane.org; Tue, 25 Jul 2017 15:29:41 +0200 Original-Received: from localhost ([::1]:60776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZzuE-0000Bb-Gz for ged-emacs-devel@m.gmane.org; Tue, 25 Jul 2017 09:29:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dZvmQ-0006zP-Gb for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:05:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dZvmP-0001Vy-F3 for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:05:26 -0400 Original-Received: from mail-ua0-x230.google.com ([2607:f8b0:400c:c08::230]:38677) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dZvmP-0001Vs-A8 for emacs-devel@gnu.org; Tue, 25 Jul 2017 05:05:25 -0400 Original-Received: by mail-ua0-x230.google.com with SMTP id w45so98026376uac.5 for ; Tue, 25 Jul 2017 02:05:25 -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=XtcceVuDjB3wRF6ykOnnO6rZIZcG6M5AaGWrt6aqa6g=; b=GU48xQimUOahusPpKKl31HomvAg4lVx2KrCv4TG3NYKKMkdpR2Gsr3nuBRKf+yu5Ms QlOX8UIdqyNrzJkZdbPg/mC8nIcT982yHsL6j4v8Iix9hVi8mwL3jPzzBtuLSc35C4wf b0iNmf3icWFsErBfRRre8CHNgiuXY2DEkY2Z34G4EFCaBwbKAwxXbWdjNnSYsXayGi0i uWSrEajp7I7c3ZPyS4GIRzSkjS3CHBkacxf951PCGFjOruXbGyh7D56y+hSd5iX+E6qG 47Rw/xv/VYe0xB3aZKjooxX8Z8eJI3qPdeqmaXFS5E8HKY162gG2pSeKpO/G4oGpvrAG inww== 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=XtcceVuDjB3wRF6ykOnnO6rZIZcG6M5AaGWrt6aqa6g=; b=PY4mUkWQcnEQgdGDkPn5zPmDeIzYWXkDmK26JRjJ56n5MKWUt0EDiqTJE9uYHoxTYa YGWB/nCW/G1eZ3EdsNzu0lcpkecqoUbaHAgzWmnIc29IJzhAQby3TL5P9wktKXJY6TOt IlrJCNvzTquwwpcGr+pjXLPg8ItZgTj1i0dCSVTOP31mqIyJGUixUTQoAmLOhrPgqKvT N462fiwtBavzOw8WTK4aG3slAxjnL4wZjk6Q0S9xwxZFKWkq552YR4Nj5MGZ0XVc2mTD VDd93vHMkCdrzuC7qUZWpU6SGBXsM8h21UGGBfQIApOzYDUbH1bmzeAWqG595rCxwuZU kT2Q== X-Gm-Message-State: AIVw1118DqykaFq9jHcVhD2RxH7m+MkTERaD5doVRcJiy1oovLsQ/zDX a9Xrlx6rb9HVr71MmfWnlOWsGWyNEH+Dg3s= X-Received: by 10.176.9.75 with SMTP id c11mr12462068uah.145.1500973524575; Tue, 25 Jul 2017 02:05:24 -0700 (PDT) Original-Received: by 10.176.71.148 with HTTP; Tue, 25 Jul 2017 02:05:24 -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:217016 Archived-At: --f403043ec134bfe99e055520a110 Content-Type: text/plain; charset="UTF-8" (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. --f403043ec134bfe99e055520a110 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Apologies, forgot to CC the list)

> Sounds like Ido (or Ido Ubi= quitous) needs to be fixed.=C2=A0 There
> should not be a problem wit= h providing a default value, even
> when that default value might not= always be helpful.

I think this cou= ld also be an option, but note that ido follows
completing-re= ad-default in its handling of invalid defaults. E.g.,
evaluat= e the following and hit RET without selecting anything:

(completing-= read-default
=C2=A0"Complete: " '("abc" "de= f" "ghi")
=C2=A0nil t nil nil "jkl")

The result will be "jkl".

One thing tha= t cannot be fixed within ido (or completing-read)
is the prom= pt. 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<= br>> default value as a default value.
>
> > - =C2=A0 =C2= =A0 =C2=A0(setq name (or (imenu-find-default name prepared-index-alist) nam= e)))
> > + =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 pre= pared-index-alist))
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq pr= ompt (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 return a string so that `imenu-find-d= efault' 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:

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


--f403043ec134bfe99e055520a110--