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: Add cl-defgeneric project-name; first use case eglot Date: Wed, 23 Nov 2022 04:34:19 +0200 Message-ID: <0d0c80fa-7db1-be68-0dba-a9dd466d34d5@yandex.ru> References: <86zgcll1le.fsf@stephe-leake.org> <83a64k4fru.fsf@gnu.org> <87h6yrxqga.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="19344"; 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: Stephen Leake , emacs-devel@gnu.org, joaotavora@gmail.com To: =?UTF-8?Q?K=c3=a9vin_Le_Gouguec?= , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 23 03:35:46 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 1oxfc1-0004ok-Sh for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Nov 2022 03:35:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxfb4-0001Gr-AJ; Tue, 22 Nov 2022 21:34: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 1oxfal-00017R-Qw for emacs-devel@gnu.org; Tue, 22 Nov 2022 21:34:43 -0500 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxfaj-0007Zm-98; Tue, 22 Nov 2022 21:34:27 -0500 Original-Received: by mail-wr1-x42c.google.com with SMTP id d1so15362764wrs.12; Tue, 22 Nov 2022 18:34:24 -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=ww2/+GrT/wtZKMadLZZbnR9yOqW+Ro20OQX+XpzhxAU=; b=e6OcTTy5Te64n7RymhbtbSUyeZaWzMBgCH4z6B/sw9h5AV1o+C14hrCk83NE0c4i0r knh6tNk33Ba8mT9l1KZGRivMgaSmaLKSrOnpJZsS9/6zfJ8Q3oIn6lJAneNPF/g3HMUw ZVAMAAHqJakmla6Do/2zcy0/Ouz7kxwwzGZP0D+mCDeJu/BsN13Mu22cbj0Fz8JCpTc8 abqUzzR7N+3V83e8i+0fjUbAU86ktF7sh9M4C7pGUQ74NiduaNfulro2fv+f5cxpJsLE /q2yvLUQfT4IuogJU3DhL5r0gCL8dCN+g9hBUandTS6i6jZR/jxjOtZAghLt+ccZmCjo jTOQ== 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=ww2/+GrT/wtZKMadLZZbnR9yOqW+Ro20OQX+XpzhxAU=; b=LfqjpqIMBPmRQuPjWLTZ9yD3KwRrtV6Bx0U4+XCEmIPlRHnLD5h/KP4IEYvxmg6GnV 0MMVGHoUkocSC9Wk5/5B/KsGWDMyJ3I/ZgUaygIxNJXiXG09tiTngNIanbrdpmbE127u REeW3SCw0/CRC7VtmNBXwAULxUz0HJm8fSCEPTTqFv9uCn+QmLv6cm11phe880q2GTJk mT4KqzkGLjWi9GAAdvkaBnLn1f+JQ6nUuza3o+rx0EXFFCTIrMbvriwyBvf55xrjiVOe 7VcXl5v9eTx5UlwXDYf4USKdtM8PeLR3hhYhhol5aE9VSYIkaFC8pDS7q7i7iTlgozMV cFuw== X-Gm-Message-State: ANoB5pkbDwkaJdQXuyJkIeFwHoXwan2+wUy8rTljOrlvjCWkyEb/2eJ4 2mM6oJ1MXaMDaaZRUjZmcHA= X-Google-Smtp-Source: AA0mqf6TncjFGqNtMnn1C6CLR4l0okeMokJAXI5TrbG4YOZPCMIyqG6qoC4rK5IZHar2AYAm2yMYPA== X-Received: by 2002:adf:c64e:0:b0:236:78cd:f3d2 with SMTP id u14-20020adfc64e000000b0023678cdf3d2mr16342732wrg.719.1669170863105; Tue, 22 Nov 2022 18:34:23 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b5-20020adff905000000b002366fb99cdasm15451848wrr.50.2022.11.22.18.34.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 18:34:22 -0800 (PST) Content-Language: en-US In-Reply-To: <87h6yrxqga.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42c.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:300374 Archived-At: On 22/11/22 11:56, Kévin 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 backend 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 an alist value, associating root dirs with names. > (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… > > 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 instances 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 possible to skip those when computing the names. > (2) I'd like to be able to give nicknames to projects. I could make > project-prompt-project-dir use the flex style to match e.g. "fts" to > "foo-testsuite", but I can think of other nicknames that wouldn't match > (e.g. "xfoo" for "cross-foo"). > > (3) I'd like to stick (project-name) in my frame-title-format; currently > using "(file-name-base (directory-file-name (project-root > (project-current))))", but my lack of creativity in worktree naming is > biting me in the rear ("ah yes, the “master” project 😐"). > > Granted, I would still need to come up with my own logic for more > informative project names, but at least I could keep it separate from my > frame-title-format logic. E.g. if I had different project-naming > conventions for $HOBBIES and $DAYJOB, I could keep frame-title-format in > sync everywhere, but give different machines different project-naming > code. > > Granted², I can already define my own indirection layer today; I don't > need to wait for project-name to be introduced. > > (4) Similar itch with Magit buffer names: > > (info "(magit) Naming Buffers") > https://magit.vc/manual/magit.html#Naming-Buffers > > Being able to stick a (project-name) in there (or a "%p") would be > convenient, for the same reasons as frame-title-format: use the same > Magit buffer-name config everywhere; keep project-naming logic > "workplace-bound". Cool. Hopefully the performance of 'project-current' won't make any of these applications unfeasible (like the mode-line which has to refresh after every change in any buffer, every keypress, etc). > 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 way to specify the name. So we don't have any global vars which affect what all projects do.