From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.bugs Subject: bug#48747: [SPAM UNSURE] Re: bug#48747: add project-name generic Date: Mon, 21 Nov 2022 10:59:05 -0800 Message-ID: <86bkp0kubq.fsf@stephe-leake.org> References: <86eedoi0jw.fsf@stephe-leake.org> <86o7t1l18h.fsf@stephe-leake.org> <9b4aded1-5dda-25c8-8144-71aa9727353c@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32790"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 48747@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 21 20:00:52 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oxC2F-0008Le-CW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Nov 2022 20:00:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxC1W-0003Vr-Ea; Mon, 21 Nov 2022 14:00:06 -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 1oxC1T-0003U0-Fw for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 14:00:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxC1T-000550-4A for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 14:00:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oxC1S-0000w7-R8 for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 14:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Leake Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Nov 2022 19:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48747 X-GNU-PR-Package: emacs Original-Received: via spool by 48747-submit@debbugs.gnu.org id=B48747.16690571703517 (code B ref 48747); Mon, 21 Nov 2022 19:00:02 +0000 Original-Received: (at 48747) by debbugs.gnu.org; 21 Nov 2022 18:59:30 +0000 Original-Received: from localhost ([127.0.0.1]:48843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxC0w-0000ue-6p for submit@debbugs.gnu.org; Mon, 21 Nov 2022 13:59:30 -0500 Original-Received: from alt-proxy28.mail.unifiedlayer.com ([74.220.216.123]:50505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxC0t-0000uL-6w for 48747@debbugs.gnu.org; Mon, 21 Nov 2022 13:59:28 -0500 Original-Received: from cmgw13.mail.unifiedlayer.com (unknown [10.0.90.128]) by progateway1.mail.pro1.eigbox.com (Postfix) with ESMTP id 694F01003FBBC for <48747@debbugs.gnu.org>; Mon, 21 Nov 2022 18:59:08 +0000 (UTC) Original-Received: from host2007.hostmonster.com ([67.20.76.71]) by cmsmtp with ESMTP id xC0ZozUBN0QBNxC0Zo3KL2; Mon, 21 Nov 2022 18:59:08 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=DuqTREz+ c=1 sm=1 tr=0 ts=637bca7c a=dWLzHQi6WpdymmZIwiVdBw==:117 a=Fln8i1WyhtedwaIJAdHvmw==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=9xFQ1JgjjksA:10:nop_rcvd_month_year a=vvvmwbhNdt4A:10:endurance_base64_authed_username_1 a=vaJtXVxTAAAA:8 a=JZa9GAoKzzdEozJIMVMA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=stephe-leake.org; s=default; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yigsSJR+mZo7oW+FDe8aHYHw7DIq9JYHTWHNgt8LfJ0=; b=A9tcN+XQyJofs4rg7oFkiEKY9H pdzovTt2awFEfFPgpDEOX99zEMJaheqmK7c6L4hsWfGZyDj21FgcW+CH92oX2rHEZno/MDUzKSOfh ULi9XW/NjYKyPWVra91/sm7IrpqYahT9Vw72rm/1g6cP6Zzn2s1eihmR5DvQVUp+3NGCNUC6JJo4d /e/HvgfP9BqBQgojNR1DL0z/bWdY5gLb+c0eksz5pRjsl0H7we/ynYSf6oW2wRnaOOy7vz3xGtRqJ cbFG5RxXk9q49tmS1RutRSY+h55+EHvVdEnmCYsv2eAu6N9e2IO11by40nkR+xH7m9UJlynSwddJ1 nOpR8wMg==; Original-Received: from 135-180-197-170.fiber.dynamic.sonic.net ([135.180.197.170]:58374 helo=DESKTOP-G20DCG1) by host2007.hostmonster.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oxC0Z-002HNs-93; Mon, 21 Nov 2022 11:59:07 -0700 In-Reply-To: <9b4aded1-5dda-25c8-8144-71aa9727353c@yandex.ru> (Dmitry Gutov's message of "Mon, 21 Nov 2022 00:57:33 +0200") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host2007.hostmonster.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - stephe-leake.org X-BWhitelist: no X-Source-IP: 135.180.197.170 X-Source-L: No X-Exim-ID: 1oxC0Z-002HNs-93 X-Source-Sender: 135-180-197-170.fiber.dynamic.sonic.net (DESKTOP-G20DCG1) [135.180.197.170]:58374 X-Source-Auth: stephen_leake@stephe-leake.org X-Email-Count: 5 X-Source-Cap: c3RlcGhlbGU7c3RlcGhlbGU7aG9zdDIwMDcuaG9zdG1vbnN0ZXIuY29t X-Local-Domain: yes X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248570 Archived-At: Dmitry Gutov writes: > On 21.11.2022 00:17, Stephen Leake wrote: > > But let's please go back to my question: could we use the new generic > in project-prompt-project-dir? And should we? project-prompt-project-dir used to chose a project, by choosing a root directory (in project-current, project-forget-project, and project-switch-project). (that's not guarranteed to be a one-to-one mapping, but that's a separate issue). It currently completes on a list of file names. Those file names come from project-list-file which relies on users or clients calling project-remember-project. It might be useful to include the project name in the completion list for project-prompt-project-dir, but with the default implementation returning the abbreviated project root it would only duplicate information already in the completion table. Instead, we could have project-prompt-project-by-name, which would complete on project names. The list of names could also be in project-list file, with a change in format; also maintained by project-remember-project. The functions that ask the user to complete on projects would have to choose which way to do that; there would have to be a project-prompt-style defcustom for the user to set. I think a better design would be for the default project-name to return nil; then project-prompt-project-dir could use names if they are non-nil, falling back to abbreviated file names if the project name is nil. That would allow a mix of named and un-named projects. Eglot could do the same. project-list-file should store the project name. In that case, project-prompt-project-dir could be renamed to project-prompt-project. > If we do, we'll have to default the return value to > > (abbreviate-file-name (project-root pr)) > > rather than your suggested > > (file-name-base (directory-file-name (project-root pr))) That's a reasonable choice; it does not work for the eglot use case. Which argues for the default to be nil. I'm not clear why you want this to be the default; project-prompt-project-dir does not currently use abbreviate-file-name (perhaps it should?). > Would you say you intend to override project-name a lot? I'm not sure what counts as "a lot" here. All wisi projects have a name provided by the user, and almost all projects I use are wisi projects. So yes? On the other hand, I don't have plans to write any new projects that need names. So no? > Or do you want to take advantage of the shorter default name in most > cases? Deriving the project name from the root directory of the project is not useful in my use cases. Abbreviating does not make it more useful; the only useful label is the string provided by the user. And I have situations where the root directory is the same for two projects; for example, ada_language_server has main and test projects. So wisi will continue to store a user provided string in a project object slot; it will override project-name to return that slot. Transient projects could also store a name as a plist entry in the project object: '(transient /a/root/dir :name "wisitoken main") > What do you think about the first option anyway? I don't follow; what is "the first option"? -- -- Stephe