From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: dont.spam.earl@gmail.com Newsgroups: gmane.emacs.help Subject: Re: Looking for universal completion with simple UI Date: Tue, 7 Oct 2014 08:39:15 -0700 (PDT) Message-ID: <0a07ca5d-d79f-42d8-b74c-f8e7b8fdfae0@googlegroups.com> References: <778b7522-e7b5-4ee7-89fa-10548516d79c@googlegroups.com> 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 1412696470 13479 80.91.229.3 (7 Oct 2014 15:41:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2014 15:41:10 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Oct 07 17:41:05 2014 Return-path: Envelope-to: geh-help-gnu-emacs@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 1XbWsr-0007aT-3C for geh-help-gnu-emacs@m.gmane.org; Tue, 07 Oct 2014 17:41:05 +0200 Original-Received: from localhost ([::1]:59467 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbWsq-00062S-PW for geh-help-gnu-emacs@m.gmane.org; Tue, 07 Oct 2014 11:41:04 -0400 X-Received: by 10.43.94.134 with SMTP id by6mr2664012icc.18.1412696355765; Tue, 07 Oct 2014 08:39:15 -0700 (PDT) X-Received: by 10.182.91.5 with SMTP id ca5mr14002obb.32.1412696355540; Tue, 07 Oct 2014 08:39:15 -0700 (PDT) Original-Path: usenet.stanford.edu!h18no2732227igc.0!news-out.google.com!rp1ni22143igb.0!nntp.google.com!uq10no5794215igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=207.198.105.23; posting-account=QyAvTQoAAADtRdvZ5VbKTpUdY2nZ1GFk Original-NNTP-Posting-Host: 207.198.105.23 User-Agent: G2/1.0 Injection-Date: Tue, 07 Oct 2014 15:39:15 +0000 Original-Xref: usenet.stanford.edu gnu.emacs.help:208048 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100324 Archived-At: Yes, these are important UI considerations that I hadn't thought through ye= t. Thanks for outlining the possibilities.=20 I see now how Icicles does indeed provide much of the functionality I'd lik= e including supporting comint inputs, search history, etc. Drew - The one unresolved issue for me is simplicity: the documentation for= Icicles spans dozens of pages on emacswiki.org. Even after using it for a = few months, I'm still surprised and turned-off by some of the defaults. I c= an envision an "Emacs Starter Kit"-style layer on top of icicles that provi= des a simpler interface and smoother learning curve. This might come at the= cost of some of the advanced features and configurability however. If it w= ere to have a different name yet acknowledge Icicles in its documentation, = is that something you'd oppose? Thanks, Earl On Sunday, October 5, 2014 10:53:01 PM UTC-7, Drew Adams wrote: > > Drew - thanks for the response. Yes, Icicles is the most >=20 > > comprehensive package for completion I've found, particularly for >=20 > > the mini buffer. I found it especially helpful to read you >=20 > > explaining the philosophy here: >=20 > > http://stackoverflow.com/questions/2100166/making-sense-out-of- >=20 > > emacs-completion-mode-choices >=20 > >=20 >=20 > > It appears Icicles is focused on mini-buffer completion though. >=20 > > Any tips for the various forms of in-buffer completion: searching, >=20 > > cycling through killed text, etc.? >=20 >=20 >=20 > One consideration is where you type the text to be completed, i.e., >=20 > whether you type it first in the minibuffer or you type it directly >=20 > in the destination buffer. >=20 >=20 >=20 > IOW, even if you are completing text that you type into a buffer >=20 > (e.g., code), completion can use the minibuffer for (temporary) >=20 > text entry and another buffer (e.g. `*Completions*') for candidate >=20 > display. (Or it could, Ido-style, use the minibuffer for both input >=20 > and candidate display.) >=20 >=20 >=20 > To complete text in a buffer it is more common that you type there >=20 > and hit a key to complete there, without opening a minibuffer for >=20 > temporary text entry. But where you enter the text is relevant >=20 > only to UI convenience, not to what kinds of completion are >=20 > available, for what contexts, etc. Typing directly into the buffer >=20 > does have the advantage that you need not temporarily move your eye elsew= here (i.e., to the minibuffer or to `*Completions*'). >=20 >=20 >=20 > It is true that Icicles does not have a lot of direct, particular >=20 > support for completing different kinds of buffer text. It supports=20 >=20 > general, dynamic text completion (`dabbrev', `completion.el'). It support= s BBDB text completion, comint (shell) text completion, and >=20 > Lisp symbol completion. Other than those, it does not offer >=20 > anything special completing different kinds of text. >=20 >=20 >=20 > But if another library uses `completing-read' to provide a >=20 > particular form of text completion (e.g., completion for terms >=20 > in a particular programming language), then you can take >=20 > advantage of Icicles completion. Most do not, AFAIK - they tend >=20 > to use in-buffer prefix entry and in-place cycling of completion >=20 > candidates. >=20 >=20 >=20 > Wrt which packages provide particular support for different >=20 > programming languages, others will no doubt chime in with >=20 > suggestions. For vanilla Emacs there are CEDET and Semantic, >=20 > and various programming-language modes should offer some text >=20 > completion. >=20 >=20 >=20 > If you look at the code for the Icicles versions of `dabbrev' >=20 > etc. completion (command `icicle-dabbrev-completion'), you will >=20 > see that it is essentially the vanilla code with Icicles >=20 > completion added to handle the multiple-candidates case. >=20 >=20 >=20 > This means that if you have some existing text-completion code, >=20 > you can likely convert it easily to take advantage of Icicles >=20 > completion for the multiple-candidates case. >=20 >=20 >=20 > (Dunno what you mean by "searching, cycling through killed text" >=20 > as "forms of in-buffer completion". Icicles provides completion >=20 > for searching; for yanking kill-ring text; and for navigating >=20 > using Imenu, bookmarks, the mark-ring, tag files, Info nodes, >=20 > grep or occur hits, buffer narrowings, etc. But I don't really >=20 > see such things as being forms of "in-buffer completion".)