GNU bug report logs - #41821
28.0.50; read-directory-name in vc commands should provide defaults from projects

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 41821 <at> debbugs.gnu.org
Subject: bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects
Date: Wed, 1 Jul 2020 00:59:59 +0300

On 30.06.2020 23:50, Juri Linkov wrote:
>>> Note the same prefix 'project-vc' for vc backend of project.el.
>>> Then 'project-vc-known-roots' in project.el be like this:
>>> (defun project-vc-known-roots ()
>>>     "Return a list of known vc roots."
>>>     (seq-filter #'project-try-vc (project-known-project-roots)))
>>
>> You suggested this before. Special-casing a particular backend in a general
>> purpose public function is not a good idea.
> 
> It's not a general purpose function.  Its prefix 'project-vc-' indicates that
> this public function is specific to project-vc backend.

An yet, its purpose is general. If it were to be used ubiquitously, it 
should remain useful even if the user employs other backends, not 
project-vc.

>> See, even when the project backend is VC, there is no guarantee that its
>> root will be the repository's root.
> 
> Isn't the project's root the same as the repository's root in 99% cases?

This number is going to get lower in the future. Because of the examples 
I cited, and maybe others.

>> First, there are submodules (and whether a submodule root is a project
>> root is customizable).
> 
> This is a general problem currently discussed in other threads.

I don't understand this response.

>> Second, there is an existing feature request to use also some other
>> project root markers, even inside VC repos (the "monorepo"
>> case). These might end up in the 'vc' backend as well.
> 
> I don't see how is this related to the subject of this bug report.
> It's not a big problem when some directories provided by M-n
> are not repository root directories in 1% of cases.

It is related to the sentence I wrote above it in the previous email. 
And it's related to your estimation of "99%".

>> So things as they are, I'd rather VC has a separate roots history,
>> or we at least put this feature request on hold (and, for now, revert
>> the installed patches).
> 
> Look, what I'm trying to say is that there are users who want
> to use project directories from ~/.emacs.d/projects in vc commands.
> Of course, there are users with no free memory available that can't
> afford loading project.el to the memory.  Addressing the needs of users
> who don't use project.el is a separate issue.  But in this report
> I'm addressing the needs of users who want to use project.el in vc commands.

The question is whether it would be better done in a different way.

And consider: okay, saving a separate (partially duplicating) list in 
~/.emacs.d/vc-roots sounds somewhat of a hassle, but from the user's 
POV, they will enter a repository root directory one more time. And from 
then on Emacs will suggest it from the saved list, and all will be well. 
 It could even be memorized automatically most of the time, similarly 
to what you suggested in the previous email.

And in the cases when a project root doesn't match the repository root, 
this alternative solution will result in better behavior.

> Also I'm sure that most users will want to use project directories from
> ~/.emacs.d/projects not only in vc commands, but in more places for
> non-vc commands.  Here's a similar patch for grep commands:

This looks like a substitute for a 'project-grep' command, right?

But if Eli thinks it's good, I have no objection. Note that the 
tradeoffs are different in this case: obviously, there's even no need to 
filter by #'project-try-vc.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.