GNU bug report logs - #12492
24.2.50; Open vc-dir buffer easier and faster

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
Subject: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)
Date: Fri, 06 Mar 2020 19:12:07 +0200

> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 6 Mar 2020 18:53:39 +0200
> 
> On 06.03.2020 18:14, Eli Zaretskii wrote:
> > So if we want to document the above two commands, we should do that in
> > the VC chapter, and talk about "project" meaning the current VCS
> > repository?
> 
> Umm, that's not how I would do that.
> 
> Since the idea behind project.el was to create an abstraction that 
> third-party project packages could hook into (Projectile, most 
> prominently), I think making such an emphasis is counter-productive.
> 
> So I'd rather put it in its own section, rather than create an 
> impression that a project = VC repository. But I see how this creates a 
> tension between giving practical advice and saying that "things might 
> change a little as soon as you install a third-party package". Or enable 
> ede-mode, I suppose.

Exactly.  For starters, how do you explain what a "project" is, when
the only example we can give is a repository?

I see nothing wrong with having this in the VC chapter for now; we can
always move it out later, when there are other back-ends.  The
placement of sections in chapters of the manual is neither sacred nor
final.

> BTW, there is a planned cleanup in the API that I've been thinking on 
> for a while. I've been hoping to get it into Emacs 27, but a number of 
> other issues conspired to take up the free time, so I guess it'll only 
> be there in Emacs 28. So I'm not sure to which extent we should document 
> this package in Emacs 27. But the two aforementioned commands will 
> remain there, of course.

I was only thinking about the commands, so the API change should not
be an issue.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.