From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 55ec674: * lisp/multifile.el: New file, extracted from etags.el Date: Wed, 26 Dec 2018 05:34:56 +0200 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; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1545795229 6306 195.159.176.226 (26 Dec 2018 03:33:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Dec 2018 03:33:49 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Thunderbird/64.0 To: emacs-devel@gnu.org, Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 26 04:33:45 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 1gbzx3-0001YM-0i for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2018 04:33:45 +0100 Original-Received: from localhost ([127.0.0.1]:44259 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gbzz9-0004Mj-SG for ged-emacs-devel@m.gmane.org; Tue, 25 Dec 2018 22:35:55 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:33631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gbzyK-00042b-5k for emacs-devel@gnu.org; Tue, 25 Dec 2018 22:35:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gbzyG-0001Q5-3i for emacs-devel@gnu.org; Tue, 25 Dec 2018 22:35:04 -0500 Original-Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:50964) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gbzyF-0001Pi-UB for emacs-devel@gnu.org; Tue, 25 Dec 2018 22:35:00 -0500 Original-Received: by mail-wm1-x332.google.com with SMTP id n190so13733205wmd.0 for ; Tue, 25 Dec 2018 19:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=63VUIk4K4YLMCEQGM/yftNLMNJzAo2/TuEJz4fzKuzw=; b=TDDFj/ZHDa07QzgQ3MW9rL6bPpvg7eGZA/zetIZM1yYtQIbtxkfe+YYfNUnFl0G2xg z4/3eemUw5Y/xJdX8BiDo7vtwcf9nVe4s4b2UId97GnEUTu6HzfF2VOhPNy6J8G+oUdB CrRsTe7aGg4jBoz4Tb2wOhTWQy769HoA8tjJ2dmQsWT8nR/LxPqJQNKucy5iy/gMJviV q5ooNDG4BZZJ2KGKuKR88ogaIzgB1B7d3ktyQeoBuyhETMPRdVCS2eS9gad4/hWEM/pF WQljBEc7z+E64o1tQqyqPoyfg3MGTwdCKXXvTSa+bFHmDwMLfm0e8CtpU7FCxdZh1A3G AFYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=63VUIk4K4YLMCEQGM/yftNLMNJzAo2/TuEJz4fzKuzw=; b=nV7hnGgAJ/AWs7Md8qUAS5Q2dg4iksypKoE3S1ou/6xW3fvLfwLJnReLdFhECdTKEk 5P5UgnZelGTc1KDpVEL8OM++gKeoBWNTGSkhBBEwB/Q/6k9B3gGM7ZxOxarj0D+R5z/L VniDL6sAsN9u1Cx6yDsxVFLWS7E4vBODI0WhhZpfJaI1cTcBq3FpzCd93amOcxNs+X8w 3RjNg+xclPgpczkD1+kIf7W1JrGl+ofv94vrhYOogslo8569+POyRQLtu2me/zWg5AQD qY5WqTHcG7OX5CbKUIBz9Op4WU549E1tLqTXXFltw2WpRSdC1G1QqL6CpVhS8Y7ymGGh GhZA== X-Gm-Message-State: AJcUukdfTJJT5cfo1oao0EpEdRENyKPy8IH5rblLYwJUbe26JGGn4lgo MeGuHiDVWGHcI1lQ+ft4PSKNpThO X-Google-Smtp-Source: ALg8bN6buJsS7BXRRXJ/SxDAsnOyBJLbyZ+MCIAuY32hNkvMjEzTAixDY6rJCjGGaTYFVi6L9hZ7IQ== X-Received: by 2002:a7b:c181:: with SMTP id y1mr5765765wmi.10.1545795298760; Tue, 25 Dec 2018 19:34:58 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id e16sm26123360wrn.72.2018.12.25.19.34.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Dec 2018 19:34:57 -0800 (PST) In-Reply-To: <20180922154640.9D58220310@vcs0.savannah.gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::332 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:231987 Archived-At: Hi Stefan, I've only noticed this change recently, hence this late email. On 22.09.2018 18:46, Stefan Monnier wrote: > +(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. > + ;; FIXME: Maybe we should do the reverse: implement the default > + ;; `project-file-completion-table' on top of `project-files'. Originally I figured that having the completion table be a basic part of the propocol gives some benefits: * If there's a background process that filters files faster than Emacs, then it could actually provide faster file completion. * Completion table is a "lazy" value, which can be handy. 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? > + (all-completions > + "" (project-file-completion-table > + project (or dirs (project-roots project))))) > + > (defgroup project-vc nil > "Project implementation using the VC package." > :version "25.1" > @@ -389,12 +401,17 @@ recognized." > ;; removing it when it has no matches. Neither seems natural > ;; enough. Removal is confusing; early expansion makes the prompt > ;; too long. > - (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. 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. > +;;;###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? Maybe rename dired-do-search and dired-do-query-replace-regexp later as well. 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. 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? 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.