From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el Date: Wed, 26 Dec 2018 15:13:41 -0500 Message-ID: References: <20180922154639.23195.66360@vcs0.savannah.gnu.org> <20180922154640.9D58220310@vcs0.savannah.gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1545855118 17589 195.159.176.226 (26 Dec 2018 20:11:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Dec 2018 20:11:58 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 26 21:11:54 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gcFWz-0004TJ-Ce for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2018 21:11:53 +0100 Original-Received: from localhost ([127.0.0.1]:48052 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcFZ5-0003LG-Tu for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2018 15:14:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcFYx-0003Kw-La for emacs-devel@gnu.org; Wed, 26 Dec 2018 15:13:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gcFYs-0000MP-Tj for emacs-devel@gnu.org; Wed, 26 Dec 2018 15:13:55 -0500 Original-Received: from [195.159.176.226] (port=34289 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gcFYs-0000Ie-Gb for emacs-devel@gnu.org; Wed, 26 Dec 2018 15:13:50 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gcFWi-0004CP-Uz for emacs-devel@gnu.org; Wed, 26 Dec 2018 21:11:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 81 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:7YpXWDvvMjAnRdYZck66arGDECU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:231991 Archived-At: >> +(cl-defgeneric project-files (project &optional dirs) >> + "Return a list of files in directories DIRS in PROJECT. >> +DIRS is a list of absolute directories; it should be some >> +subset of the project roots and external roots." >> + ;; This default implementation only works if project-file-completion-table >> + ;; returns a "flat" completion table. > > That sounds like a fair concern, never thought about it. Do we want to have > both as generic functions, though? People will have to take care to keep > them in sync. Not sure what you mean by "keep them in sync". > Not sure if item 1 is ever going to materialize, and it would only help in > certain cases. But since file listing can be slow sometimes, should we > consider having some other kind of return value, for performance? > Say, a stream of some kind. It could be handy for multifile-based commands, > since they only show one file at a time. Ideally, though, the stream should > be easily composable with external tools like Grep. > > Ideas? We could define it to return a *sequence*, so it can either return a list, or a stream, or an array, .. >> - (let* ((new-prompt (if default >> + (let* (;; (initial-input >> + ;; (let ((common-prefix (try-completion "" collection))) >> + ;; (if (> (length common-prefix) 0) >> + ;; (file-name-directory common-prefix)))) > > Interesting suggestion if we only want to use this function in > project-find-file. I see the same effect, though, if I just press TAB. Having to type TAB makes the interface quite different from just `find-file`. > Or I can right away type a unique file name, press TAB and see it completed > to the full file name. I wonder what other people think; I still haven't > managed to get off Ido, personally. Indeed, that's why that code is commented out: inserting the common prefix is a bad idea for substring completion. I think TRT is to take the above common-prefix-directory, add it to the prompt, and remove it from each completion candidate: this will keep substring completion working correctly (and working even better since it won't uselessly find matches in the common prefix) and will also clarify where the search takes place. >> +;;;###autoload >> +(defun project-search (regexp) >> +;;;###autoload >> +(defun project-query-replace (from to) > > I'm not a fan of these names. I know they kind of mirror what we already > have in the dired- namespace, but can't we do better? If you have better ideas, by all means change them. > I think it's going to be hard for a user to differentiate between > project-find-regexp and project-search. And that they might also have > a guess that the latter "searches" for a project among the opened ones. Not only I'm not wedded to those names, but of those two commands the one that I use is project-query-replace. I only added the other one "for completeness". > Should we move both commands to the multifile package and name them, for > instance, multifile-project-find-regexp (or multifile-project-search) and > multifile-project-query-replace-regexp? No opinion on that either. > Originally we thought that this kind of UI preference would be enacted using > xref-show-xrefs-function, but apparently that's not so easy to do. I don't know what such an approach would look like. Stefan