From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Exposing Isearch toggleable options Date: Thu, 29 Oct 2015 14:27:21 -0700 (PDT) Message-ID: <7e3720d6-cc00-4a74-9c3a-4193bb40b283@default> References: <87r3kdcws3.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1446154095 1276 80.91.229.3 (29 Oct 2015 21:28:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Oct 2015 21:28:15 +0000 (UTC) To: =?iso-8859-1?B?03NjYXIgRnVlbnRlcw==?= , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 29 22:28:00 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zrujg-0000KK-Jn for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 22:27:52 +0100 Original-Received: from localhost ([::1]:46895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zrujf-0000ZG-U2 for ged-emacs-devel@m.gmane.org; Thu, 29 Oct 2015 17:27:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrujM-0000Yl-5u for emacs-devel@gnu.org; Thu, 29 Oct 2015 17:27:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrujI-0005On-2j for emacs-devel@gnu.org; Thu, 29 Oct 2015 17:27:32 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:37298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrujH-0005Og-Sn for emacs-devel@gnu.org; Thu, 29 Oct 2015 17:27:28 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9TLRPoZ015594 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Oct 2015 21:27:25 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t9TLROqR013889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Oct 2015 21:27:24 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t9TLRNhk021095; Thu, 29 Oct 2015 21:27:24 GMT In-Reply-To: <87r3kdcws3.fsf@wanadoo.es> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:192929 Archived-At: > The discoverability issue is a very interesting one. Even more when > combined with ergonomics and convenience in general. Not too long ago I > was surprised to see how discoverability *and* convenience are benefited > from having a good completion mechanism on the M-x and set-variable > prompts. Ido+flx was a big enhancement for a tiny effort, IMO. I'm sure > that other packages can bring similar or superior benefits. >=20 > Ido+flx work on command/variable names. It would be better to have > conceptual relations among features, and exploit those relations > contextually. Some type of smart search engine for features, with the > right interfaces. FWIW: Icicles provides this for all minibuffer completion, not just for command and variable names. It also provides all of the keys available in the current dynamic context, including after you hit prefix keys. (And you can invoke the completed keys - any number of the key-completion candidates.) By default, it automatically provides short help in the mode line for the "current" completion candidate (you can cycle candidates or otherwise choose any as the "current" one). And you can hit a key to get the complete help for the current candidate, in *Help*. For example, for `M-x', the candidates are command names. Cycling among those that match your current minibuffer input, as each is cycled through, one-line help is shown for it in the mode line. And if you hit `C-M-RET' then the complete `describe-function' help for it is shown in `*Help*'. Same thing for faces (using `describe-face'), packages,... whatever. Same thing for key completion: the available keys (at top level or after a prefix key) are completion candidates, and their help too is available in the mode line and (on demand) in *Help*. So yes, I agree that discoverability is radically helped by providing help on completion candidates. And extending this to keys is particularly helpful. Emacs lets you know what you can do at any time, and lets you find out more and more about what's possible, on demand, on the fly. (You can access the manual from *Help*...)