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.bugs Subject: bug#48747: [SPAM UNSURE] Re: bug#48747: add project-name generic Date: Tue, 22 Nov 2022 04:41:06 +0200 Message-ID: References: <86eedoi0jw.fsf@stephe-leake.org> <86o7t1l18h.fsf@stephe-leake.org> <9b4aded1-5dda-25c8-8144-71aa9727353c@yandex.ru> <86bkp0kubq.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13493"; 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: 48747@debbugs.gnu.org To: Stephen Leake Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 22 03:42:20 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 1oxJEq-0003Jb-Er for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Nov 2022 03:42:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxJEa-0001Wd-Q4; Mon, 21 Nov 2022 21:42:04 -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 1oxJEZ-0001WH-D5 for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 21:42: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 1oxJEZ-0005o4-1e for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 21:42:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oxJEY-0000Ou-UM for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 21:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Nov 2022 02:42: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.16690848771485 (code B ref 48747); Tue, 22 Nov 2022 02:42:02 +0000 Original-Received: (at 48747) by debbugs.gnu.org; 22 Nov 2022 02:41:17 +0000 Original-Received: from localhost ([127.0.0.1]:49280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxJDo-0000Nt-RN for submit@debbugs.gnu.org; Mon, 21 Nov 2022 21:41:17 -0500 Original-Received: from mail-wr1-f43.google.com ([209.85.221.43]:38724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxJDm-0000Ne-Tp for 48747@debbugs.gnu.org; Mon, 21 Nov 2022 21:41:15 -0500 Original-Received: by mail-wr1-f43.google.com with SMTP id n3so6133131wrp.5 for <48747@debbugs.gnu.org>; Mon, 21 Nov 2022 18:41:14 -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=Cu2ADtqert00+GvqSrya0IhuU1YpLCAvsDMPMKts51w=; b=DYMmlbMHMOvNdN/sk3A66lM3N5TzhFvz/gue5zMLyrv0pXFPb7CGfhCZ0dmFXf0g6D zdi3aryLZ13tR4uslKVkfQLkCJA3/o1EwE5VnoGsynfunrvB4P4tfIhVWPti1ELmTetQ fCgu88sDOtjhc5Mz/k+c5uXQ1FRMYHhPODRfElaOrLEY4E5GESQamV1upu6AKWUBwIxL lXODAoLETiZtkU6m2V5i0EiBLy/GiwFZnRR1lVoUpsDu9gxA3DHXcsTQvEzOeOqduNJg cUcWFRSNivzi5XDuOUJXY/uHEggpMI4IF/RFxAkAuVZho74Fhnl1ZvGnO5JHnaG77uu8 g/9w== 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=Cu2ADtqert00+GvqSrya0IhuU1YpLCAvsDMPMKts51w=; b=2+9Z6WwcpFbe5WEHzyKdM0wCF/slKiiDf1DAJVWpnvtxBwpV4iaRgwf3EABWRovom2 phLajM5IDXHy14kXOLdfAZwgWb/WFvJwCcy0jc/u79tWbSofJtXgVsSBreYqgzyn982A F12288Ft6r85QgKWadsUuNONAGi+5dzFpI6oMp5xl2gWdqugLi+eq8i9Es1TyD4xlwyi D4Vsq42wCi4fqqkofXUxO7L+yUhcQrV0Gwl6QQQDO549Q30OckHzvoS9js6YT7OmoDFX nxvI5JTQYq4naLocmOJu0WGdLMZwERagm0NG3/3yb8+wFbeMenFkWTt3OllHNKISoPeB js3A== X-Gm-Message-State: ANoB5pk4HaxewZTD1jZUPVxDCpYQPZL6BepTqkZt5WIfvVMaHX2XG3FW wMP56Q3HKZ/6HLcVg0l2Ms4BkrPvrio= X-Google-Smtp-Source: AA0mqf5q1Os96V/mPAfWYI9beADmofqEA7/5FUVt6dxXScQ+icLd/k/cAfsFuTvjVPMBwUheAYEKPA== X-Received: by 2002:adf:f84e:0:b0:22e:46be:5bc9 with SMTP id d14-20020adff84e000000b0022e46be5bc9mr13537191wrq.378.1669084868668; Mon, 21 Nov 2022 18:41:08 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g18-20020a5d46d2000000b00236722ebe66sm12522825wrs.75.2022.11.21.18.41.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Nov 2022 18:41:07 -0800 (PST) Content-Language: en-US In-Reply-To: <86bkp0kubq.fsf@stephe-leake.org> 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:248596 Archived-At: On 21/11/22 20:59, Stephen Leake wrote: > 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. I guess what you might be saying is that the file contains directories and not project instances. Thus, going to the project name is a non-trivial transition anyway. And for the whole list, potentially costly. > 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. That's a problem: if the default is nil, then for every project the user will have to customize it somehow. Otherwise the method is not going to be usable. That's not a great workflow from my POV. If the place where you want to use it in Eglot, currently calls (file-name-base (directory-file-name root)) then that is probably the best default after all. > 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?). Abbreviate or not is a minor detail. Not too important for project-prompt-project-dir, but could be more valuable in other potential places, such as mode-line, which value compactness. >> 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. That answers my questions, thanks. > Transient projects could also store a name as a plist entry in the > project object: '(transient /a/root/dir :name "wisitoken main") Yes, but, for a transient object, there's nowhere to get the custom name from. The user just chooses a directory. Anyway, I think we can proceed with your original proposal (where the default name is the base name of the root directory). Some users of project-vc backend will probably want to customize it too, we can add a buffer-local variable for that (now or later).