[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Fri, 19 Jun 2020 18:11:47 +0300

> Cc: philip@warpmail.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 19 Jun 2020 17:49:00 +0300
> On 19.06.2020 17:37, Eli Zaretskii wrote:
>  >>>      Switch to another buffer related to the current project.
>  >>>    A buffer is related to a project if its `default-directory'
>  >>>    is inside the directory hierarchy of the project's root.
>  >>
>  >> Sounds good. Except some projects can be inside one another, too.
>  > Does that invalidate what the text above says?
> If the current project contains a few other projects inside of its 
> subdirectories, project-switch-to-buffer probably should offer any of 
> "their" buffers for switching.

"Should" or "should not"?  If the former, then the text I proposed is
fine as it is.

> > Maybe we should step back and talk about the intended uses of this
> > command?  When would you want to switch to a buffer whose name you
> > don't know in advance?
> When don't I? Do you use icomplete, or something similar?
> As soon as you start relying on completion hints, you don't need to 
> remember the names in advance. And it's also a good overview of the 
> current open buffers in the current project.

If this is just for completion's sake, then I could understand, but
still it sounds very strange to include stuff like *XREF*, Eshell,
Occur, *Compilation*, *Grep*, etc.  Those are basically singletons, at
least by default, and a simple "C-x b" should be enough to switch to
them.  project-switch-to-buffer should be more helpful by offering
only "useful" buffers.

> Also, different projects can have files with conflicting names.

That cannot be solved by completion, where only the basename is
usually shown.

reply via email to

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