From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Mon, 29 Jun 2020 01:14:36 +0300 Message-ID: <363e38af-9a1a-860c-0cb2-a498e8340a36@yandex.ru> References: <87bllfqj82.fsf@warpmail.net> <83o8pfxhzq.fsf@gnu.org> <83imfnxgt3.fsf@gnu.org> <626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru> <83h7v7xf7w.fsf@gnu.org> <831rmayj55.fsf@gnu.org> <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> <83wo42w83e.fsf@gnu.org> <6762abf5-71c1-aa54-1bac-d4c90c20870b@yandex.ru> <831rmavsuq.fsf@gnu.org> <83a70wv4mj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="29138"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 29 00:15:35 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jpfaI-0007TI-LL for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Jun 2020 00:15:34 +0200 Original-Received: from localhost ([::1]:42632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpfaH-000792-GS for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jun 2020 18:15:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpfZU-0006du-Fp for emacs-devel@gnu.org; Sun, 28 Jun 2020 18:14:44 -0400 Original-Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:40512) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jpfZS-0002YL-Eu; Sun, 28 Jun 2020 18:14:44 -0400 Original-Received: by mail-ed1-x532.google.com with SMTP id b15so11267738edy.7; Sun, 28 Jun 2020 15:14:41 -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=btgOvY1LPtfkA4nUFI1RRpr4x90fFK5AawyPpW4b6A0=; b=Hm6Tkz9OLkXt7+Osp7gtCUY3/U5r6yqQxC7zyxh+L9itaZzAxH/4XvTpwMh2aCDBw2 +fYVZaehkdi4MtsoJcDKbt/zzXUyl4SfIBRBaMStgYlt3/Zz6b/kG3f8nWtYJLsHQ7ux aYjTjem4KyNZSEyomzNVbf9Tn9d0kkMvX884/1GPoHxyhKO7RMOlrcL46aO2JdRhlD/t mcZ5AJz/1Zytl7azmp2m9tBncwyONdaXGjSOhh5OfGvOGOWpJYrWI3KjUXjS+3t6j7z6 gDtlOs4gJs2eMiEVMgoDyK67Z5kE0/YIyb+BAn2daeC4fMeFv131PeC1aUtOZKInN3v9 cZ8A== 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=btgOvY1LPtfkA4nUFI1RRpr4x90fFK5AawyPpW4b6A0=; b=ZvblxpIn2b8cempGcjb6I6/lTMk58a9qe+p6zqOYihW4yLqXb+xL+PWmfeN1GN8ukK AkkPPJJVGsaipz4OHWNlcwWoUC+n15m2NUvxxKCp9jncAUYr96TEyPnDjKTZTXd/x2MO EXJtKRSM3e/S75+7qmd6a2Q9LfailbXfAd4vNv1keIN61+94zON2SY7TuYZJyrMIzjGq KAnEs0axyO0qEAEUYDHAzs2o9oxzGF6HZIG7R0aujmHpXuMaD+IyS5krNIJXEH5Enndd +YeciUfL3EXTgg6wpTXO45189B9IF4PQvCGoQ/xvUij9YEMMktkZN1d2KvgundMWER+c xwDQ== X-Gm-Message-State: AOAM531b+AIGv5s5LuFc9FmYFpz547y/ifh3YRBEs7nJsDN/LDY9fg0j HSmFMbRSfoBseUAFZlpvCMLCM0V+ X-Google-Smtp-Source: ABdhPJzUIUbQqkNe/5/7ev5PnE7HNOd70p18lxu+BAeqcBDTnIA9R62B50TtcSESceo1K5VlFAY5QA== X-Received: by 2002:aa7:c2c5:: with SMTP id m5mr14307465edp.214.1593382480046; Sun, 28 Jun 2020 15:14:40 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id s23sm18617482ejz.53.2020.06.28.15.14.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Jun 2020 15:14:39 -0700 (PDT) In-Reply-To: <83a70wv4mj.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=raaahh@gmail.com; helo=mail-ed1-x532.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=1, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252553 Archived-At: (Continuing from the previous email.) On 21.06.2020 18:08, Eli Zaretskii wrote: >> I don't want to dismiss the critique outright. Believe it or not, I really do want you, personally, to be happier and more productive as a result of things I do here. I spent several hours today just thinking about this discussion. But our workflows are different, and expectations are different as well, and it seems that your requests tend to conflict with some design choices I have originally made. >> >> >> One of them was to make the VC project a hands-off backend, one that immediately "just works" (or tries to), with a few possibilities for customization through local variables. > > This must be supported, of course. And the backend which treats an > entire directory with its subdirectories as a project must also be > supported. At this point I'm somewhat inclined to merge these two into one. > I'm not arguing for dropping any of these two. I'm arguing for adding > yet another possibility, whereby the files belonging to a project are > selected by the user, whether by marking in a Dired-like directory > display, or by explicitly naming each file to be added, or by > drag-n-drop. Acknowledged. It's a pretty alien UI paradigm for me (micromanaging project configuration like that). Similarly, I never got into using tags tables because that requires to both generate a file, re-generate it manually, and visit it manually as well. I have seen similar sentiments expressed by other users. (Having said that, I hope to return to adding a feature that auto-generates and regenerates tags tables for the current project using etags, one of these days.) As such, I'd rather let someone else implement the project backend with the features you outlined. And if someone decides to take it up, I have a number of thoughts on how it can be better integrated. OTOH, along the lines of Juri's opinion, perhaps your requirements could be satisfied by making use of whitelisting entries in VC project config. But if your projects indeed span multiple directories, the config couldn't reside in some particular root, then that calls for a separate backend. > Based on the discussion of non file-visiting buffers related to a > project, I think there should also be a command that would allow the > user to include/exclude such buffers from the project, because it > doesn't make sense to me to decide up front that any *shell* or *grep* > or whatever buffers are automatically considered to be part of the > project based on something as ephemeral as their default-directory. As I explained, with project-vc you don't "decide" anything like that up front, you just internalize the idea that any buffer with default-directory inside the project's root more or less "belongs" to that "project" (the meanings of both terms are apparently different from how you use that words). So, if you need to switch to said buffer, you make sure to use the appropriate command (either project-switch-buffer, or switch-buffer, or project-switch-project). >> You seem to think (and this is only my guess, of course) that a project is a unit of work. And that whatever files, or activities, are pertinent to your current goal, are a part of that project. Hence, if you do a search anywhere, in any directory, but in pursuit of that goal, the search results are certainly a part of the current project. It is certainly a valid viewpoint, but one that I have never considered before. > > I think it needs to be considered because it's a valid use case and > happens in practice. It would be useful to support it OOTB. I'd like to make this clear: it's not a "use case", it's a point of view. If one considers a project to roughly be a "directory with files in it", and their work spans several such directories, they will think that the work spans several projects, and that's it. > Even if > all the files belonging to a project are in the same directory, the > MO where _all_ (or a vast majority) of the files in a directory belong > to the project is a serious limitation, and we shouldn't impose it on > our users. Granted, one can produce a large enough exclude/ignore > list to leave only a handful of files, but if just 5% or 10% of files > in a directory should be part of a project, excluding the other 90% or > 95% is a nuisance and an unnatural thing to do. This sounds like a use case for whitelist entries. >> So I'm not sure where to go from here. If the latter viewpoint has more supporters, perhaps an new, alternative backend is the way to go. This would be a test of the API, how well it adapts to different goals. > > I'm not talking in terms of backends, I'm talking in terms of > user-facing features. I think we should decide whether a feature such > as the above should be part of what project.el supports, and then > consider how to implement it. I don't see why the implementation > should be very complicated, FWIW, so there's no need to bring the > implementation into the picture, not yet. A naive implementation should be pretty easy. What is difficult is fitting this starkly different kind of interaction and configuration in the current design. Having interactive commands affect project-vc's configuration is a murky idea, having two different ways to configure it. And it would have to add some new variables as well, that affect its behavior. Or some other configuration storage. So ultimately, if you really want this kind of interaction, it would be better to have a separate backend. It could also have a different author than myself, thereby validating the idea that it is, indeed, something that users want.