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

Previous Next

Full log

Message #273 received at 12492 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Mon, 16 Mar 2020 05:25:27 +0200

> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sun, 15 Mar 2020 23:57:11 +0200
> 
> On 13.03.2020 16:30, Eli Zaretskii wrote:
> >> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> >> From: Dmitry Gutov <dgutov <at> yandex.ru>
> >> Date: Fri, 13 Mar 2020 14:23:51 +0200
> >>
> >>> How can we describe such an extension in advance in the user manual?
> >>
> >> Maybe by using a higher-level language like I suggested earlier in this
> >> discussions.
> > 
> > That'd be some vague general principle, not a documentation of
> > specific commands.
> 
> Surely you're not going to say that e.g. project-find-file calls 'git 
> ls-files' to enumerate a project's files in the most usual case, or that 
> project-find-regexp uses Grep under the hood?

We keep losing context, and this keep looping without any hope.  I
hate to tell people please re-read the past discussion, but there's
nothing else I can say here, because you keep repeating the same
questions and I keep giving the same answers.

> >> Projects are this and that, you can use commands xx and yy whn inside a
> >> project. If the current buffer does not belong to a project, you will be
> >> prompted for a directory to look in. The main project type supported by
> >> Emacs OOB is VC repositories.
> > 
> > Sorry, not in my book.  This text begs gobs of questions for which
> > there will be no answers.  User manuals shouldn't do that.
> 
> Could you give an example of a couple of such questions?

I already did, up-thread.

> >> How do we document completion-at-point, for instance? It's also
> >> extensible.
> > 
> > We describe the available variants.  Please take a look at the
> > relevant text (in "Symbol Completion" and in "Shell Mode").
> 
> So it says that completion-at-point is "flexible", and that's basically 
> it on the subject of extensibility (IOW, the possibility of different 
> behaviors in different major modes)?

No, that's not what the text said, at least not the text I read there.

Previous Next

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