From: Stephen Leake <stephen_leake@stephe-leake.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 48747@debbugs.gnu.org
Subject: bug#48747: [SPAM UNSURE] Re: bug#48747: add project-name generic
Date: Mon, 21 Nov 2022 10:59:05 -0800 [thread overview]
Message-ID: <86bkp0kubq.fsf@stephe-leake.org> (raw)
In-Reply-To: <9b4aded1-5dda-25c8-8144-71aa9727353c@yandex.ru> (Dmitry Gutov's message of "Mon, 21 Nov 2022 00:57:33 +0200")
Dmitry Gutov <dgutov@yandex.ru> 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
next prev parent reply other threads:[~2022-11-21 18:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-30 17:38 bug#48747: 28.0.50; add project-name generic Stephen Leake
2021-06-07 2:08 ` Dmitry Gutov
2022-07-15 11:48 ` Lars Ingebrigtsen
2022-07-15 13:09 ` Stephen Leake
2022-11-20 22:17 ` bug#48747: " Stephen Leake
2022-11-20 22:57 ` Dmitry Gutov
2022-11-21 18:59 ` Stephen Leake [this message]
2022-11-22 2:41 ` bug#48747: [SPAM UNSURE] " Dmitry Gutov
2022-11-22 19:02 ` Stephen Leake
2022-11-22 22:20 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86bkp0kubq.fsf@stephe-leake.org \
--to=stephen_leake@stephe-leake.org \
--cc=48747@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).