bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41821: 28.0.50; read-directory-name in vc commands should provide de


From: Dmitry Gutov
Subject: bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects
Date: Wed, 1 Jul 2020 23:24:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

Hi Eli,

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.

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.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]