From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: A project-files implementation for Git projects Date: Thu, 19 Sep 2019 18:33:23 +0300 Message-ID: <64bcedbf-d891-dcad-ac65-5719920f58e2@yandex.ru> References: <8736h9rdc4.fsf@gnu.org> <87mufcfz1u.fsf@gnu.org> <87tv9kz2x6.fsf@gnu.org> <87a7bbjdwe.fsf@gnu.org> <87a7ba8uvx.fsf@gnu.org> <87pnk2zvvy.fsf@gnu.org> <838sqpx9eq.fsf@gnu.org> <83y2yow9dy.fsf@gnu.org> <838sqnw2na.fsf@gnu.org> <3007947f-f4eb-e3e8-8c14-1b372323aa1c@yandex.ru> <831rwfvzd6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77627"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 19 17:34:40 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iAyS5-000K3b-SZ for ged-emacs-devel@m.gmane.org; Thu, 19 Sep 2019 17:34:38 +0200 Original-Received: from localhost ([::1]:45652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAyS4-0008SQ-DX for ged-emacs-devel@m.gmane.org; Thu, 19 Sep 2019 11:34:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36300) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAyQz-0008Rp-Rz for emacs-devel@gnu.org; Thu, 19 Sep 2019 11:33:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iAyQy-0006bj-Gu for emacs-devel@gnu.org; Thu, 19 Sep 2019 11:33:29 -0400 Original-Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:34835) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iAyQy-0006b1-8S; Thu, 19 Sep 2019 11:33:28 -0400 Original-Received: by mail-lj1-x22e.google.com with SMTP id m7so4074815lji.2; Thu, 19 Sep 2019 08:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ywEioHVgguR1I6C4eRKM2RS86IVi9X7EeRwj1ScKWUs=; b=oC56eKSs4genWwKY+NVAwASCjgz2XnRgjc8BGuku1YtH1oacks3nF1+GSJANkUx6B6 8LJ7WKMH3aSFITfIV3uA5jhqoldNhXjv9SoOboj8kdGG7Xo4BVzLyzs/rBjkdQVAZ0LS ZuiUbbIOhgWWcQ3G8oCEPE+7qgykielosqLlgOivSxzlgoJcDFaCWmUOJVH5DlBsOFu3 psi6I88Fr/J0DqZUSh94FmG7/R6Rlkk0RJEEgi8wZjUAHjbCnGXuNcq3s5hHoyzTwNA+ k82LB6bO/bgl2JSLfiuzbiD2VoKDuw11c+TWvV8QV6AJSLleLNQ/lqUy8zUXDKtXhME8 IsmA== 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:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ywEioHVgguR1I6C4eRKM2RS86IVi9X7EeRwj1ScKWUs=; b=ugbCQ1onT5AA4dcYMTrcnwXIOPBcBRqjfaZU7Rf0or/uaiS7nYMmvuyVOLqDIT9pOF NT0Q+KTxu6MQnQWkHWRZkliXbTPflBbBSBuGIIZESs9p0ZfTVfQSs1hnBJ8WP7IjqMNr a1ZGIEHjb2pMyeu26uc24xE8PYLlzNTk7q81SlXVr59fpZM6me2eCrmhtFJ0oJXRcmv+ ygWdMD69cgU2s8yleOUrES0s0HkbDcDAmK8OD+r8/FlRQoUrxh0+ogPh1V2QcoRcjk5C y2JWacpD21WwZWh1ZTP6plkw0a+1/rdqbK/pimqXPHpBj8eTlTQ+Q7Y5i5YSEG3cCS3E XqzQ== X-Gm-Message-State: APjAAAVdrMZ8vLsAbeolaQ7JCiMRmaCkufbCmWHrJNBk97cQWcX4lL5p hVGxdLnFppbOE1Snk92SGiM8cZLCFXc= X-Google-Smtp-Source: APXvYqxS0rHh5aonZaXiv9JNqimCZrgM89Ta3AGj5g4pg95FASKj3yB2QYfMkzbDeJmMHmQUvwtkUQ== X-Received: by 2002:a2e:5c09:: with SMTP id q9mr6013576ljb.4.1568907205672; Thu, 19 Sep 2019 08:33:25 -0700 (PDT) Original-Received: from [192.168.1.142] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id r22sm1744220ljr.43.2019.09.19.08.33.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Sep 2019 08:33:24 -0700 (PDT) In-Reply-To: <831rwfvzd6.fsf@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::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:240170 Archived-At: On 17.09.2019 16:14, Eli Zaretskii wrote: > My point is that having to work with > long 'find' command lines is unwieldy and inelegant. A given VCS > repository can have many dozens of ignored files. I don't see how the length of the command line is an issue. The user won't see it. And anyway, as we've established, the find-based solution will have to be there anyway, at least for some uses. So there's no use arguing about its awkwardness: the complexity coming with it will have to be there anyway. >> Second, like I said, using Git for this purpose seems easy enough. >> Others, less so. > > I don't see how you arrived to the last conclusion. AFAIU, Tassilo > presented code to deal with others as well. Sorry it's in the thread. Including the end of the message you were replying to. >> It's not intuitive that a user has to vc-register a file before it shows >> up in 'project-find-file'. > > We already established that we will show also non-registered files, so > this is a non-issue. I was replying to a sentence from you where you seemed to disagree. >> From what I see, it doesn't allow to "unignore" certain files >> selectively, and I'm not sure if there's a way to apply additional >> ignores except by doing it in Lisp. > > What do you mean by "unignore"? Which VCS backend allows you to do > that, and how? Err, not yet. But I'm thinking we should allow adding entries like '!/foo/bar' to project-vc-ignores, similar to Git's related syntax. The find-based indexer is yet to learn to support that feature, but asking Git to add extra whitelist entries looks fairly easy. > It isn't the problem of filenotify the package, it's a problem with > the OS features it uses: inotify, knotify, etc. They all lose events > when there are a lot of file operations in a tree. E.g., try using > Auto-revert-tail mode on a log file produced by building the Boost > library -- in the default mode, where it uses file notifications, it > simply chokes. Should there be a way to debounce the events, or handle this somehow? For instance, when too many events come, we could simply discard the files list cache, and force it to be rebuilt later. For this particular use, we don't really have to see every notification. >> That's not the only problem. We want to change the ignores list >> arbitrarily, or maybe just use a user-defined one. It will usually >> correlate with the contents of gitignore/hgignore/bzrignore, but not >> exactly. And neither Hg or Bzr seem to offer easy ways to adjust their >> lists of ignores before output. > > Then those features will be not available for hg and bzr, or we will > tell their users that must have that to switch to 'find'. But let's > not bypass VC where it can do the job, because that's TRT from where I > stand. We should not design our implementations for the lowest > denominator, especially when we know that a large proportion of the > users will use Git anyway. Yes. Like I said several messages back: "We probably want to use Git because it's fast and flexible, but other VCSes are going to be less helpful". Tassilo might prove me wrong in some instances, but it's definitely hard to support this feature across the range of VC backends. So it *would* make sense to bypass VC (the API) and just use Git (and maybe Hg) directly when available.