From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: Completions in Semantic Date: Mon, 19 Oct 2009 18:17:08 -0400 Message-ID: <1255990628.6961.1084.camel@projectile.siege-engine.com> References: <87tyxwxq6t.fsf@stupidchicken.com> <1255924220.6961.1039.camel@projectile.siege-engine.com> <1255969613.6961.1056.camel@projectile.siege-engine.com> <1255980824.6961.1075.camel@projectile.siege-engine.com> Reply-To: eric@siege-engine.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1255990596 4475 80.91.229.12 (19 Oct 2009 22:16:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2009 22:16:36 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 20 00:16:25 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N00Wc-00034J-QX for ged-emacs-devel@m.gmane.org; Tue, 20 Oct 2009 00:16:23 +0200 Original-Received: from localhost ([127.0.0.1]:44929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N00Wc-0005Dx-6E for ged-emacs-devel@m.gmane.org; Mon, 19 Oct 2009 18:16:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N00WV-0005Cm-6c for emacs-devel@gnu.org; Mon, 19 Oct 2009 18:16:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N00WU-0005CM-HU for emacs-devel@gnu.org; Mon, 19 Oct 2009 18:16:14 -0400 Original-Received: from [199.232.76.173] (port=52338 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N00WU-0005C8-9w for emacs-devel@gnu.org; Mon, 19 Oct 2009 18:16:14 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:36767 helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N00WT-0004mW-UY for emacs-devel@gnu.org; Mon, 19 Oct 2009 18:16:14 -0400 Original-Received: from projectile.siege-engine.com (localhost [127.0.0.1]) by projectile.siege-engine.com (8.14.3/8.14.3/Debian-6) with ESMTP id n9JMH9Va002250; Mon, 19 Oct 2009 18:17:09 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n9JMH9uu002249; Mon, 19 Oct 2009 18:17:09 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: X-Mailer: Evolution 2.26.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:116256 Archived-At: On Mon, 2009-10-19 at 16:06 -0400, Stefan Monnier wrote: > >> You mean like lisp-complete-symbol but modal? > > > Yes, that's what I meant, but in light of your simplified description, I > > suppose it doesn't matter much. If there was a single function like > > 'completing-read' that took arguments to control what proposed text > > after the cursor was, I suppose it wouldn't matter what happened > > underneath. I used overlays and overlay keymaps. > > > You could try semantic-complete-analyze-inline on something that needs > > completing to see the effect I was going for. It should work for Lisp > > or C code. > > > I would expect designing such a thing would be challenging since the > > rules for what is before the cursor is a bit vague and language > > specific, so it might belong in a tool like Semantic. > > We have `symbol-complete' although I'm not very happy about its API. > But something along thses lines would be good. When I rewrite the > minibuffer completion code I tried to make it possible to use it in > non-minibuffer contexts, so for example lisp-complete-symbol nowadays > uses minibuffer-complete internally. I was unaware of that, but it sounds useful. > I also intend to consolidate the comint completion this way, tho it's > more difficult because its current UI is slightly different. Part of > the difficulty is how to determine when the "completion is done" so as > to know when to pop-down the *Completions* buffer (if any). Maybe the > best option is to pop-down *Completions* eagerly ("all the time"). For my completion engine, I used an overlay to wrap the text being completed. As soon as the cursor leaves the overlay, or if the user types a character that doesn't belong in the symbol such as SPC, ., or other punctuation, then it exists. The post-command-hook is a bit complex during the semantic inline completion. Perhaps that style of interface could be used, if not directly. I was going for something where the completion part could activate at idle time without interfering with regular editing commands. ie, if the user was typing away or using point motion, nothing would change, but if they saw the decoration indicating active completion, they would know that TAB was special. A side effect is that a *completions* buffer is not always desired, so there are some experiments on completion showing that might not need a buffer, such as the tooltip, or ghost-text. These options have varying success in this task. The semantic complete code for inline stuff uses the same completion and display engines as the minibuffer or inline prompts, so you can mix and match the pieces. Hopefully an official API can do something similar, so you can complete in the minibuffer or inline with the same functions. Eric