From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: find-file-project Date: Wed, 16 Sep 2015 01:21:30 +0300 Message-ID: <55F899EA.7050700@yandex.ru> References: <86pp1j4ejm.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1442355732 7665 80.91.229.3 (15 Sep 2015 22:22:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 22:22:12 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 16 00:22:05 2015 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 1Zbybz-0003Wk-SZ for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 00:22:04 +0200 Original-Received: from localhost ([::1]:46192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zbybt-0005if-La for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 18:21:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zbybp-0005iL-Kw for emacs-devel@gnu.org; Tue, 15 Sep 2015 18:21:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zbybm-0005GX-HF for emacs-devel@gnu.org; Tue, 15 Sep 2015 18:21:53 -0400 Original-Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:32831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zbybm-0005GT-7v for emacs-devel@gnu.org; Tue, 15 Sep 2015 18:21:50 -0400 Original-Received: by wiclk2 with SMTP id lk2so48246103wic.0 for ; Tue, 15 Sep 2015 15:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=KOgSY7MMb/Hf+3v9eH3aYPNalmjjxahPGEHtSS5951w=; b=Adjv1ZaowHx+ZyyX19s+LUZITXtnSpjfGH+4avy5pkJ+SEI3ZKP9uNCYMD6z4DdrkW P+UlDn8pYVc/h06EILXmS3ln0TN6+bAsZcatVRNGhGLN+0BbKW5zLs7z9SMBeHcVK01g E+8Qgv/XLsnYwE/GBgZ6IvumNjDhPnc/JwxZZfiaHpLPygVUfpje1/YCU6unygPvFM/S asnTJ5MKh+B7KgZ4/0lCqTzHgxub9R0LjC6SixOy6oFoSYwFAxcHU+Bp8ypxfdSNqmUK 3JNJGec1s5n/WVGtAKfErE1WrR930q9FGEJ1cIfX9ueXYAhZztviJVLvt9RGhpvI1Juy WsaQ== X-Received: by 10.194.105.73 with SMTP id gk9mr48078859wjb.122.1442355709527; Tue, 15 Sep 2015 15:21:49 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id bh5sm23233319wjb.42.2015.09.15.15.21.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2015 15:21:48 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: <86pp1j4ejm.fsf@stephe-leake.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22c 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:189990 Archived-At: Hi Stephen, We've discussed this before: I think this approach adds too much infrastructure (like forces through bits of "flat" project support, which aren't optimal for most of the projects I know of). Why not just implement completion on file paths relative to the project root? The user could input a base file name, if they like, and TAB would expand it to one of the relative paths if it's unique, or allow them to input a directory. You won't need any other uniquification then. On 09/15/2015 11:23 PM, Stephen Leake wrote: > Attached is a patch that implements find-file-project, with completion > of file-name on the project search path. It handles duplicate filenames > by uniquifying them witht trailing directory names. Maybe call it find-file-in-project? > The patch also adds small projects for elisp and global, to show that > this approach works for multiple backends. I don't see the elisp backend. Regarding global, is there no related semantic-symref-tool command? Maybe it would make sense to implement this in a generic fashion. > I can break this into smaller commits on master, if that seems like a good idea. If you want to test it out, please commit it to a feature branch instead. > I didn't add a NEWS entry. I don't think we are putting project related > changes in NEWS yet, since it is all new in Emacs 25. But the > file-name-all-completion change needs a NEWS entry. We will add NEWS entries before the release. > +(defun find-file-complete-global (filename) > + "Prompt for completion of FILENAME in a Gnu global project." > + (setq filename > + (completing-read > + "file: " ;; prompt > + (completion-table-with-cache #'find-file-complete-global-table) ;; collection > + nil ;; predicate > + t ;; require match > + filename > + )) I don't think each implementation should do its own completing-read. Rather, they should just return the completion table from a generic method. E.g. (cl-defmethod project-file-completion-table ...). > + ;; and the user completes to the first, the following global call > + ;; will return both. The desired result is always the shortest. I'd say the better match wins (not the shortest path), but if you want to add sorting, completion-metadata can include display-sort-function. > +;;; project.el integration > + > +(defun project-try-global (dir) > + (when (cedet-gnu-global-version-check t) > + (let ((root (locate-dominating-file dir "GTAGS"))) > + (when root > + (list 'global root))))) > + > +(cl-defmethod project-find-file ((prj (head global)) filename) > + (let ((default-directory (file-name-as-directory (nth 1 prj)))) > + (find-file (find-file-complete-global filename)))) ...if you're sure it's a good idea. After all, GNU Global is just a tool, it doesn't (and cannot) know too much about a project. If it's used as just-another project implementation, you won't be able to integrate it with some more advanced kind of project definition. > +(defconst find-file-uniquify-regexp "^\\(.*\\)<\\(.*\\)>" > + "Regexp matching uniqufied file name. > +Match 1 is the filename, match 2 is the relative directory.") This is way complicated. completion-at-point interface will help with typing, no real need to shorten the file names. Another benefit of delegating all that to a completion table, is that different kinds of frontends would be able to use it. > +;; Conversion between recursive and flat paths. > +(defun project--directory-directories-1 (dir ignore-regexp) > ... > +(defun project--directory-directories-recurse (dir ignore-regexp) > ... > +(defun project-recursive-ignores-to-flat (recursive-path ignore-dirs) > ... > +(defun project-flat-to-recursive-ignores (flat-path) > ... > +(cl-defgeneric project-ignore-dirs (_prj) > ... > +(cl-defgeneric project-flat-search-path (prj) > ... Do you really need all this? > + ;; FIXME: do we need both project-ignores and project-ignore-files-globs? Just having project-ignores should suffice.