[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: |
Eli Zaretskii |
Subject: |
bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects |
Date: |
Thu, 02 Jul 2020 16:36:54 +0300 |
> 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.
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/07/01
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/07/01
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects,
Eli Zaretskii <=
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/07/02
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/07/02
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/07/02
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/07/03
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/07/03
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Eli Zaretskii, 2020/07/03
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Dmitry Gutov, 2020/07/03
- bug#41821: 28.0.50; read-directory-name in vc commands should provide defaults from projects, Drew Adams, 2020/07/03