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: comint-filename-completion and :exclusive completion bugs Date: Wed, 14 Mar 2012 09:53:57 -0400 Message-ID: References: <87ehsvh0fv.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1331733261 23228 80.91.229.3 (14 Mar 2012 13:54:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Mar 2012 13:54:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 14 14:54:20 2012 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 1S7oeh-0008Sy-4J for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2012 14:54:19 +0100 Original-Received: from localhost ([::1]:36015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7oeg-0007WH-It for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2012 09:54:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7oeW-0007Vl-Pg for emacs-devel@gnu.org; Wed, 14 Mar 2012 09:54:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7oeQ-0003zF-IE for emacs-devel@gnu.org; Wed, 14 Mar 2012 09:54:08 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:31281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7oeQ-0003up-Ea for emacs-devel@gnu.org; Wed, 14 Mar 2012 09:54:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9soXdS/2dsb2JhbACBX5x7eYhwnhmGGQSbGYQJ X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="167964949" Original-Received: from 108-161-119-82.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([108.161.119.82]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 14 Mar 2012 09:53:58 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id D1914AE08D; Wed, 14 Mar 2012 09:53:57 -0400 (EDT) In-Reply-To: <87ehsvh0fv.fsf@gmail.com> (Vitalie Spinu's message of "Wed, 14 Mar 2012 12:44:04 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:149041 Archived-At: > Place the point after 'sfsdf and M-x completion-at-point. You will get > "No-match" message. The intended behavior is to pass over to next > completion function `test-completion'. Actually, no this is not the intended behavior (unless you specify :exclusive 'no): functions on completion-at-point-functions are supposed to only return non-nil if the text at point is one for which they intend to take responsibility. This is important, because it then allows completion-styles to try harder ("aha! there's no matching prefix? well, let's see if there's some other way to find a match"). Otherwise, the completion UI gets a dilemma: in case of completion style fails, should it try the next completion style, or should it try to fallback on the next completion data? The ":exclusive 'no" solves this dilemma by only allowing prefix completion. I think that for filename completion, non-prefix completion is important, so while I can agree that comint-filename-completion often isn't really sure whether it should take responsibility (because it doesn't actually know that there should be a filename at point), preventing things like partial-completion on filenames would be sad. Maybe we could provide a comint-maybe-filename-completion which would set the ":exclusive 'no", for situations like yours where you prefer falling back on some other completion data if the text isn't a prefix of a valid filename. Or maybe you can change your own completion function so that rather than placing it after comint-filename-completion, you can place it before. > Now it works after 'sfsfd, but it reveals the following problem with > :exlusive argument: > Place your cursor after /bin and M-x completion-at-point, which > completes to /bin/, but calls test-completion with 3 arguments: `test-completion' is a predefined function taking 3 args, which you just redefined as something completely different, leading to all kinds of funny results. Stefan