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: Fri, 28 Dec 2018 13:07:06 -0500 Message-ID: References: <20180922154639.23195.66360@vcs0.savannah.gnu.org> <20180922154640.9D58220310@vcs0.savannah.gnu.org> <54108dbc-9d12-06ff-3f1d-151118e9b234@yandex.ru> <87sgyi69iw.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1546020964 23096 195.159.176.226 (28 Dec 2018 18:16:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Dec 2018 18:16:04 +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 Fri Dec 28 19:16:00 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 1gcwfv-0005rG-AQ for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2018 19:15:59 +0100 Original-Received: from localhost ([127.0.0.1]:60924 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcwi1-00079H-Sv for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2018 13:18:09 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcwhm-0006xU-Ix for emacs-devel@gnu.org; Fri, 28 Dec 2018 13:17:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gcwXY-0004ER-U8 for emacs-devel@gnu.org; Fri, 28 Dec 2018 13:07:24 -0500 Original-Received: from [195.159.176.226] (port=33572 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gcwXY-0004BN-N6 for emacs-devel@gnu.org; Fri, 28 Dec 2018 13:07:20 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gcwVN-0000oz-Qx for emacs-devel@gnu.org; Fri, 28 Dec 2018 19:05:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 54 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:AcR0PiF1bS5EEBivNpS9tJLxSbM= 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:232022 Archived-At: Juri wrote: > 'git ls-files' seems very fast, and moreover it outputs only relative > paths, not absolute. [ Nitpick: the GNU convention says these are "file names" rather than "paths". ] > On TAB completion with too long absolute paths > the list of completions is quite unreadable. That's why I was suggesting to start by stripping the common prefix. > Also is it possible to complete only on file names, not paths? With the `substring` completion style, yes. > I think they should mirror everything that makes sense to use in the > multifile project: project-occur, project-grep, ... occur operates on buffers, not files, so I don't think mirroring it into multifile- or project- makes much sense. The corresponding command for files is `grep`, so `project-grep` might make sense. Dmitry wrote: > Stefan, I think Juri is (maybe unknowingly) hinting that the package's name > is a bit unfortunate. I'm not particularly proud of that name. All I wanted was the multifile-query-replace feature, and "multifile" just was the least bad name I could come up with. That's also why I chose the name `project-query-replace` over `multifile-query-replace` or anything like that: the fact that it uses multifile.el is an internal detail, IMO. Juri wrote: > Either prefix multifile- or project- is fine, but not both at the same time. > Or better just shorten to multi-. We already have multi-isearch (not > supporting project yet). I chose "project-" so it actually says to which files it is supposed to apply, compared to "multi-" or "multifile-" which just says that it applies to several files but without clarifying which are those. Dmitry wrote: > OK, let me put it another way: "multifile" is just a package that implements > a particular UI. It is in no way synonymous with "project". Maybe a better > name for it would be something like bufferloop (suggestions welcome). multifile loops over several *files* rather than buffers, so I'm fine with "fileloop" or "iteratefiles", but "bufferloop" doesn't seem right. Stefan