From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: `completion-in-region' Date: Thu, 08 Apr 2010 23:05:19 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1270782335 16219 80.91.229.12 (9 Apr 2010 03:05:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Apr 2010 03:05:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Leo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 09 05:05:33 2010 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.69) (envelope-from ) id 1O04XE-00036m-TJ for ged-emacs-devel@m.gmane.org; Fri, 09 Apr 2010 05:05:33 +0200 Original-Received: from localhost ([127.0.0.1]:45030 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O04XD-0002T0-Ea for ged-emacs-devel@m.gmane.org; Thu, 08 Apr 2010 23:05:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O04X7-0002Su-NJ for emacs-devel@gnu.org; Thu, 08 Apr 2010 23:05:25 -0400 Original-Received: from [140.186.70.92] (port=50509 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O04X5-0002Sm-EI for emacs-devel@gnu.org; Thu, 08 Apr 2010 23:05:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O04X2-0006nM-MD for emacs-devel@gnu.org; Thu, 08 Apr 2010 23:05:23 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:39984 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O04X2-0006nH-60 for emacs-devel@gnu.org; Thu, 08 Apr 2010 23:05:20 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALM2vkvO+K6K/2dsb2JhbACbO3K6cYUJBIs6 X-IronPort-AV: E=Sophos;i="4.52,174,1270440000"; d="scan'208";a="60501847" Original-Received: from 206-248-174-138.dsl.teksavvy.com (HELO pastel.home) ([206.248.174.138]) by ironport2-out.pppoe.ca with ESMTP; 08 Apr 2010 23:05:19 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 890A681AE; Thu, 8 Apr 2010 23:05:19 -0400 (EDT) In-Reply-To: (Leo's message of "Tue, 06 Apr 2010 15:37:55 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:123371 Archived-At: > completion-in-region allows a complete customise of its behaviour > through completion-in-region-functions. But minibuffer-message blocks > execution for minibuffer-message-timeout seconds (default to 2) unless > there's input from user. Yes, that's a known problem in minibuffer-message, indeed. Patches welcome. > For example if I define my own: > (defun my-completion-in-region (next-fun start end collection predicate) > (when (funcall next-fun start end collection predicate) > BODY)) > BODY will only be executed after 2 seconds that gives a false slow user > experience. I can work around this problem by let-binding > minibuffer-message-timeout to 0. But I think some improvement can be done > here. completion-in-region-functions is indeed meant for situations where you want to either completely replace the completion UI with some other one (=E0 la completion-ui.el), or where you want to let-bind some completion variables. But indeed, it hasn't been used much yet, so maybe a better interface would make sense. > The above comments are based on my experience to write two > completions: one for TeX: I want the completion to automatically > include a 'close' string (i.e. {} for LaTeX macros etc.), I can write > a function for completion-at-point-functions which returns '(beg end > completion-function) and do the adding in completion-function but it > is difficult to control the position of point so that it locates > between {}. Could you expand on what problems you've encountered when trying to add it in completion-function? You may want to check how I used completion-table-with-terminator in pcomplete.el for that same kind of situation. > Another solution is to customise completion-in-region through > completion-in-region-functions but I need to isolate the interference > between functions in completion-in-region-functions. That doesn't seem like a good approach to add a terminating } > Another for snippet (similar to abbrev), complete the snippet (abbrev) and > then expand if completion succeeds. Hmm... I do not understand the above two lines. They seem to lack context or something. Stefan