From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= Newsgroups: gmane.emacs.devel Subject: Re: Add cl-defgeneric project-name; first use case eglot Date: Sun, 27 Nov 2022 19:47:05 +0100 Message-ID: <87pmd8i6ae.fsf@gmail.com> References: <86zgcll1le.fsf@stephe-leake.org> <83a64k4fru.fsf@gnu.org> <87h6yrxqga.fsf@gmail.com> <0d0c80fa-7db1-be68-0dba-a9dd466d34d5@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7894"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Stephen Leake , emacs-devel@gnu.org, joaotavora@gmail.com To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 27 19:47:53 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 1ozMgz-0001rZ-2c for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Nov 2022 19:47:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozMgN-0000rA-N4; Sun, 27 Nov 2022 13:47:15 -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 1ozMgJ-0000pb-NS for emacs-devel@gnu.org; Sun, 27 Nov 2022 13:47:13 -0500 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ozMgH-0004Qg-Qz; Sun, 27 Nov 2022 13:47:11 -0500 Original-Received: by mail-wr1-x42e.google.com with SMTP id d1so13688653wrs.12; Sun, 27 Nov 2022 10:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=e+U6mbl4fZlMk2jYW7nkSdnnYNB+moI/74m6TW9KdqE=; b=a2WGMWYvKuCqq8G6r8TCnu1SVrjvt8lYDJdHVIQtt5ZC06zJkd+VRXd1+t7qVSbDoB PA6sVN5ipPtDcsKKWMNpSRQYQa5h4AVBQRpPZklXArheotby3GSWUu8tnH7p7T98WhHs X963aVFQYKqRZtZ4DbgmUZWi159Zi2GPK3rXHfDnlDg1L14YxG/JzqJsT5o9ayE9Nf5G 7k7HIm7uTz4vcgiSwVTPXpg38CEcFvAcdfi3sS+bvhk7v3YfIrj1tNJJwyi2E87RkAU7 RFxrjg7+Lf/8xk8I6tGVzb6JjUITc/tzbXgfJ9CnRvdNu2RcbAho3QWThJ6ZAaOZb1sz SIHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=e+U6mbl4fZlMk2jYW7nkSdnnYNB+moI/74m6TW9KdqE=; b=arlslqOyv1KaBvbOPyI5icAQKifPiivSshZKWDI1q16yBScfZigpuV5ZTnQtuBIT9P R8IztjQA8VwJuTcvt+fgPsdY5ahysAyv6BDJZzjLmi54ieEd7xBsCUsy4Ur2K5jf2deg mLVpJzbUNiB867uVeUpb/TKU0tpRqs9ftnQt23anXyjBqrr6LI1SR52RTl0PtR+IxF22 c2D5NDTdDxLIe29Yz3A+lQhhQvSayhtsQIqrr5JtxLDgPGOO7+gS1zqaZtbH0OuaZxIM 0Ks4DQx/xsVFN3P26W4Gi9qa/eLOQi82FOK3x2T9gMrS77Odk6id870Z5XtYQUKmwmct eDng== X-Gm-Message-State: ANoB5pmbuPn5Rai8NpRXCt/+2GG/y4p19yA3aZP8HzJVY5TykTcOemQR UAUN8W1ntWMzuOVeljS9JHk= X-Google-Smtp-Source: AA0mqf5S6XG2/wBMqWn15GGxRX53Al2LHpYTFu2+VPKl0suXjSM4p610xLWV01meSfTMzv1T8uPOPw== X-Received: by 2002:adf:fd04:0:b0:242:1888:a017 with SMTP id e4-20020adffd04000000b002421888a017mr425331wrr.273.1669574827395; Sun, 27 Nov 2022 10:47:07 -0800 (PST) Original-Received: from amdahl30 ([2a01:e0a:253:fe0:2ef0:5dff:fed2:7b49]) by smtp.gmail.com with ESMTPSA id t6-20020adfeb86000000b00241e5b917d0sm10272130wrn.36.2022.11.27.10.47.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Nov 2022 10:47:06 -0800 (PST) In-Reply-To: <0d0c80fa-7db1-be68-0dba-a9dd466d34d5@yandex.ru> (Dmitry Gutov's message of "Wed, 23 Nov 2022 04:34:19 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=kevin.legouguec@gmail.com; helo=mail-wr1-x42e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:300639 Archived-At: Dmitry Gutov writes: > On 22/11/22 11:56, K=C3=A9vin Le Gouguec wrote: > >>> I don't see why the needs of Eglot usage justify another generic in >>> project.el, or should be solved in project.el to begin with. If Dmitry >>> wants to add such a generic for his own reasons, with some future >>> development of project.el in mind, I won't object, of course. >> FWIW, being able to tell project.el "this project is named foobar, >> nevermind the path" would help me in a couple of situations: > > I have just added (efe599df3127) a way to set the project name for VC bac= kend > through dir-locals. > > Not sure if this way will be to your liking, but it's the most > straightforward. Though I suppose we could also make this variable take a= n alist > value, associating root dirs with names. Thanks! So to recap, IIUC now users have a couple of ways to control how projects are named: (1) Coding up their own project-name defmethod; AFAIU this is what Stephen has in mind, when he talked about overriding the default implementation? Not very familiar with generic functions yet, so currently going through "(elisp) Generic Functions" to better understand the mechanics. ( Thoughts after experimenting for 5 minutes: my first instinct was to specialize methods by regex-matching on (project-root project), but that doesn't seem straightforward to do. AFAICT the defmethod ARGS are not in scope when &context EXPR forms are evaluated? So I can't use &context as an "escape hatch" to string-match-p on (project-root project). IIUC I could define my own "regex" specializer with cl-generic-generalizers? No idea how judicious that is. ) (2) Through the project-vc-name variable you introduced, using either .dir-locals.el files or directory classes. (Neither here nor there, but: I was surprised to see project-name go in master "so soon"; OT1H I realize that some discussion had already happened in bug#48747, OTOH I wouldn't have expected this feature to be committed before the emacs-29 branch was cut, since that pretty much "cements" the current design, to some extent?) >> (1) C-x p p emacs TAB is currently rather crowded, because I stuff a lot >> of things under ~/src/emacs: emacs.git worktrees, elpa.git, upstream >> repos for *ELPA packages=E2=80=A6 >> If I could "name" projects such that only emacs.git worktrees included >> the string "emacs" (rather than all repos under ~/src/emacs), that'd >> make completion more efficient. > > You're welcome to experiment with project-prompt-project-dir's code. But = note > that until now that function didn't require to "materialize" project inst= ances > for every entry, it just works off saved directory names. > > The feature you have in mind seems to require fetching a project instance= for > every dir and calling 'project-name' on it. The apparent #1 gotcha would = be with > remote filesystems where connection is slow/impossible, but it might be p= ossible > to skip those when computing the names. Point taken. >> [=E2=80=A6 KLG: lots of my vaporware elided =E2=80=A6] > > Cool. Hopefully the performance of 'project-current' won't make any of th= ese > applications unfeasible (like the mode-line which has to refresh after ev= ery > change in any buffer, every keypress, etc). Hopefully =F0=9F=A4=9E As an anecdata point, I've had project-current in my frame-title-format for years, with no ill effects. (<87h7vy9wrv.fsf@gmail.com> is the only time I remember experiencing any kind of impact, and you dealt with it swiftly enough =F0=9F=99=87) >> ISTM those look like "use-cases" for teaching project.el about "project >> names" untangled from project root paths. I'd make use of that feature, >> regardless of what Eglot does. >> (Can't say whether a defgeneric is the most suited technical answer; >> FWIW I'd expect my project-naming code to look at various things, >> e.g. the project path, the repo's upstream URL, the current branch. Not >> sure it matters much to me whether we use a defgeneric or a >> project-name-function, but then I'm not very familiar with generics) > > The general design is we leave it up to the project implementations how to > implement things internally. E.g. Projectile might already have its own w= ay to > specify the name. So we don't have any global vars which affect what all > projects do. (Noted; if anything, that's one more reason for me to get around to learning generics)