Re: master 1e3b0f2: Improve doc strings of project.el

[Dmitry Gutov]

On 20.06.2020 15:37, Eli Zaretskii wrote:
> > Cc: Eli Zaretskii <eliz@gnu.org>, Theodor Thornhill <theothornhill@pm.me>,
> >   philip@warpmail.net, emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Sat, 20 Jun 2020 14:57:07 +0300
> >
> > > Would it make sense for these special modes to have a buffer-local
> > > variable pointing to the buffer where the command was invoked?
> > > project.el could then consult that variable first, then fallback to
> > > default-directory?
> >
> > Perhaps. I don't know if that would be enough for Eli's purposes, however.
>
> It will solve some of them, to be sure.

Solve them how? Do you always invoke that search command from a buffer 
belonging to the original project? 75% of the time? 30%?

> > After all, in the Grep example, it could have been invoked from one of
> > the buffers belonging to the current project, or just as well from an
> > "outside" buffer (because, for example, that made it easier to select
> > the intended directory).
>
> So you are saying that it's better to have no way of supporting that
> use case than have some, even restricted, way?

No. I even suggested a few ways how this can be user-extensible.

And I'm saying we need a coherent design that's in line with what is 
already there. Or extends the behavior in a predictable way.

Going back to Kevin's suggestion, I'm fairly sure it will also generate 
both false positives and false negatives, going simply by my own usage 
habits: the originating buffer of where I'm calling a command doesn't 
necessarily correspond to which project I'm thinking of right now.

So I'm not sure if we can do this for the default behavior. Hence we'd 
need to use either one of the existing customization point, or add a new 
one.