From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Thu, 2 Jul 2020 01:57:37 +0300 Message-ID: <44f2f1f4-ae34-f0bf-b153-f33b8ee6069f@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> <5542db0c-cc0d-2743-87ae-7728a0cc94bb@yandex.ru> <83ftaf2rj2.fsf@gnu.org> <43a8f8d4-83fb-f012-8e1d-c1a618b0ef59@yandex.ru> <83mu4m0vub.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="blaine.gmane.org:116.202.254.214"; logging-data="15941"; 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 Thu Jul 02 01:00:22 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 1jqliI-00043B-13 for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Jul 2020 01:00:22 +0200 Original-Received: from localhost ([::1]:52652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jqliG-0008Tr-Vv for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Jul 2020 19:00:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jqlhb-00084F-Lm for emacs-devel@gnu.org; Wed, 01 Jul 2020 18:59:39 -0400 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:34486) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jqlfk-0003Fs-Bo; Wed, 01 Jul 2020 18:59:39 -0400 Original-Received: by mail-wr1-x436.google.com with SMTP id f7so22772354wrw.1; Wed, 01 Jul 2020 15:57:43 -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=tkBwIJTqxcFCA7D9/JKxQNFcqwhrm54MhgM//0OcaDI=; b=Zj0e5rzZE/pkjH5SmtjGJ78HXpUwtrgBacFFwGOzPmpEpihHRsCsYjei3vhHpQjKPE 6mdxqN426O9C1LCPz8MwNoQBaXjq9rd0j3dQDijO/RqpxGc2oaHKMaZiWaYR5EevA5Ei 2aACXrd4kqnMUCYCFAo+LloDeYCGSaROk54XmmlEZCJDaAdWS2X2mC6dXcVSzRmkw+Iy 6mM4wJyxe7dXdQmaGNJxSn3kI/WPOH8CmK6x4uUapZDTA0UnAlkJboWe0PVj5LbrCztF moNmKAUnbbFqWb3TxwpFHRsu+jrPkXi7f5YSnAObyVqENkynYES578PzidQkquWSFb0n 3pEw== 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=tkBwIJTqxcFCA7D9/JKxQNFcqwhrm54MhgM//0OcaDI=; b=Ifc83yYKjMDI3X31NCTDI6uNQrB/qaRY6RvXtuqryIAk7nJ81XuQ/SQa/lvBUFfdm8 xMJCy3kVjQXgHYnv7bMaz4YncaUImMWbvsGfec3KhGh81bU+Hsu/AWiUVBD1CHANkvu9 nXeoAkAcyCDQTuOD7yGsfeir/yr5IUH98hl0jD2y6ttYKCP4XSIasCD0qZvCLDmpSz4d U9BoG0tiB1v7RlHRovEXR1oUmAn3bhwnJTLsawa1Hk1O4MBWimZLJpoMnFFu0K7wllfI N0zxf3L2OFZdymXRvUZHJQN6CdYhxFCM/KFmtRSpOJFtvDvQg+anWt7w6SWvY8XfGGY9 tYUQ== X-Gm-Message-State: AOAM532JyQCmAg9z6uxyJoTyv1guBdzC81zjmx9hZtKycz4HBB279DRk +e0DubsRBHDna1sWpmuqx2ld+KI+ X-Google-Smtp-Source: ABdhPJx6yb/BGz5ERN8kSz0z2+DNqfbJuvkMzrN1P9HCbgckhYQ366jzqh1SZWm/mkTgYAvv7ZV7Lw== X-Received: by 2002:adf:f08b:: with SMTP id n11mr27904754wro.312.1593644261549; Wed, 01 Jul 2020 15:57:41 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id r10sm8816972wrm.17.2020.07.01.15.57.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2020 15:57:41 -0700 (PDT) In-Reply-To: <83mu4m0vub.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=raaahh@gmail.com; helo=mail-wr1-x436.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:252619 Archived-At: Hi Eli, On 29.06.2020 17:50, Eli Zaretskii wrote: > I didn't mean to ask you to change your priorities. I was only > talking about the design of deciding what buffers belong to which > project, and the implications of that design. If you recall, I even posted a "more correct" patch a while back that wouldn't make the choice of which buffers belong to the project depend solely on the value of default-directory. >> I think it's an objective summary. Because you said that not having this >> capability keeps Emacs at a severe disadvantage to other editors. So it >> was clearly a subject that required analysis. > > Once again, my problem is not with the schedule of providing the > support for the use case I described, but with the current design > which AFAICT makes it hard to add such support in the future. We > should modify the design to make such use cases easier to add. ...and I asked for design suggestions that would make the behavior better from your standpoint. Some ideas, old and new: 1. We can call 'project-current' in every buffer, and then compare the returned values (this is what that alternative patch did). But recalling bug#41029, it seems some users can have outstanding numbers of buffers open, and this approach might heavily limit the performance of project-switch-to-buffer, unless we employ some very heavy buffer->project caching. And I'd really like to stay away from manual cache invalidation. 2. We could call 'project-files' on the current project and compare the values of buffer-file-name of every buffer. This could become slow with larger projects. And the complexity will be N^2 (at least with naive implementation), so it can be worse than project-find-file for those projects. Also, this doesn't solve your problem with Grep buffers. But it would help in the situation of having a project contain arbitrary files from arbitrary directories. 3. Create a new generic function (or several) which would delegate the inclusion logic to individual project backends. This would require work on naming, semantics, what have you, and would likely still come out clunkier than either of the previous two options. Further, with this approach, I'm still not sure of a good "fast" solution for project-vc which leads to correct behavior in the presence of nested projects. >> The model that other editors use, and the one I'm assuming you do as >> well (guessing mostly due to how tags' UI works), is that you work only >> on one "project" (in your sense of the word) at a time. >> >> Then, would I be correct to assume that if there exists a Grep buffer in >> the current session, then it mostly likely belongs to the current >> "project"? If so, would there be any particular advantage to using >> project-switch-to-buffer instead of plain switch-to-buffer? > > No and no. My Emacs sessions run for many days on end, and during > that time I work on several projects. Sometimes I need to switch > between them every few minutes (e.g., when I read my email and need to > answer questions and request, or review code, related to several > projects, in the order in which I read the incoming email). More > often, I would work for several hours on one project, then switch to > another, then to yet another or back to the first. I see, thank you. > When I do switch, I don't want to lose the "payload" of the project I > switch from: its files, its Grep, XREF, and Compilation buffers, its > documentation buffers, etc. -- because I know I will come back there > in hours or days. This means each project should stay readily > accessible, so that I could pick up where I left off. > > It is true that the last Grep buffer I created most probably belongs > to the current project, but that doesn't mean I want to give up the > previous Grep buffer -- I might need it shortly. What I meant, would there be a lot of downside to using switch-to-buffer specifically to switch to file-less buffers such as Grep when a need arises. This way, they wouldn't be "lost", but you'd have to deal with filtering through many buffers. Even so, Grep buffers are usually named uniquely, so it's unlikely to be a total disaster. And you wouldn't be able to clean then up easily with project-kill-buffers. Anyway, I'm talking about the backup plan here. One to consider if we don't manage to settle on a better approach. >> I never said that it's an ideal method. And I'm sure there can be >> problematic examples out there. But I wasn't convinced by the example >> you gave because the reason for why it was bad was based on your >> understanding on the word "project", and not on mine. Thus, it's hard >> for me to choose a good solution for the project backend which is based >> on my understanding of the word "project". > > I'm not asking you to come up with a backend suitable for the use case > I described. I'm asking you to take that use case into consideration > when you design the means of deciding which buffer belongs to what > project. If we design this decision in a way that cannot be easily > extended to reasonable use cases we can envision, we will limit > ourselves in the use cases we can usefully support, ever. Let's try > to avoid producing such a restrictive design, if we can. Sure, agreed.