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: Tue, 22 Nov 2022 17:48:39 +0200 Message-ID: <7a5b76fd-fb15-8c1e-ea29-bf11f7e0d2ae@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> 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="27956"; 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: 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 Tue Nov 22 16:49:27 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 1oxVWZ-000773-KJ for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Nov 2022 16:49:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxVVu-0002KV-Qj; Tue, 22 Nov 2022 10:48:46 -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 1oxVVt-0002J3-EI for emacs-devel@gnu.org; Tue, 22 Nov 2022 10:48:45 -0500 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxVVr-000804-JV for emacs-devel@gnu.org; Tue, 22 Nov 2022 10:48:45 -0500 Original-Received: by mail-wr1-x42d.google.com with SMTP id b12so11545413wrn.2 for ; Tue, 22 Nov 2022 07:48:42 -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:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=sdFTmAie5zUztk2eKxkGdQZ5TpHRxpAGoRZ//XqBJSo=; b=GPfP02S0MVuzLi7mNT28AhMFDtUb8MZ8lIcbV5RvH6vxYO0Mn72uV+Ohafq3VhCzvM D7jrOzIFelAWUZtMdqsONQ9isFgyde15NVmWcryznLr63OmRFBBaxHbxhlNeDyp5cqjL UhUcxLuUgsjEi42vF4TPi9Hktl2k2XY5ssDoNsqoy3NUK+pw+EX0zqHDzDSS89zyY/V4 O1fguvbgwYRkIG/4TL3Aj0gjhusct3++EIOXxRWmc3lnLw9lSWubUEZLkORgmOkOrvna qK92KJjhFsMn0OC8KZOf5sZ6HYQDmwUxA+Lz7uVchDEwmC9NMPXfSSkzCIBPCZpY08S7 BT5g== 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:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sdFTmAie5zUztk2eKxkGdQZ5TpHRxpAGoRZ//XqBJSo=; b=iiicvRPS7alKSnzRGGIvTeiEUC/GmEW+x9T6On+tpj7gJidr2K/tkz/fxRNbHBAQ/O hYkLHxg0HGkWa/vAsHDTiRIbWQ9lhKztGgHWSZ31yLIS+Ue8rpPZpLybM9fYYBmir7xA GiuDByt1kYZGxcZZdPirUYE6qEdRkQK/kgNvwrIZTRaIkEq53B7IC2vgbfYLO4sjxMx5 wSuXmqT3L9fsobXliWHw1ANOYazZWMsZZVWn3R9u8CppTP+vr9WguI7wJEaxM0kHuqAY 0QsZjfzVZUIp7HI7lsE+W/GrR07DLh7ht1rGRgVcA2Aqr22vW17uTj2axll4o+v83RF5 S5Sw== X-Gm-Message-State: ANoB5pmITguATHF9ahZ4YK1cG+Ka7osXmILxet3Qst0D1sYqORYzhImv eGyW+e0OzPebcS9Qs55tVhA= X-Google-Smtp-Source: AA0mqf6HBuxx/YwEbtta3EP4v6tdiP3VdknjS+IGyWHnWEpjy9FkKLscRFKc7JF5S9XCIP2QglJrCQ== X-Received: by 2002:adf:bc12:0:b0:241:bc6a:ceb with SMTP id s18-20020adfbc12000000b00241bc6a0cebmr13649599wrg.514.1669132121502; Tue, 22 Nov 2022 07:48:41 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id p2-20020a1c7402000000b003cfe6fd7c60sm17308229wmc.8.2022.11.22.07.48.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 07:48:40 -0800 (PST) Content-Language: en-US In-Reply-To: <87wn7oa0aw.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::42d; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42d.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:300338 Archived-At: On 21/11/22 15:45, João Távora wrote: > Dmitry Gutov writes: > >> On 20.11.2022 22:35, João Távora wrote: >>> You shouldn't be writing performance off as a detail. You can't just >>> wish it away, or think users will change OSs soon. You should instead >>> think of solutions that help manage size and complexity. >> >> No, I'm saying performance itself shouldn't sway the decision in this >> case one way or another. > > I think I couldn't disagree more. If there something that should > influence system design (usually as early as possible) are performance > considerations: they can't be an afterthought. That said, looking > forward to these "other means". Performance is important, but desired behavior comes first. >>> But it's not just performance. For example, in this particular project, >>> it makes sense, by default, to grep the superproject, but C-x f in the >>> subprojects. Lack of subproject support in project.el means I have to >>> work around this with defadvice. >> >> Perhaps in your particular project it makes sense. Most of the users I >> see in this thread seem to prefer it otherwise in their projects. >> >> So that seems to indicate that the Eglot fix and the subprojects thing >> should be separate, implemented without tying one to the other. > > Certainly shouldn't be "tied" to the other, but if subproject > configuration becomes available in project.el, Eglot can easily take > advantage of it (perhaps even automatically). I cannot reasonably add a feature with only one known (and expected) consumer. Whether we call it subprojects, or an eglot-only backend, or etc. FWIW, "subprojects" that I can imagine would probably be implemented as a new hook or a list of "project markers". As long as only Eglot uses it, it might as well live there. > As the Eglot "fix" for the current status quo, it's just a > documentation change to the manual. I think it's a problem when a significant part of userbase need to make a change to their config (a specific, non-trivial one) to make Eglot functional in their projects. I sympathize with not wanting to collect that info for every file type and their dog in Eglot, but it's not 100% obvious to me that the place for that info is in major modes.