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: Eglot, project.el, and python virtual environments Date: Wed, 23 Nov 2022 02:03:57 +0200 Message-ID: <0024a67d-b8e5-b35c-1b22-82541a170eb3@yandex.ru> References: <87zgcq68zp.fsf@ericabrahamsen.net> <878rkale3l.fsf@dfreeman.email> <4c5f4b07-3df6-d700-83f8-9a9d1b684afc@yandex.ru> <84781346-5b88-2be5-38bb-02696fcf1364@yandex.ru> <87o7t2vj19.fsf@dfreeman.email> <877czqtyfy.fsf@dfreeman.email> <87zgcml7g7.fsf@gmail.com> <2ba04533-097a-a1da-ff3f-2c9506fd488e@yandex.ru> <875yf9bbzb.fsf@gmail.com> <87wn7oa0aw.fsf@gmail.com> <7a5b76fd-fb15-8c1e-ea29-bf11f7e0d2ae@yandex.ru> <87bkoya815.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18179"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: Stefan Monnier , Danny Freeman , Eric Abrahamsen , emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 23 01:04:50 2022 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 1oxdFx-0004XA-EP for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Nov 2022 01:04:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxdFO-0006vm-TD; Tue, 22 Nov 2022 19:04:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oxdFE-0006sy-AK for emacs-devel@gnu.org; Tue, 22 Nov 2022 19:04:05 -0500 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxdFB-00018O-O5 for emacs-devel@gnu.org; Tue, 22 Nov 2022 19:04:03 -0500 Original-Received: by mail-wr1-x42f.google.com with SMTP id l14so8289839wrw.13 for ; Tue, 22 Nov 2022 16:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=+rDot6Yb6x7bYl+KzP2Of1/BP5D2Qvy8yrhHvoqp+Y4=; b=VhSQKRPzvcybHa93ozpe99HLRmM5boAOKaIEkf3e/casueP6PLQF+8uWum9QbcGaiV BO3lztaGV6dZpKpE6ZMjuE8sY/RoNuht+On/HRgtQVWYExRz89AjZ+gw92vBjdVBQzDa UnIFu0gCSVV/blTvuDXcllR7ofCm4PucOj09bOmSQZ2qKaVJcfBz2muJT3x/QeZBEpBV 51w7tv7daBOCKVHIOL7MOnrh+MldexFaStsYNuuIaAieTOljXo4y4s0/U8zr2hQkNpH6 8wuHKSFQfOT1kQ1dZUT+ms/GQTCw1lKzL1Fr1B6nTYQnOSRqmsfWlbXn3AxB17Mp0B+U Ol2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+rDot6Yb6x7bYl+KzP2Of1/BP5D2Qvy8yrhHvoqp+Y4=; b=C9kyYpz4KVneKg65x5HFfs4vVxXFPJ8S3hySjnT93FmMKcF+kl2Cans5/j//nckBnd zuK9PUNi/B8w+3TMwFc4gHUUJ2VP/0vKgXi1X1fuwTWo5KYkcRvTnZX4R07BIxCwM4DW Itqn7mJuIiqPdh2XiaWMUwSX1t5ZO2ifS7pIjr4+h/rQFd9AsI0cuVnE0nI1h4dM1uqf qbV9aMLq90HIR60/L5lie8D/V8f9Hs5s6IV2srT057MOztOogGASmSg31oXbfaxrYKrY FbhPNTH26lBK0f1S9uCRr/gB4hxWFN5BaDVq3S2yi9RBaB0+fyJ7ykGugfCbzt+yICCT v37A== X-Gm-Message-State: ANoB5pmjSiQ96+w/uHvinPUAd+GZzEYH806FJpdU5u/ftZ+/GDIuhKRu O6xFHvQ5IwKQd4abAS5Xye8= X-Google-Smtp-Source: AA0mqf4vZdCYCWNCRzbIBulW+9/qy3JwP1feMiuGSalHNgnsK4Iy46fYKjnFjyYvWwWGQd0yqQBImA== X-Received: by 2002:a5d:5914:0:b0:236:57f3:c9e6 with SMTP id v20-20020a5d5914000000b0023657f3c9e6mr15452325wrd.21.1669161839831; Tue, 22 Nov 2022 16:03:59 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m66-20020a1c2645000000b003cf9bf5208esm308059wmm.19.2022.11.22.16.03.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 16:03:59 -0800 (PST) Content-Language: en-US In-Reply-To: <87bkoya815.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42f.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.205, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300364 Archived-At: On 23/11/22 01:23, João Távora wrote: > Dmitry Gutov writes: > >> On 22/11/22 23:34, João Távora wrote: >>> Given a tree a tree structure such as a file system that can have >>> very many nodes, not having any means to take advantage of that structure >>> tree-ness (as project.el clearly doesn't: see the protocol of >>> project-files and >>> the lack of sub-projects) is going to be a hard limitation.  Monorepos >>> are really popular in many businesses and many of these are large and/or >>> getting larger. >> >> Like I said: if you want sub-projects, go and write a proper feature >> request, with expected behavior, which commands are affected, which >> are not. > > I've just described in the other thread that I would like to have > finding references and finding files to be able to operate on either > sub-projects or super-projects on demand. This is the problem I'm > facing, and it's not new. For example, there is only: find file in the > very large project, and find file in the current directory. There is no > "find file in this section of the repo, which is a sub-project in > itself". It would be much more helpful in a dedicated bug report where we could discuss the details, collect the votes and see what kind of design will ultimately satisfy the requirements. Instead of drowning it all in this thread, which is only moderately related. > IMO, it's not "improper" to describe problems and use cases: in fact I > prefer that people describe over jumping to vapourware solutions. But > if you're really looking for a suggestion as to _how_ to design it, I > suppose my problem would be well dealt with a negative prefix on C-x p g > and C-x p f giving me a choice of which project to operate on. But that > is only one possibility: new commands are also acceptable. Note that you can more-or-less do this now: press 'C-x p p', select the parent project from the list, then choose 'f' or 'g' to run the command there. So to justify the added complexity one should say that they do want to use this feature frequently enough to justify the added complexity (which will reduce the number of keystrokes). And even if we do, we might not need the additional notion of sub-projects. E.g. 'search in the parent project (if any)' might work as "take the root, go up a directory, search for a project there; if it exists, use it". Though Stephen L. might want a generic for that, since his projects do not correlate with directory tree. OTOH, if one of the operations will require a step "get all subprojects of the current project", then a separate notion might be required, with a separate hook. > As to how one defines sub-projects, I think having > project-find-functions be used to compose a list of projects (as opposed > to to stopping after finding one) would be a nice way. It would be nice > if the elements of project-find-functions could be informed of the > projects found so far. But keeping the "stop after first" behaviour and > having members return a more complex object is maybe also good. I > really don't care much what you eventually choose, as long as I can > solve my problem. If we wanted to define projects and subprojects through the same hook, the step "get all subprojects of the current project" might not be feasible to implement. Because of performance-related considerations.