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

[Eli Zaretskii]

> Cc: 41821@debbugs.gnu.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 1 Jul 2020 23:24:19 +0300
> 
> On 01.07.2020 17:42, Eli Zaretskii wrote:
> > Like you, Dmitry, I'm a bit uneasy with mixing the two sets of
> > features.  We should decide on some concept and try to stick to it;
> > right now, it seems to me that we prefer to have specialized commands
> > in project.el rather than inject project.el-specific nits into
> > commands outside project.el, which I think could be a slippery slope.
> 
> In my previous message I drew a line, of sorts, where I think it's okay 
> to suggest directories to search in in rgrep from known project roots. I 
> do think it's okay.
> 
> I'm not sure if I understand your position, because you say you agree, 
> but then make a one-directional statement.

I agreed with your general doubt whether the proposal is TRT.  My
motivation is somewhat different.

> > Why isn't that a better approach?  I don't think it's wise to blur the
> > difference between using project.el features and the VC back-end
> > features that support them.  If someone wants to use project.el in VC
> > commands, let them use project.el commands, not VC commands.  That
> > way, Emacs will know that some kind of project is being worked on, and
> > could offer more targeted support for such users.
> 
> Not sure that's going to result in optimal user experience. After all, 
> simply having a copy of every command, but acting on a project, would 
> make it 2x the number of commands.
> 
> And project-rgrep, on the other hand, would probably search the current 
> project root without prompting. Unlike the proposed change to rgrep, 
> which only makes it a suggestion.

I just fear that this is a slippery slope: we will eventually need to
inject this into many GP commands, "for consistency".

> Another long-term violation of your idea is the default definition of 
> xref-backend-references. It uses the current project. You could say that 
> mixes up abstractions as well, but it's just too handy to implement this 
> way.

I don't think I understand the issue and the use case, sorry.