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 11:45:59 -0400 Message-ID: References: <87ehsvh0fv.fsf@gmail.com> <87obrzb5dh.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1331739988 16461 80.91.229.3 (14 Mar 2012 15:46:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Mar 2012 15:46:28 +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 16:46:26 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 1S7qPA-0000i1-Ac for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2012 16:46:24 +0100 Original-Received: from localhost ([::1]:41524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7qP2-0005qN-UQ for ged-emacs-devel@m.gmane.org; Wed, 14 Mar 2012 11:46:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7qOu-0005m3-PR for emacs-devel@gnu.org; Wed, 14 Mar 2012 11:46:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7qOo-00077B-B6 for emacs-devel@gnu.org; Wed, 14 Mar 2012 11:46:08 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:55436) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7qOo-000773-6h for emacs-devel@gnu.org; Wed, 14 Mar 2012 11:46: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="167977897" 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 11:45:59 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 35C72AE2B3; Wed, 14 Mar 2012 11:45:59 -0400 (EDT) In-Reply-To: <87obrzb5dh.fsf@gmail.com> (Vitalie Spinu's message of "Wed, 14 Mar 2012 15:54:02 +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.183 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:149050 Archived-At: >> 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. > I don't really understand how :exlusive 'no prevent partial completion > (in case you mean the obsolete package complete.el). This is a limitation due to the way it's currently implemented. Hopefully the implementation will be improved, maybe by taking various "completion data" and combining them along the lines of what completion-table-in-turn does (so if you have three non-exclusive completion data like files, tags, and whatnots, the completion would first try prefix completion on files, then on tags, then on whatnots, and then partial-completion on files, than on tags, then on whatnots, ...). But this opens up various other problems: - what if the beg..end of those completion data are not the same? - what if the completion `category' of those completion tables is not the same, and hence the completion-styles and/or cycle-thresholds to use are not the same? Another approach is to first try all completion styles for files, then all completion styles for tags, then all completion styles for whatnots. But this will require less localized changes in minibuffer.el. > So if there is no partial expansion of foo_bar|, doesn't :exlusive > pass the handling over? No, I'm saying that if you typed "fo/ba" it will pass the handling over before trying "foo/bar". > comint-filename-completion is active in all comint buffers, and it > prevents the completion UI to reach the global > tags-completion-at-point-function. And this is a bit of a limitation. Indeed, it's a limitation. > In other modes than comint, file completion of 'sdfdsf, or anything else > not prefixed by "/", or even not quoted, is not a filename, and should > be passed over. At least for shell-mode, there are really very few cases where we can *know* that a given shell argument is not a file name. The only exceptions I can think of are when we know it because we know what the command is and what its arguments can be. Otherwise, pretty much anything may be a valid file name, e.g. "'The", "The\ ", and friends can very much be the prefix of a file or directory name. >> 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. > That would be great, for the simple reason that hacking > comint-filename-completion, in order to be used in other modes, is a bit > difficult. A real example: > (defun ess-filename-completion () > "Return completion only within string or comment." > (when (ess-inside-string-or-comment-p (point)) > (comint-filename-completion) > )) If you need to modify the return value of comint-filename-completion in non-trivial ways, I recommend (pcase (comint-filename-completion) (`(,beg ,end ,table . ,props) )) > Comint-filename-completion returns a list of length 2 or 3 depending on > filesuffix. Hmm... AFAICT, it's either 0, 3, or 5. > So to tweak it, I have to check for the length, if 2, append, if > 3 insert :exclusive into the last list. Ugly as far as I am concerned. If you only want to add :exclusive, (append '(:exclusive no)) should work (except for the case where is nil). Stefan