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: Thu, 27 Dec 2018 03:49:26 +0200 Message-ID: <54108dbc-9d12-06ff-3f1d-151118e9b234@yandex.ru> 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 1545875254 16720 195.159.176.226 (27 Dec 2018 01:47:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 27 Dec 2018 01:47:34 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Thunderbird/64.0 To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 27 02:47:30 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 1gcKll-0004EJ-OB for ged-emacs-devel@m.gmane.org; Thu, 27 Dec 2018 02:47:29 +0100 Original-Received: from localhost ([127.0.0.1]:48997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcKns-0007ki-7z for ged-emacs-devel@m.gmane.org; Wed, 26 Dec 2018 20:49:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gcKnm-0007kb-Sh for emacs-devel@gnu.org; Wed, 26 Dec 2018 20:49:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gcKnj-00018B-JB for emacs-devel@gnu.org; Wed, 26 Dec 2018 20:49:34 -0500 Original-Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:52310) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gcKnj-00014E-3x for emacs-devel@gnu.org; Wed, 26 Dec 2018 20:49:31 -0500 Original-Received: by mail-wm1-x32f.google.com with SMTP id m1so15614083wml.2 for ; Wed, 26 Dec 2018 17:49:30 -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=5fEqaWzWCOzLmVN9stEvq3ctdk66G80DRYTIYmlWRls=; b=jRo180NDw/MZw5xoF1Nbw1keMm4X1+NZwh8tPCkd1IbZgaEbDXbu9EpXJeUL3Z6+ST WoVoDI5CTmdJ4B+QFd/S7vdSkfDwDtrs8T21NLOg/JJsbUP2GNWcGJuXLdkGBMpquBNO Vx/dEH2SH58hyrDJJ0JOIXfFsNqS8WKQ9ZvoTzjLtMW5cqRDUTca5dllwPazkUT6qcBu 98QVKZKkgjS+cqOSgwi8LZyh7CjuYTUWZ3b6ofNpKjf4oFTgQqpuUBXwB5K9h7fONOME Oz1I6pCLRusChBEvQ6iTHUjnnIVl0+D1yj+T6TXbodxyRgnkf17BS2mrIbE5Wg73QzCh 0dLg== 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=5fEqaWzWCOzLmVN9stEvq3ctdk66G80DRYTIYmlWRls=; b=NwOWj4UGZVtFSy3FN1KDEGaT13l32+YR56Xg4Ji6B37qPNSZkztmkCC+nY8Jr8TXGq DMoEAM2qT9eSVQVFCwrMayp7sfoIiPo54xhNIbXrdMDZYgzb5F1yXGQFT8OlkFmUfAwn UYvQYenk6qCtH6srVE2lR0Uwn1oO1IngWbA54YdD6li0j91my7yBVdpALKd45B9oVkUa 1GB3nIfrffE1klxtW2gp5W7OAIvG2+WauKxudTSW7/sc8RY2eLrMfOdoABe3AYrjI2hy SS8XqbwWuxVzEqMCZLSdRN/eYxs6CnHCzFREhzVj7cEiz/6PxActU3rMQBlnW81eBa1d lHMw== X-Gm-Message-State: AJcUukdpLu6R8nsSEPAtiftGkD2rDK6TvYqDPuD8FwMYrTvtYP6GHsSc mLXd5+POCbVqd8zL/YMhZKXl91sq X-Google-Smtp-Source: AFSGD/UUnPPexEtGqQMolx6vuZuJ4QlUKbF+5n5FjwxX8Jg2++nL+kpBvJiPLs8NCVWHGr3KWj7Ndw== X-Received: by 2002:a1c:aa0f:: with SMTP id t15mr19095285wme.108.1545875369437; Wed, 26 Dec 2018 17:49:29 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id n6sm22167246wmk.9.2018.12.26.17.49.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Dec 2018 17:49:28 -0800 (PST) In-Reply-To: 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::32f 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:231996 Archived-At: On 26.12.2018 22:13, Stefan Monnier wrote: >> 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". Making sure to implement them in a compatible fashion. My point is, it's probably better to leave just one if the other can (almost?) always be efficiently implemented in terms of it. > We could define it to return a *sequence*, so it can either return > a list, or a stream, or an array, .. OK, so we can turn it into a completion table simply by calling (seq-map #'identity files). Though there might be a better choice. I wonder if we could efficiently implement project-find-regexp on top of a sequence like that, i.e. pipe to Grep with little overhead. And I'm thinking about this because there can be faster ways to list all files in the project than 'find' (e.g. 'git ls-files'). But xref-collect-matches should know nothing about 'git ls-files'. And by streams you mean stream.el in ELPA, right? It mentions "IO streams" but has no examples of that. Guess it's still something to R&D. > 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. Makes sense. Should work as long as '/' is in completion-pcm-word-delimiters. But this approach also needs the completion table to be flat, right? > Not only I'm not wedded to those names, but of those two commands the > one that I use is project-query-replace. This one also needs a docstring update (note to self or whoever). >> 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. OK, so unless somebody objects I'd like to move them to lisp/multifile.el and rename to multifile-project-find-regexp 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. > > I don't know what such an approach would look like. Hmm, maybe it's not easily compatible with multifile, since this function is passed a list of hits already. Not a list of files.