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

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Sat, 22 Sep 2012 23:06:01 UTC

Severity: wishlist

Tags: patch

Found in version 24.2.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12492 in the body.
You can then email your comments to 12492 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sat, 22 Sep 2012 23:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dmitry Gutov <dgutov <at> yandex.ru>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 22 Sep 2012 23:06:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2.50; Open vc-dir buffer easier and faster
Date: Sun, 23 Sep 2012 03:04:01 +0400
[Message part 1 (text/plain, inline)]
Tags: patch

Two changes:
1) All version controlled buffers have after-save-hook set up to call 
vc-dir-resynch-file. So if we're just bringing up a buried vc-dir 
buffer, we (almost?) never need to refresh it. This cuts about 1 second 
or more on my machine, depending on the backend.
2) For almost all backends we can easily deduce the repository root 
directory (exceptions: cvs, rcs, sccs), and I believe that in almost all 
cases the user wants to see the status of this directory, not of some 
subdirectory or any directory unrelated to the current buffer.
Hence the function vc-root-dir, which I think should be bound to 'C-x v 
d' and the respective menu item.
In the rare case when the user need to do something unusual, they can do 
M-x vc-dir.
When the backend doesn't have the function vc-xx-root, vc-root-dir 
interactively delegates to vc-dir, so for CVS, for example, the behavior 
will not change.
[vc-dir.diff (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sat, 22 Sep 2012 23:34:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
	and faster)
Date: Sun, 23 Sep 2012 03:31:35 +0400
[Message part 1 (text/plain, inline)]
Same patch, with ChangeLog entries.
[vc-dir.diff (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 23 Sep 2012 07:04:01 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: 24.2.50; Open vc-dir buffer easier and faster
Date: Sun, 23 Sep 2012 09:01:12 +0200
I don't agree with either point.  This should be optional with the
current behaviour left as the default.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 23 Sep 2012 08:41:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: 24.2.50; Open vc-dir buffer easier and faster
Date: Sun, 23 Sep 2012 12:38:17 +0400
On 23.09.2012 11:01, Andreas Schwab wrote:
> I don't agree with either point.  This should be optional with the
> current behaviour left as the default.

Do you have a counter-example for the first point? External changes made 
outside Emacs? I can make a customize variable for that, I guess.

The second can be made "optional" by keeping the current keybinding.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 23 Sep 2012 08:49:01 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: 24.2.50; Open vc-dir buffer easier and faster
Date: Sun, 23 Sep 2012 10:46:12 +0200
Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 23.09.2012 11:01, Andreas Schwab wrote:
>> I don't agree with either point.  This should be optional with the
>> current behaviour left as the default.
>
> Do you have a counter-example for the first point? External changes made
> outside Emacs? I can make a customize variable for that, I guess.

Yes, that is what I was thinking of.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 23 Sep 2012 11:49:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: 24.2.50; Open vc-dir buffer easier and faster
Date: Sun, 23 Sep 2012 15:46:35 +0400
On 23.09.2012 12:46, Andreas Schwab wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
>> On 23.09.2012 11:01, Andreas Schwab wrote:
>>> I don't agree with either point.  This should be optional with the
>>> current behaviour left as the default.
>>
>> Do you have a counter-example for the first point? External changes made
>> outside Emacs? I can make a customize variable for that, I guess.
>
> Yes, that is what I was thinking of.

Very well.

On the second point, do you always prefer to open vc-dir for a directory 
other than repository root? Why?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 23 Sep 2012 11:57:01 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: 24.2.50; Open vc-dir buffer easier and faster
Date: Sun, 23 Sep 2012 13:54:39 +0200
The repository root doesn't always coincide with the subsystem root.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 23 Sep 2012 12:29:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: 24.2.50; Open vc-dir buffer easier and faster
Date: Sun, 23 Sep 2012 16:26:40 +0400
On 23.09.2012 15:54, Andreas Schwab wrote:
> The repository root doesn't always coincide with the subsystem root.

I see. Though personally, I'd prefer not to have uncommitted changes 
outside the subsystem I'm working on. So vc-dir buffer contents would be 
effectively the same either way.

My argument here is that selecting a different directory is a relatively 
slow operation, and having to type 'M-x vc-dir' won't slow it down much.
If the command doesn't prompt you, though, and if point (1) is in 
effect, then having a keybinding can make a bigger difference.

In addition, I can add a "pick vc directory function" variable, which 
vc-root-dir will check and try to use. Better name suggestions welcome.

Before I make an updated patch, I'd like to get an opinion from VC or 
Emacs maintainer.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 21 Jan 2015 20:56:01 GMT) Full text and rfc822 format available.

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 12492 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#12492: vc-dir vs. vc-root-dir 
Date: Wed, 21 Jan 2015 20:55:11 +0000
>>>>> Dmitry Gutov <dgutov <at> yandex.ru> writes:

[…]

 > 2) For almost all backends we can easily deduce the repository root
 > directory (exceptions: cvs, rcs, sccs), and I believe that in almost
 > all cases the user wants to see the status of this directory, not of
 > some subdirectory or any directory unrelated to the current buffer.
 > Hence the function vc-root-dir, which I think should be bound to 'C-x
 > v d' and the respective menu item.  In the rare case when the user
 > need to do something unusual, they can do M-x vc-dir.

	We already have at least two pairs of commands (C-x v l vs.
	C-x v L /and/ C-x v = vs. C-x v D), of which one operates on the
	current file /and/ the other on the repository as a whole.

	Is there any good reason we can’t have a similar arrangement for
	vc-dir (C-x v d) and the proposed vc-root-dir command (say,
	C-x v /, – where ‘/’ is a kind of obvious mnemonic for “root”)?

	I find it way better than f302475471df, as it both keeps the
	current behavior for C-x v d for those who may still want it
	/and/ it offers a /prompt-free/ shortcut for those who’d always
	want to use vc-dir on the root.

 > When the backend doesn't have the function vc-xx-root, vc-root-dir
 > interactively delegates to vc-dir, so for CVS, for example, the
 > behavior will not change.

	That’s certainly sensible, too.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 21 Jan 2015 21:56:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: vc-dir vs. vc-root-dir
Date: Wed, 21 Jan 2015 16:55:24 -0500
> 	Is there any good reason we can’t have a similar arrangement for
> 	vc-dir (C-x v d) and the proposed vc-root-dir command (say,
> 	C-x v /, – where ‘/’ is a kind of obvious mnemonic for “root”)?

If `C-x v D' were available, I guess that would be OK, but given that's
not the case, I don't think it's worth the trouble.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 22 Jan 2015 05:42:01 GMT) Full text and rfc822 format available.

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: vc-dir vs. vc-root-dir 
Date: Thu, 22 Jan 2015 05:40:50 +0000
>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

 >> Is there any good reason we can’t have a similar arrangement for
 >> vc-dir (C-x v d) and the proposed vc-root-dir command (say, C-x v /,
 >> – where ‘/’ is a kind of obvious mnemonic for “root”)?

 > If `C-x v D' were available, I guess that would be OK, but given
 > that's not the case, I don't think it's worth the trouble.

	Why is that a problem?  Especially given that the recent
	discussion seems to suggest that there’re going to be VC users
	who’d stick to vc-root-dir exclusively.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 22 Jan 2015 17:05:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: vc-dir vs. vc-root-dir
Date: Thu, 22 Jan 2015 12:04:05 -0500
> 	Why is that a problem?

It's not a "problem", just a cost/benefit tradeoff.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 23 Jan 2015 12:14:01 GMT) Full text and rfc822 format available.

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

From: Ivan Shmakov <ivan <at> siamics.net>
To: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: vc-dir vs. vc-root-dir
Date: Fri, 23 Jan 2015 12:12:55 +0000
>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

 >> Why is that a problem?

 > It's not a "problem", just a cost/benefit tradeoff.

	The “problem” as I see it is that we have at least two groups of
	VC users, – those who’d use vc-root vc-dir buffers so often as
	to make prompting an obstacle, /and/ those who’d prefer for
	vc-dir to remain consistent with the likes of find-file in its
	use of default-directory as, well, the default.

	FTR, one another case where such an “inconsistent” behavior was
	implemented at some point is desktop-read.  However, this change
	is easy to revert with an explicit (setq desktop-path '(".")) in
	one’s ~/.emacs.

	I believe it would be nice to offer the “pro-consistency” VC
	users a similarly simple way to revert to the pre-f302475471df
	behavior.

	(Personally, I guess I’d simply revert the change locally,
	should no suitable customization be implemented.)

	TIA.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 24 Feb 2016 06:09:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Wed, 24 Feb 2016 17:07:40 +1100
Dmitry Gutov <dgutov <at> yandex.ru> writes:

> +;;;###autoload
> +(defun vc-root-dir ()
> +  "Show the VC status of the current buffer's repository.
> +If the buffer is not visiting a version controlled file, or if

It looks to me like this was fixed in a different manner a few years
later, so I'm closing this bug report.  Please reopen if it's still an
issue.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug closed, send any further explanations to 12492 <at> debbugs.gnu.org and Dmitry Gutov <dgutov <at> yandex.ru> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 24 Feb 2016 06:09:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 24 Feb 2016 15:00:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Wed, 24 Feb 2016 16:59:14 +0200
Reopen!

On 02/24/2016 08:07 AM, Lars Ingebrigtsen wrote:

>> +;;;###autoload
>> +(defun vc-root-dir ()
>> +  "Show the VC status of the current buffer's repository.
>> +If the buffer is not visiting a version controlled file, or if
>
> It looks to me like this was fixed in a different manner a few years
> later, so I'm closing this bug report.  Please reopen if it's still an
> issue.

Not at all. The new vc-root-dir is a different beast from what I proposed.

Could you reopen it yourself? I'm writing this response from a 
traditional email client.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 24 Feb 2016 23:47:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Thu, 25 Feb 2016 10:46:06 +1100
Dmitry Gutov <dgutov <at> yandex.ru> writes:

> Could you reopen it yourself? I'm writing this response from a
> traditional email client.

I've now reopened.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 24 Feb 2016 23:47:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 27 Jun 2019 14:50:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Thu, 27 Jun 2019 16:49:19 +0200
Dmitry Gutov <dgutov <at> yandex.ru> writes:

> +;;;###autoload
> +(defun vc-root-dir ()
> +  "Show the VC status of the current buffer's repository.
> +If the buffer is not visiting a version controlled file, or if
> +the backend does not support function `root', prompt for
> +directory.  See `vc-dir' for more details."

I think this sounds like a useful command -- whenever I'm not vc-dir-in
in the top level of the repo, I'm doing something wrong (and just
committing bits of the changes I meant to do).

I made my own command to do this, but I think it would be generally
useful.

[...]

> -    (define-key map "d" 'vc-dir)
> +    (define-key map "d" 'vc-root-dir)

But this would probably be very controversial.  `C-x v /' is a nice
binding, though...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 27 Jun 2019 22:00:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Fri, 28 Jun 2019 00:16:57 +0300
>> +;;;###autoload
>> +(defun vc-root-dir ()
>> +  "Show the VC status of the current buffer's repository.
>> +If the buffer is not visiting a version controlled file, or if
>> +the backend does not support function `root', prompt for
>> +directory.  See `vc-dir' for more details."
>
> I think this sounds like a useful command -- whenever I'm not vc-dir-in
> in the top level of the repo, I'm doing something wrong (and just
> committing bits of the changes I meant to do).
>
> I made my own command to do this, but I think it would be generally
> useful.

I made my own too:

  (defun vc-dir-in-project-root ()
    "Run `vc-dir' in project root directory."
    (interactive)
    (let* ((project (project-current))
           (root (and project (car (project-roots project)))))
      (vc-dir (or (and root (file-directory-p root) root) default-directory))))

not sure if it should rely on `vc-root-dir' instead
(I mean the already existing function `vc-root-dir'
that returns the root dir).

>> -    (define-key map "d" 'vc-dir)
>> +    (define-key map "d" 'vc-root-dir)
>
> But this would probably be very controversial.  `C-x v /' is a nice
> binding, though...

I'd prefer an option whose customization would allow `C-x v d'
to always use the root.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 27 Jun 2019 22:15:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Fri, 28 Jun 2019 00:14:15 +0200
Juri Linkov <juri <at> linkov.net> writes:

>>> -    (define-key map "d" 'vc-dir)
>>> +    (define-key map "d" 'vc-root-dir)
>>
>> But this would probably be very controversial.  `C-x v /' is a nice
>> binding, though...
>
> I'd prefer an option whose customization would allow `C-x v d'
> to always use the root.

I this whether you want one or the other depends in the situation, so I
think `C-x v /' makes sense.  It's as easy to type as `C-x v d' (at
least on US keyboards)...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 28 Jun 2019 13:22:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 28 Jun 2019 16:21:10 +0300
On 28.06.2019 0:16, Juri Linkov wrote:

> not sure if it should rely on `vc-root-dir' instead
> (I mean the already existing function `vc-root-dir'
> that returns the root dir).

I think it should (like my original patch did).

When a project contains several repository roots, you probably want to 
use the closest one. Otherwise, the behavior will be the same.

>>> -    (define-key map "d" 'vc-dir)
>>> +    (define-key map "d" 'vc-root-dir)
>>
>> But this would probably be very controversial.  `C-x v /' is a nice
>> binding, though...
> 
> I'd prefer an option whose customization would allow `C-x v d'
> to always use the root.

Honestly, I think these are equivalent proposals, with the exception 
that Lars' keeps the current behavior intact by default.

For those of us who want to change the behavior of 'C-x v d', we can 
call define-key in the init script.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 28 Jun 2019 19:20:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Fri, 28 Jun 2019 22:16:06 +0300
>>>> -    (define-key map "d" 'vc-dir)
>>>> +    (define-key map "d" 'vc-root-dir)
>>>
>>> But this would probably be very controversial.  `C-x v /' is a nice
>>> binding, though...
>>
>> I'd prefer an option whose customization would allow `C-x v d'
>> to always use the root.
>
> I this whether you want one or the other depends in the situation, so I
> think `C-x v /' makes sense.  It's as easy to type as `C-x v d' (at
> least on US keyboards)...

The difference in number of typed keys between the existing key sequence
and the proposed new one is just one key:

C-x v d RET   (4 keys for existing)
C-x v /       (3 keys for new)

But I don't oppose to the new keybinding if you get more support for it.

BTW, it also makes sense to use C-x D to open dired in the root directory
(added to ~/.emacs)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 28 Jun 2019 19:20:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Fri, 28 Jun 2019 22:17:36 +0300
>> not sure if it should rely on `vc-root-dir' instead
>> (I mean the already existing function `vc-root-dir'
>> that returns the root dir).
>
> I think it should (like my original patch did).
>
> When a project contains several repository roots, you probably want to use
> the closest one. Otherwise, the behavior will be the same.

Yes, the closest one is the right.

>>>> -    (define-key map "d" 'vc-dir)
>>>> +    (define-key map "d" 'vc-root-dir)
>>>
>>> But this would probably be very controversial.  `C-x v /' is a nice
>>> binding, though...
>>
>> I'd prefer an option whose customization would allow `C-x v d'
>> to always use the root.
>
> Honestly, I think these are equivalent proposals, with the exception that
> Lars' keeps the current behavior intact by default.
>
> For those of us who want to change the behavior of 'C-x v d', we can call
> define-key in the init script.

So we could have a new command anyway (with a different name than
the already added function vc-root-dir that returns the root directory),
even if unbound, so users can decide wherever they prefer to bind it.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 28 Jun 2019 19:30:03 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 28 Jun 2019 22:29:00 +0300
On 28.06.2019 22:17, Juri Linkov wrote:
> So we could have a new command anyway (with a different name than
> the already added function vc-root-dir that returns the root directory),
> even if unbound, so users can decide wherever they prefer to bind it.

Yup, that would be fine by me.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 28 Jun 2019 19:31:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 28 Jun 2019 22:30:10 +0300
On 28.06.2019 1:14, Lars Ingebrigtsen wrote:
> It's as easy to type as `C-x v d' (at
> least on US keyboards)...

Not exactly; the former can be typed using just one hand. That's easier, 
in my book.

So overall, I'm leaning towards just adding a new command and leaving 
the choice of binding it to the user.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sat, 29 Jun 2019 10:20:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Sat, 29 Jun 2019 12:19:21 +0200
Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 28.06.2019 22:17, Juri Linkov wrote:
>> So we could have a new command anyway (with a different name than
>> the already added function vc-root-dir that returns the root directory),
>> even if unbound, so users can decide wherever they prefer to bind it.
>
> Yup, that would be fine by me.

I don't see any reason not to bind this new command to a key: It seems
like a genuinely useful command that most people (if they knows it
exists) will want to use.  I can well imagine more people wanting that
command than they want the `C-x v d' one.

But I also think that many people will want both, so the solution seems
to me to just bind this new command to a new keystroke, and leave the
rest alone.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 30 Jun 2019 22:16:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Sun, 30 Jun 2019 23:53:43 +0300
>>> So we could have a new command anyway (with a different name than
>>> the already added function vc-root-dir that returns the root directory),
>>> even if unbound, so users can decide wherever they prefer to bind it.
>>
>> Yup, that would be fine by me.
>
> I don't see any reason not to bind this new command to a key: It seems
> like a genuinely useful command that most people (if they knows it
> exists) will want to use.  I can well imagine more people wanting that
> command than they want the `C-x v d' one.
>
> But I also think that many people will want both, so the solution seems
> to me to just bind this new command to a new keystroke, and leave the
> rest alone.

C-x v / is so nicely mnemonic keybinding that it even makes sense
to use it as a key prefix to the whole set of root-related commands, e.g.:

C-x v / =   vc-root-diff (mnemonic: '/' root, '=' diff)
C-x v / l   vc-print-root-log (mnemonic: '/' root, 'l' log)
C-x v / d   vc-root-dir (mnemonic: '/' root, 'd' dir)
...

Hmm, btw, why the extra prefix 'print-'?  Why not simply 'vc-root-log'?





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 01 Jul 2019 08:03:02 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> suse.de>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Mon, 01 Jul 2019 10:02:49 +0200
On Sep 23 2012, Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> +(defun vc-root-dir ()

This is already defined in vc.el.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 01 Jul 2019 12:57:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Andreas Schwab <schwab <at> suse.de>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Mon, 1 Jul 2019 15:56:42 +0300
On 01.07.2019 11:02, Andreas Schwab wrote:
> On Sep 23 2012, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> 
>> +(defun vc-root-dir ()
> 
> This is already defined in vc.el.

True. The patch predated the introduction of that function.

Here's the code that I have been using for the last few years:

(defun vc-dir-quick ()
  (interactive)
  (require 'vc-dir)
  (let* ((file (or buffer-file-name default-directory))
         (backend (vc-responsible-backend file))
         (dir (vc-call-backend backend 'root file)))
    (let (pop-up-windows)
      (pop-to-buffer (vc-dir-prepare-status-buffer "*vc-dir*" dir 
backend)))
    (unless (derived-mode-p 'vc-dir-mode)
      (let ((use-vc-backend backend))
        (vc-dir-mode)))))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 01 Jul 2019 13:02:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Mon, 1 Jul 2019 16:01:27 +0300
On 29.06.2019 13:19, Lars Ingebrigtsen wrote:
> I don't see any reason not to bind this new command to a key: It seems
> like a genuinely useful command that most people (if they knows it
> exists) will want to use.  I can well imagine more people wanting that
> command than they want the `C-x v d' one.

I honestly don't see the point of having both having a binding. IME, the 
new commands is useful 99% of the time, and in the remaining case it 
would be faster to type 'M-x vc-dir' than remember the respective 
different key binding.

But please do as you see fit. The fight for a better behavior for 'C-x v 
d' seems to have been lost years ago, and it's the only key binding 
change here that I would get behind.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Tue, 02 Jul 2019 12:40:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Tue, 02 Jul 2019 14:39:27 +0200
Juri Linkov <juri <at> linkov.net> writes:

> C-x v / is so nicely mnemonic keybinding that it even makes sense
> to use it as a key prefix to the whole set of root-related commands, e.g.:
>
> C-x v / =   vc-root-diff (mnemonic: '/' root, '=' diff)
> C-x v / l   vc-print-root-log (mnemonic: '/' root, 'l' log)
> C-x v / d   vc-root-dir (mnemonic: '/' root, 'd' dir)

Hm...  makes sense.  But they are inconveniently long for tasks that you
do all the time.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 04 Jul 2019 20:39:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Thu, 04 Jul 2019 23:17:48 +0300
>> C-x v / is so nicely mnemonic keybinding that it even makes sense
>> to use it as a key prefix to the whole set of root-related commands, e.g.:
>>
>> C-x v / =   vc-root-diff (mnemonic: '/' root, '=' diff)
>> C-x v / l   vc-print-root-log (mnemonic: '/' root, 'l' log)
>> C-x v / d   vc-root-dir (mnemonic: '/' root, 'd' dir)
>
> Hm...  makes sense.  But they are inconveniently long for tasks that you
> do all the time.

Also it makes more sense to introduce a root prefix map for the whole set
of project related commands (not necessarily restricted to VCS):

C-x / d - project dir
C-x / f - project find file
C-x / r - project find regexp
C-x / t - project tag search
C-x / s - project search/grep
C-x / % - project query-replace
C-x / l - project log
C-x / = - project diff
...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 04 Jul 2019 20:39:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Andreas Schwab <schwab <at> suse.de>, 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Thu, 04 Jul 2019 23:25:27 +0300
>>> +(defun vc-root-dir ()
>>
>> This is already defined in vc.el.
>
> True. The patch predated the introduction of that function.

Maybe better to add interactivity to the existing function
`vc-root-dir', i.e. to add a new arg `(&optional interactive)'
and add `(interactive "p")'.

BTW, I propose another useful command without a keybinding.
I have a habit of mistyping `v' in vc-dir to view a file like in dired.
That often has adverse effect.  So I rebound these keys in ~/.emacs
to a Dired-like command.  Maybe this command could be useful for anyone
who has the same problem:

diff --git a/lisp/vc/vc-dir.el b/lisp/vc/vc-dir.el
index 6afc599d4c..a6a87e51e3 100644
--- a/lisp/vc/vc-dir.el
+++ b/lisp/vc/vc-dir.el
@@ -784,6 +784,11 @@ vc-dir-display-file
   (display-buffer (find-file-noselect (vc-dir-current-file))
 		  t))
 
+(defun vc-dir-view-file ()
+  "Examine a file on the current line in view mode."
+  (interactive)
+  (view-file (vc-dir-current-file)))
+
 (defun vc-dir-isearch ()
   "Search for a string through all marked buffers using Isearch."
   (interactive)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 04 Jul 2019 22:07:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Andreas Schwab <schwab <at> suse.de>, 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Fri, 05 Jul 2019 01:05:20 +0300
>>>> +(defun vc-root-dir ()
>>>
>>> This is already defined in vc.el.
>>
>> True. The patch predated the introduction of that function.
>
> Maybe better to add interactivity to the existing function
> `vc-root-dir', i.e. to add a new arg `(&optional interactive)'
> and add `(interactive "p")'.

BTW, why vc-git-log-incoming and vc-git-log-outgoing are interactive?
It seems these functions are not intended to be used as commands:

diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index f62e108322..6a6036cf8a 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -1048,7 +1050,6 @@ vc-git-print-log
 		'("--")))))))
 
 (defun vc-git-log-outgoing (buffer remote-location)
-  (interactive)
   (vc-setup-buffer buffer)
   (vc-git-command
    buffer 'async nil
@@ -1062,7 +1063,6 @@ vc-git-log-outgoing
 	   "..HEAD")))
 
 (defun vc-git-log-incoming (buffer remote-location)
-  (interactive)
   (vc-setup-buffer buffer)
   (vc-git-command nil 0 nil "fetch")
   (vc-git-command




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 05 Jul 2019 13:10:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Fri, 05 Jul 2019 15:09:37 +0200
Juri Linkov <juri <at> linkov.net> writes:

> Also it makes more sense to introduce a root prefix map for the whole set
> of project related commands (not necessarily restricted to VCS):
>
> C-x / d - project dir
> C-x / f - project find file
> C-x / r - project find regexp
> C-x / t - project tag search
> C-x / s - project search/grep
> C-x / % - project query-replace
> C-x / l - project log
> C-x / = - project diff

I like it.  How would one define "project root" outside of a VCS, though?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 05 Jul 2019 13:42:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 5 Jul 2019 16:41:17 +0300
On 05.07.2019 16:09, Lars Ingebrigtsen wrote:
> Juri Linkov <juri <at> linkov.net> writes:
> 
>> Also it makes more sense to introduce a root prefix map for the whole set
>> of project related commands (not necessarily restricted to VCS):
>>
>> C-x / d - project dir
>> C-x / f - project find file
>> C-x / r - project find regexp
>> C-x / t - project tag search
>> C-x / s - project search/grep
>> C-x / % - project query-replace
>> C-x / l - project log
>> C-x / = - project diff
> 
> I like it.  How would one define "project root" outside of a VCS, though?

'project root' is defined in project.el.

I don't know how we would define 'project log' or 'project diff', though.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 05 Jul 2019 13:44:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: Andreas Schwab <schwab <at> suse.de>, 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 5 Jul 2019 16:43:15 +0300
On 04.07.2019 23:25, Juri Linkov wrote:

> Maybe better to add interactivity to the existing function
> `vc-root-dir', i.e. to add a new arg `(&optional interactive)'
> and add `(interactive "p")'.

Not sure I would like such wide overloading of behaviors.

> BTW, I propose another useful command without a keybinding.
> I have a habit of mistyping `v' in vc-dir to view a file like in dired.
> That often has adverse effect.  So I rebound these keys in ~/.emacs
> to a Dired-like command.  Maybe this command could be useful for anyone
> who has the same problem:

I don't have this problem or a strong opinion, but this is a breaking 
change. Could you bring it up on emacs-devel to gauge consensus, for 
example?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 05 Jul 2019 13:46:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: Andreas Schwab <schwab <at> suse.de>, 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 5 Jul 2019 16:44:59 +0300
On 05.07.2019 1:05, Juri Linkov wrote:

> BTW, why vc-git-log-incoming and vc-git-log-outgoing are interactive?
> It seems these functions are not intended to be used as commands:

Makes sense, thank you. Please install.

> diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
> index f62e108322..6a6036cf8a 100644
> --- a/lisp/vc/vc-git.el
> +++ b/lisp/vc/vc-git.el
> @@ -1048,7 +1050,6 @@ vc-git-print-log
>   		'("--")))))))
>   
>   (defun vc-git-log-outgoing (buffer remote-location)
> -  (interactive)
>     (vc-setup-buffer buffer)
>     (vc-git-command
>      buffer 'async nil
> @@ -1062,7 +1063,6 @@ vc-git-log-outgoing
>   	   "..HEAD")))
>   
>   (defun vc-git-log-incoming (buffer remote-location)
> -  (interactive)
>     (vc-setup-buffer buffer)
>     (vc-git-command nil 0 nil "fetch")
>     (vc-git-command
> 





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 05 Jul 2019 19:14:05 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Fri, 05 Jul 2019 21:53:21 +0300
>>> Also it makes more sense to introduce a root prefix map for the whole set
>>> of project related commands (not necessarily restricted to VCS):
>>>
>>> C-x / d - project dir
>>> C-x / f - project find file
>>> C-x / r - project find regexp
>>> C-x / t - project tag search
>>> C-x / s - project search/grep
>>> C-x / % - project query-replace
>>> C-x / l - project log
>>> C-x / = - project diff
>>
>> I like it.  How would one define "project root" outside of a VCS, though?
>
> 'project root' is defined in project.el.
>
> I don't know how we would define 'project log' or 'project diff', though.

When a project is not under VCS then 'project log' could rely on
ChangeLog files, and 'project diff' to use backup files.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 05 Jul 2019 19:14:06 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Andreas Schwab <schwab <at> suse.de>, 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Fri, 05 Jul 2019 21:56:44 +0300
>> BTW, I propose another useful command without a keybinding.
>> I have a habit of mistyping `v' in vc-dir to view a file like in dired.
>> That often has adverse effect.  So I rebound these keys in ~/.emacs
>> to a Dired-like command.  Maybe this command could be useful for anyone
>> who has the same problem:
>
> I don't have this problem or a strong opinion, but this is a breaking
> change. Could you bring it up on emacs-devel to gauge consensus,
> for example?

This is not a breaking change because it's just a new command
without keybinding.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sat, 06 Jul 2019 08:38:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: Andreas Schwab <schwab <at> suse.de>, 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Sat, 6 Jul 2019 11:37:00 +0300
On 05.07.2019 21:56, Juri Linkov wrote:

> This is not a breaking change because it's just a new command
> without keybinding.

Ah, sorry. Please go ahead, then.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sat, 06 Jul 2019 12:00:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Sat, 06 Jul 2019 13:59:22 +0200
Juri Linkov <juri <at> linkov.net> writes:

> When a project is not under VCS then 'project log' could rely on
> ChangeLog files, and 'project diff' to use backup files.

Which reminds me -- why doesn't `C-x v =' work on normal files that have
backups?  I think that would be pretty nice, natural and useful...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 07 Jul 2019 23:04:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50;
 Open vc-dir buffer easier and faster)
Date: Mon, 08 Jul 2019 01:56:11 +0300
>> When a project is not under VCS then 'project log' could rely on
>> ChangeLog files, and 'project diff' to use backup files.
>
> Which reminds me -- why doesn't `C-x v =' work on normal files that have
> backups?  I think that would be pretty nice, natural and useful...

I have the same problem of sometimes typing `C-x v =' instead of `M-='
(dired-backup-diff) on backuped files in dired, and vice versa - `M-='
instead of `C-x v =' on VC files.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 07 Jul 2019 23:10:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 12492 <at> debbugs.gnu.org
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Mon, 8 Jul 2019 02:09:35 +0300
On 08.07.2019 1:56, Juri Linkov wrote:
>>> When a project is not under VCS then 'project log' could rely on
>>> ChangeLog files, and 'project diff' to use backup files.
>>
>> Which reminds me -- why doesn't `C-x v =' work on normal files that have
>> backups?  I think that would be pretty nice, natural and useful...
> 
> I have the same problem of sometimes typing `C-x v =' instead of `M-='
> (dired-backup-diff) on backuped files in dired, and vice versa - `M-='
> instead of `C-x v =' on VC files.

But those are significantly different commands. One diffs against the 
last saved copy of the file, the other works only on the saved files.

And anyway, there's no counterpart for vc-print-root-log.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 07 Jul 2019 23:12:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Mon, 8 Jul 2019 02:11:16 +0300
On 05.07.2019 21:53, Juri Linkov wrote:

> When a project is not under VCS then 'project log' could rely on
> ChangeLog files, and 'project diff' to use backup files.

I don't imagine either would (or could) use project.el, so calling those 
hypothetical commands project-based seems like a misnomer.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Tue, 25 Feb 2020 00:42:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: 12492 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 25 Feb 2020 02:10:02 +0200
> Also it makes more sense to introduce a root prefix map for the whole set of
> project related commands (not necessarily restricted to VCS):
>
> C-x / d - project dir
> C-x / f - project find file
> C-x / r - project find regexp
> C-x / t - project tag search
> C-x / s - project search/grep
> C-x / % - project query-replace
> C-x / l - project log
> C-x / = - project diff
> ...

OTOH, wouldn't it be nicer to use more mnemonic prefix key
'C-x p' where 'p' means "project".  Then:

C-x p d - project dir
C-x p s - project shell
C-x p g - project grep
...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Tue, 25 Feb 2020 10:36:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, 12492 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 25 Feb 2020 12:35:25 +0200
On 25.02.2020 2:10, Juri Linkov wrote:

> OTOH, wouldn't it be nicer to use more mnemonic prefix key
> 'C-x p' where 'p' means "project".  Then:

Sure (and I'm fine with either prefix), but...

> C-x p d - project dir

That sounds more like "open Dired in the project's root".

> C-x p s - project shell
> C-x p g - project grep

Bind project-find-regexp to it?

> ...

And a command that opens VC-Dir in the VC root, wouldn't use the 
project.el infractructure. Correct me if I'm wrong about that.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Tue, 25 Feb 2020 21:35:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 25 Feb 2020 23:27:35 +0200
>> C-x p d - project dir
>
> That sounds more like "open Dired in the project's root".

Indeed, two commands compete for the same mnemonic key 'd':
Dired and VC-Dired.

>> C-x p g - project grep
>
> Bind project-find-regexp to it?

Not sure since project-find-regexp is not asynchronous as grep.

>> ...
>
> And a command that opens VC-Dir in the VC root, wouldn't use the project.el
> infractructure. Correct me if I'm wrong about that.

You know more about connection between project.el and VC.
What I could do is only to count occurrences of the word "vc"
in project.el: 39 occurrences.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 26 Feb 2020 22:52:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Thu, 27 Feb 2020 00:51:12 +0200
On 25.02.2020 23:27, Juri Linkov wrote:
>>> C-x p d - project dir
>>
>> That sounds more like "open Dired in the project's root".
> 
> Indeed, two commands compete for the same mnemonic key 'd':
> Dired and VC-Dired.

And only one of the is likely to use the project.el functions.

>>> C-x p g - project grep
>>
>> Bind project-find-regexp to it?
> 
> Not sure since project-find-regexp is not asynchronous as grep.

All the more reason for someone to work on that. And the former has 
other benefits.

>> And a command that opens VC-Dir in the VC root, wouldn't use the project.el
>> infractructure. Correct me if I'm wrong about that.
> 
> You know more about connection between project.el and VC.
> What I could do is only to count occurrences of the word "vc"
> in project.el: 39 occurrences.

VC is just one of project.el's backends. The main one among the 
built-ins, but that's not particularly important in this context.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 26 Feb 2020 23:48:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Thu, 27 Feb 2020 01:41:46 +0200
> VC is just one of project.el's backends. The main one among the built-ins,
> but that's not particularly important in this context.

I guess other backends have no analogue of vc-dir and other vc commands.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 27 Feb 2020 07:28:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Thu, 27 Feb 2020 09:27:12 +0200
On 27.02.2020 1:41, Juri Linkov wrote:
> I guess other backends have no analogue of vc-dir and other vc commands

Nope.

I mean, you call VC-Dir in an arbitrary project's root anyway, and a lot 
of times it will work. But a project root doesn't have to be a VC root 
and vice versa, so these notions are more or less orthogonal.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 27 Feb 2020 23:19:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: 12492 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 28 Feb 2020 00:50:45 +0200
[Message part 1 (text/plain, inline)]
> I'd prefer an option whose customization would allow `C-x v d'
> to always use the root.

Given all the discussed constraints (no change in default behavior of
`C-x v d' is allowed, etc.), I see one way to close this bug report -
to add a customizable variable:

[vc-dir-default-directory.patch (text/x-diff, inline)]
diff --git a/lisp/vc/vc-dir.el b/lisp/vc/vc-dir.el
index e5c5e16a17..2699f8155b 100644
--- a/lisp/vc/vc-dir.el
+++ b/lisp/vc/vc-dir.el
@@ -1285,6 +1285,22 @@ vc-dir-deduce-fileset
 	(setq model (vc-checkout-model vc-dir-backend only-files-list))))
     (list vc-dir-backend files only-files-list state model)))
 
+(defcustom vc-dir-default-directory nil
+  "Default directory name for the command `vc-dir'.
+When nil, `vc-dir' reads a directory name using the minibuffer.
+When non-nil and the current directory is under version control,
+`vc-dir' doesn't ask for a directory name and uses the VC root directory.
+When a string and `vc-dir' is invoked in a directory outside of
+version control, then this string is used as a default directory name.
+
+However, the prefix arg of `vc-dir' overrides this customization
+and still asks for a directory name and backend."
+  :type '(choice (const :tag "Ask for directory" nil)
+                 (const :tag "Use VC root directory" t)
+                 (string :tag "Custom directory"))
+  :group 'vc
+  :version "28.1")
+
 ;;;###autoload
 (defun vc-dir (dir &optional backend)
   "Show the VC status for \"interesting\" files in and below DIR.
@@ -1304,22 +1320,29 @@ vc-dir
 \\{vc-dir-mode-map}"
 
   (interactive
-   (list
-    ;; When you hit C-x v d in a visited VC file,
-    ;; the *vc-dir* buffer visits the directory under its truename;
-    ;; therefore it makes sense to always do that.
-    ;; Otherwise if you do C-x v d -> C-x C-f -> C-c v d
-    ;; you may get a new *vc-dir* buffer, different from the original
-    (file-truename (read-directory-name "VC status for directory: "
-					(vc-root-dir) nil t
-					nil))
-    (if current-prefix-arg
-	(intern
-	 (completing-read
-	  "Use VC backend: "
-	  (mapcar (lambda (b) (list (symbol-name b)))
-		  vc-handled-backends)
-	  nil t nil nil)))))
+   (let ((dir
+          ;; When you hit C-x v d in a visited VC file,
+          ;; the *vc-dir* buffer visits the directory under its truename;
+          ;; therefore it makes sense to always do that.
+          ;; Otherwise if you do C-x v d -> C-x C-f -> C-x v d
+          ;; you may get a new *vc-dir* buffer, different from the original
+          (file-truename
+           (let ((root-dir (vc-root-dir)))
+             (if (and vc-dir-default-directory
+                      (not current-prefix-arg)
+                      (or root-dir (and (stringp vc-dir-default-directory)
+                                        (file-directory-p vc-dir-default-directory))))
+                 (or root-dir vc-dir-default-directory)
+               (read-directory-name "VC status for directory: "
+                                    (vc-root-dir) nil t nil))))))
+     (list dir (if current-prefix-arg
+                   (intern
+                    (completing-read
+                     "Use VC backend: "
+                     (mapcar (lambda (b) (list (symbol-name b)))
+                             vc-handled-backends)
+                     nil t nil nil (symbol-name (ignore-errors
+                                                  (vc-responsible-backend dir)))))))))
   (unless backend
     (setq backend (vc-responsible-backend dir)))
   (let (pop-up-windows)		      ; based on cvs-examine; bug#6204

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sat, 29 Feb 2020 21:52:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Sat, 29 Feb 2020 23:16:01 +0200
>>>> C-x p g - project grep
>>>
>>> Bind project-find-regexp to it?
>>
>> Not sure since project-find-regexp is not asynchronous as grep.
>
> All the more reason for someone to work on that. And the former has
> other benefits.

‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could run:

  git --no-pager grep --color -inH -p -e "search_string"

Then ‘C-x p C-s’ could be bound to ‘project-search’
and ‘C-x p M-%’ to ‘project-query-replace-regexp’.

BTW, why current project commands are not documented
in the Emacs Info manual?  Should they?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 02 Mar 2020 22:12:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 3 Mar 2020 00:11:48 +0200
On 29.02.2020 23:16, Juri Linkov wrote:
>>>>> C-x p g - project grep
>>>>
>>>> Bind project-find-regexp to it?
>>>
>>> Not sure since project-find-regexp is not asynchronous as grep.
>>
>> All the more reason for someone to work on that. And the former has
>> other benefits.
> 
> ‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could run:
> 
>    git --no-pager grep --color -inH -p -e "search_string"

And then we'll have three very similar commands side-by-side in the same 
menu, or on the same prefix?

project-find-regexp is the available backend-agnostic option. You can 
write project-grep, but it would most likely have to work with xargs, 
like former does.

> Then ‘C-x p C-s’ could be bound to ‘project-search’

People are welcome to use it, but it's implementation and UI are 
suboptimal in several respects.

> and ‘C-x p M-%’ to ‘project-query-replace-regexp’.
> 
> BTW, why current project commands are not documented
> in the Emacs Info manual?  Should they?

I don't know. What are the criteria?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 02 Mar 2020 22:19:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>, 12492 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 3 Mar 2020 00:17:56 +0200
On 28.02.2020 0:50, Juri Linkov wrote:
> Given all the discussed constraints (no change in default behavior of
> `C-x v d' is allowed, etc.), I see one way to close this bug report -
> to add a customizable variable:

Why not a new command, like I suggested before? Either way the user 
would have to customize something (a keybinding, in that case).

That aside...

> +(defcustom vc-dir-default-directory nil
> +  "Default directory name for the command `vc-dir'.

Both of these lines look wrong.

VC-Dir already uses the correct directory as the default. What you're 
looking for is to avoid prompting the user.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 02 Mar 2020 23:39:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 03 Mar 2020 00:57:14 +0200
>> Given all the discussed constraints (no change in default behavior of
>> `C-x v d' is allowed, etc.), I see one way to close this bug report -
>> to add a customizable variable:
>
> Why not a new command, like I suggested before? Either way the user would
> have to customize something (a keybinding, in that case).

You can implement a new command in addition to defcustom.
These options are not mutually exclusive.
And the command even could use the new defcustom
in the implementation, e.g.

(defun vc-root-dir ()
  (interactive)
  (let ((vc-dir-default-directory t))
    (call-interactively 'vc-dir) ...

But the command has more unsolved issues:

1. command name - the most natural name would be vc-root-dir,
   but this name is already taken by a non-interactive function.

2. keybinding - there are many contradicting proposals,
   and leaving it unbound is not the best solution.

>> +(defcustom vc-dir-default-directory nil
>> +  "Default directory name for the command `vc-dir'.
>
> Both of these lines look wrong.
>
> VC-Dir already uses the correct directory as the default. What you're
> looking for is to avoid prompting the user.

These details are explained further down in the docstring:

+When nil, `vc-dir' reads a directory name using the minibuffer.
+When non-nil and the current directory is under version control,
+`vc-dir' doesn't ask for a directory name and uses the VC root directory.
+When a string and `vc-dir' is invoked in a directory outside of
+version control, then this string is used as a default directory name.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 02 Mar 2020 23:39:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 03 Mar 2020 01:05:46 +0200
>>>>>> C-x p g - project grep
>>>>>
>>>>> Bind project-find-regexp to it?
>>>>
>>>> Not sure since project-find-regexp is not asynchronous as grep.
>>>
>>> All the more reason for someone to work on that. And the former has
>>> other benefits.
>> ‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could
>> run:
>>    git --no-pager grep --color -inH -p -e "search_string"
>
> And then we'll have three very similar commands side-by-side in the same
> menu, or on the same prefix?

Yes, in the new Project menu.

> project-find-regexp is the available backend-agnostic option. You can write
> project-grep, but it would most likely have to work with xargs, like
> former does.

project-grep could rely on xargs indeed.  But what about vc-grep?
Should it use xargs on ls-files, or the existing command vc-git-grep
should be generalized with a new backend operation e.g. "vc-grep pattern"
that could be implemented by more vc backends?

>> Then ‘C-x p C-s’ could be bound to ‘project-search’
>
> People are welcome to use it, but it's implementation and UI are suboptimal
> in several respects.

Maybe a better option is to implement project-isearch,
i.e. multi-file isearch on all project files?
This is trivial to do with just a call to (multi-isearch-files files)

>> and ‘C-x p M-%’ to ‘project-query-replace-regexp’.
>> BTW, why current project commands are not documented
>> in the Emacs Info manual?  Should they?
>
> I don't know. What are the criteria?

Maybe when is becomes popular enough?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Tue, 03 Mar 2020 11:28:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 3 Mar 2020 13:27:18 +0200
On 03.03.2020 0:57, Juri Linkov wrote:
>>> Given all the discussed constraints (no change in default behavior of
>>> `C-x v d' is allowed, etc.), I see one way to close this bug report -
>>> to add a customizable variable:
>>
>> Why not a new command, like I suggested before? Either way the user would
>> have to customize something (a keybinding, in that case).
> 
> You can implement a new command in addition to defcustom.
> These options are not mutually exclusive.

Sure.

> And the command even could use the new defcustom
> in the implementation, e.g.
> 
> (defun vc-root-dir ()
>    (interactive)
>    (let ((vc-dir-default-directory t))
>      (call-interactively 'vc-dir) ...
> 
> But the command has more unsolved issues:
> 
> 1. command name - the most natural name would be vc-root-dir,
>     but this name is already taken by a non-interactive function.

vc-dir-quick was my idea.

> 2. keybinding - there are many contradicting proposals,
>     and leaving it unbound is not the best solution.

Like mentioned already, I think it's fine unbound. Not worse than having 
a user option. It comes down to the user either customizing the option, 
or binding the command to 'C-x v d' in their init script. We shouldn't 
provide both in the core, though.

>>> +(defcustom vc-dir-default-directory nil
>>> +  "Default directory name for the command `vc-dir'.
>>
>> Both of these lines look wrong.
>>
>> VC-Dir already uses the correct directory as the default. What you're
>> looking for is to avoid prompting the user.
> 
> These details are explained further down in the docstring:

I'm saying both the option name and the first sentence of the docstring 
don't fit its purpose, or the later description.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Tue, 03 Mar 2020 11:34:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 3 Mar 2020 13:33:14 +0200
On 03.03.2020 1:05, Juri Linkov wrote:
>>>>>>> C-x p g - project grep
>>>>>>
>>>>>> Bind project-find-regexp to it?
>>>>>
>>>>> Not sure since project-find-regexp is not asynchronous as grep.
>>>>
>>>> All the more reason for someone to work on that. And the former has
>>>> other benefits.
>>> ‘C-x p s g’ could be bound to a new command ‘M-x project-grep’ that could
>>> run:
>>>     git --no-pager grep --color -inH -p -e "search_string"
>>
>> And then we'll have three very similar commands side-by-side in the same
>> menu, or on the same prefix?
> 
> Yes, in the new Project menu.

I think that would be silly.

> But what about vc-grep?
> Should it use xargs on ls-files, or the existing command vc-git-grep
> should be generalized with a new backend operation e.g. "vc-grep pattern"
> that could be implemented by more vc backends?

If it can be generalized, it can be generalized. But it seems unrelated 
to the current discussion.

>>> Then ‘C-x p C-s’ could be bound to ‘project-search’
>>
>> People are welcome to use it, but it's implementation and UI are suboptimal
>> in several respects.
> 
> Maybe a better option is to implement project-isearch,
> i.e. multi-file isearch on all project files?
> This is trivial to do with just a call to (multi-isearch-files files)

https://pics.me.me/thumb_why-mermegenerator-net-but-why-jackie-chan-meme-meme-50686141.png

project-find-regexp is both faster in most situations, works remotely, 
and provides a decent UI.

You're free to implement any variations of existing commands, and they 
can be good in certain situations, but we shouldn't prefer them over the 
primary command (which has had quite some work put into) for the menu 
placement.

>>> and ‘C-x p M-%’ to ‘project-query-replace-regexp’.
>>> BTW, why current project commands are not documented
>>> in the Emacs Info manual?  Should they?
>>
>> I don't know. What are the criteria?
> 
> Maybe when is becomes popular enough?

That doesn't sound right. We put info into the manual to popularize it, 
not vice versa.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Tue, 03 Mar 2020 13:33:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Tue, 3 Mar 2020 15:31:55 +0200
On 03.03.2020 13:33, Dmitry Gutov wrote:
> You're free to implement any variations of existing commands, and they 
> can be good in certain situations, but we shouldn't prefer them over the 
> primary command (which has had quite some work put into) for the menu 
> placement.

Maybe your point was that it would be sufficiently different to have 
both in the menu.

If so, maybe so.

BTW, I wonder how such project-isearch using multi-isearch-files would 
work in a non-toy project with a sufficiently-rare input.

Even if we take the Emacs project itself, loading all 4000 files into 
Emacs's memory to search through them all is likely to take a lot of time.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 04 Mar 2020 00:11:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Wed, 04 Mar 2020 01:19:46 +0200
> project-find-regexp is both faster in most situations, works remotely, and
> provides a decent UI.

project-find-regexp is not asynchronous whereas vc-git-grep is.

UI of project-find-regexp is non-standard.  A more familiar UI
would be like in occur, for example, as used by noccur-project.

> BTW, I wonder how such project-isearch using multi-isearch-files would work
> in a non-toy project with a sufficiently-rare input.
>
> Even if we take the Emacs project itself, loading all 4000 files into
> Emacs's memory to search through them all is likely to take a lot of time.

No problem at all - trying on the Emacs project:

  (multi-isearch-files (project-files (project-current t)))

is like project-search, but with more convenient UI:
it's easier to type C-s to go to the next occurrence than
to invoke the command M-x fileloop-continue that has no keybinding.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 04 Mar 2020 00:11:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Wed, 04 Mar 2020 01:27:16 +0200
>> But the command has more unsolved issues:
>> 1. command name - the most natural name would be vc-root-dir,
>>     but this name is already taken by a non-interactive function.
>
> vc-dir-quick was my idea.

This name implies its implementation has better performance
over its slower competitor.

>> 2. keybinding - there are many contradicting proposals,
>>     and leaving it unbound is not the best solution.
>
> Like mentioned already, I think it's fine unbound. Not worse than having
> a user option. It comes down to the user either customizing the option, 
> or binding the command to 'C-x v d' in their init script. We shouldn't
> provide both in the core, though.
>
>>>> +(defcustom vc-dir-default-directory nil
>>>> +  "Default directory name for the command `vc-dir'.
>>>
>>> Both of these lines look wrong.
>>>
>>> VC-Dir already uses the correct directory as the default. What you're
>>> looking for is to avoid prompting the user.
>> These details are explained further down in the docstring:
>
> I'm saying both the option name and the first sentence of the docstring
> don't fit its purpose, or the later description.

This option is multi-purpose and one of its possible values is:

  When a string and `vc-dir' is invoked in a directory outside of
  version control, then this string is used as a default directory name.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 04 Mar 2020 11:52:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Wed, 4 Mar 2020 13:51:38 +0200
On 04.03.2020 1:27, Juri Linkov wrote:
>>> But the command has more unsolved issues:
>>> 1. command name - the most natural name would be vc-root-dir,
>>>      but this name is already taken by a non-interactive function.
>>
>> vc-dir-quick was my idea.
> 
> This name implies its implementation has better performance
> over its slower competitor.

vc-dir-instant?

>> I'm saying both the option name and the first sentence of the docstring
>> don't fit its purpose, or the later description.
> 
> This option is multi-purpose and one of its possible values is:
> 
>    When a string and `vc-dir' is invoked in a directory outside of
>    version control, then this string is used as a default directory name.

You got a point there, but that seems like a rare use case (not sure who 
would ever use it). I think the variable would be better named after its 
main use scenario.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 04 Mar 2020 12:06:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Wed, 4 Mar 2020 14:05:27 +0200
On 04.03.2020 1:19, Juri Linkov wrote:
>> project-find-regexp is both faster in most situations, works remotely, and
>> provides a decent UI.
> 
> project-find-regexp is not asynchronous whereas vc-git-grep is.

There's no project-agnostic asynchronous option on the table now.

> UI of project-find-regexp is non-standard.  A more familiar UI
> would be like in occur, for example, as used by noccur-project.

It is standard enough, Xref commands use it. And they have both default 
key bindings and menu items.

noccur-project like this naive implementation? 
https://nicolas.petton.fr/blog/mutli-occur-on-projects.html

How long does it take to search the Emacs project for an arbitrary 
string on your machine?

Not to mention the unfortunate side-effect of having to visit 4000 buffers.

If you have a better implementation in mind, I will certainly try it.

>> BTW, I wonder how such project-isearch using multi-isearch-files would work
>> in a non-toy project with a sufficiently-rare input.
>>
>> Even if we take the Emacs project itself, loading all 4000 files into
>> Emacs's memory to search through them all is likely to take a lot of time.
> 
> No problem at all - trying on the Emacs project:
> 
>    (multi-isearch-files (project-files (project-current t)))
> 
> is like project-search, but with more convenient UI:
> it's easier to type C-s to go to the next occurrence than
> to invoke the command M-x fileloop-continue that has no keybinding.

"like project-search" also implies "to take a lot of time", that's where 
I made that conclusion from. How long does it take for the UI to say "no 
matches"?

The UI is probably better (the main thing I like about this idea), but 
the downside is opening several buffers with intermediate matches for 
incomplete input (while you're still typing the search string). Though I 
don't know how serious of a problem that is.

And when I try this, I'm getting messages about uncompressing files, and 
prompts about local variables, which I can't answer.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 05 Mar 2020 00:23:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Thu, 05 Mar 2020 02:04:38 +0200
>>> project-find-regexp is both faster in most situations, works remotely, and
>>> provides a decent UI.
>> project-find-regexp is not asynchronous whereas vc-git-grep is.
>
> There's no project-agnostic asynchronous option on the table now.

Only getting project file names should be synchronous and blocking,
everything else (including grepping) could be asynchronous.

>> UI of project-find-regexp is non-standard.  A more familiar UI
>> would be like in occur, for example, as used by noccur-project.
>
> It is standard enough, Xref commands use it. And they have both default key
> bindings and menu items.
>
> noccur-project like this naive implementation?
> https://nicolas.petton.fr/blog/mutli-occur-on-projects.html

It works fine as a proof of concept.

> How long does it take to search the Emacs project for an arbitrary string
> on your machine?

The result is almost instantaneous: 1 sec on Emacs repo.

> Not to mention the unfortunate side-effect of having to visit 4000 buffers.

It visits only matched buffers.

>>> BTW, I wonder how such project-isearch using multi-isearch-files would work
>>> in a non-toy project with a sufficiently-rare input.
>>>
>>> Even if we take the Emacs project itself, loading all 4000 files into
>>> Emacs's memory to search through them all is likely to take a lot of time.
>> No problem at all - trying on the Emacs project:
>>    (multi-isearch-files (project-files (project-current t)))
>> is like project-search, but with more convenient UI:
>> it's easier to type C-s to go to the next occurrence than
>> to invoke the command M-x fileloop-continue that has no keybinding.
>
> "like project-search" also implies "to take a lot of time", that's where
> I made that conclusion from. How long does it take for the UI to say "no
> matches"?

Depends on the search string.

> The UI is probably better (the main thing I like about this idea), but the
> downside is opening several buffers with intermediate matches for
> incomplete input (while you're still typing the search string). Though I
> don't know how serious of a problem that is.

Probably multi-isearch-files could be useful for projects
with small number of files.

> And when I try this, I'm getting messages about uncompressing files, and
> prompts about local variables, which I can't answer.

OT1H, an ability to search in compressed files is an advantage -
even grep can't search in compressed files.  OTOH, it had to visit
all files - this is its downside.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 05 Mar 2020 00:23:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Thu, 05 Mar 2020 02:06:56 +0200
>>>> But the command has more unsolved issues:
>>>> 1. command name - the most natural name would be vc-root-dir,
>>>>      but this name is already taken by a non-interactive function.
>>>
>>> vc-dir-quick was my idea.
>> This name implies its implementation has better performance
>> over its slower competitor.
>
> vc-dir-instant?

vc-dir-with-the-speed-of-light :)

>>> I'm saying both the option name and the first sentence of the docstring
>>> don't fit its purpose, or the later description.
>> This option is multi-purpose and one of its possible values is:
>>    When a string and `vc-dir' is invoked in a directory outside of
>>    version control, then this string is used as a default directory name.
>
> You got a point there, but that seems like a rare use case (not sure who
> would ever use it). I think the variable would be better named after its 
> main use scenario.

Yeah, this is a secondary feature, not sure if it's needed.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 05 Mar 2020 23:16:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 6 Mar 2020 01:15:10 +0200
On 05.03.2020 2:04, Juri Linkov wrote:
>>>> project-find-regexp is both faster in most situations, works remotely, and
>>>> provides a decent UI.
>>> project-find-regexp is not asynchronous whereas vc-git-grep is.
>>
>> There's no project-agnostic asynchronous option on the table now.
> 
> Only getting project file names should be synchronous and blocking,
> everything else (including grepping) could be asynchronous.

The API indeed allows it, but there are no good UIs with that support 
that we can use. But you're welcome to fix/improve/write one.

>>> UI of project-find-regexp is non-standard.  A more familiar UI
>>> would be like in occur, for example, as used by noccur-project.
>>
>> It is standard enough, Xref commands use it. And they have both default key
>> bindings and menu items.
>>
>> noccur-project like this naive implementation?
>> https://nicolas.petton.fr/blog/mutli-occur-on-projects.html
> 
> It works fine as a proof of concept.

Not if I have to wait for >1 minute for the UI to show up. Or I don't 
know how long, I never managed to muster enough patience to get past all 
the 'local variables' prompts.

>> How long does it take to search the Emacs project for an arbitrary string
>> on your machine?
> 
> The result is almost instantaneous: 1 sec on Emacs repo.

I don't understand how that's possible: it's much longer than that on my 
machine, and I have a fast laptop manufactured last year, with NVMe and 
stuff.

>> Not to mention the unfortunate side-effect of having to visit 4000 buffers.
> 
> It visits only matched buffers.

No. It looks through all project files and calls 'find-file' on each of 
them. Which is obviously inevitable since multi-occur only accepts a 
list of buffers, not files.

>>>     (multi-isearch-files (project-files (project-current t)))
>>> is like project-search, but with more convenient UI:
>>> it's easier to type C-s to go to the next occurrence than
>>> to invoke the command M-x fileloop-continue that has no keybinding.
>>
>> "like project-search" also implies "to take a lot of time", that's where
>> I made that conclusion from. How long does it take for the UI to say "no
>> matches"?
> 
> Depends on the search string.

To sum up: project-isearch could be a fine addition, but not the "main" 
search command to recommend to our users.

>> And when I try this, I'm getting messages about uncompressing files, and
>> prompts about local variables, which I can't answer.
> 
> OT1H, an ability to search in compressed files is an advantage -
> even grep can't search in compressed files.  OTOH, it had to visit
> all files - this is its downside.

zgrep can probably do that. Much faster, too.

Anyway, if you want to continue this chat, could you file a relevant 
bug, or post to emacs-devel?

All of this is certainly not about vc-dir anymore.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 06 Mar 2020 00:06:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 06 Mar 2020 01:59:49 +0200
>> Only getting project file names should be synchronous and blocking,
>> everything else (including grepping) could be asynchronous.
>
> The API indeed allows it, but there are no good UIs with that support that
> we can use. But you're welcome to fix/improve/write one.

rgrep/vc-git-grep provides good UI.

>> The result is almost instantaneous: 1 sec on Emacs repo.
>
> I don't understand how that's possible: it's much longer than that on my
> machine, and I have a fast laptop manufactured last year, with NVMe and 
> stuff.

The speed depends on the number of files with matches.
It's quick when matches are in a few files.

>>> Not to mention the unfortunate side-effect of having to visit 4000 buffers.
>> It visits only matched buffers.
>
> No. It looks through all project files and calls 'find-file' on each of
> them. Which is obviously inevitable since multi-occur only accepts a 
> list of buffers, not files.

No, it doesn't call 'find-file' on each file, noccur-project
calls 'find-file' only on files with matches found by grep.

> Anyway, if you want to continue this chat, could you file a relevant bug,
> or post to emacs-devel?
>
> All of this is certainly not about vc-dir anymore.

Regarding vc-dir, I see no better name than 'vc-dir-default'
meaning that it uses root-dir by default.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 06 Mar 2020 09:41:02 GMT) Full text and rfc822 format available.

Message #210 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: Fri, 06 Mar 2020 11:40:07 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 3 Mar 2020 00:11:48 +0200
> Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
> 
> > BTW, why current project commands are not documented
> > in the Emacs Info manual?  Should they?
> 
> I don't know. What are the criteria?

We could start by coming up with a list of commands and the use cases
where these commands are useful.  Then we could reason whether these
are important enough to add to the manual.

Do we have in core any feature that provides back-end for the
project.el infrastructure?  It sounds like we only support VC as
back-end in project.el, is that true?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 06 Mar 2020 15:34:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Fri, 6 Mar 2020 17:33:30 +0200
On 06.03.2020 1:59, Juri Linkov wrote:
> Regarding vc-dir, I see no better name than 'vc-dir-default'
> meaning that it uses root-dir by default.

But the question is not what the default is (which will be VC root), but 
whether to prompt the user or use that value right away.

So I was thinking more along the lines of vc-dir-prompt-p. Or, more 
verbosely, vc-dir-prompt-for-directory.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 06 Mar 2020 16:02:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Fri, 6 Mar 2020 18:01:25 +0200
On 06.03.2020 11:40, Eli Zaretskii wrote:

> We could start by coming up with a list of commands and the use cases
> where these commands are useful.  Then we could reason whether these
> are important enough to add to the manual.

project-find-file and project-find-regexp are the main ones. Useful 
when... you want to visit a file within the current project, or search 
it for a regexp?

xref-query-replace-in-results could also be mentioned, given that it 
allows the user to replace the matches with some other string (both in 
project-find-regexp output, and in xref-find-references output).

> Do we have in core any feature that provides back-end for the
> project.el infrastructure?  It sounds like we only support VC as
> back-end in project.el, is that true?

It's extensible via project-find-functions, which was the core design goal.

In the core, we have only two backends indeed: one using VC, and another 
for EDE.

Though I'm not sure if the latter has any users, and its implementation 
is very simplistic.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 06 Mar 2020 16:15:02 GMT) Full text and rfc822 format available.

Message #219 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: Fri, 06 Mar 2020 18:14:28 +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:01:25 +0200
> 
> On 06.03.2020 11:40, Eli Zaretskii wrote:
> 
> > We could start by coming up with a list of commands and the use cases
> > where these commands are useful.  Then we could reason whether these
> > are important enough to add to the manual.
> 
> project-find-file and project-find-regexp are the main ones. Useful 
> when... you want to visit a file within the current project, or search 
> it for a regexp?
> 
> xref-query-replace-in-results could also be mentioned, given that it 
> allows the user to replace the matches with some other string (both in 
> project-find-regexp output, and in xref-find-references output).
> 
> > Do we have in core any feature that provides back-end for the
> > project.el infrastructure?  It sounds like we only support VC as
> > back-end in project.el, is that true?
> 
> It's extensible via project-find-functions, which was the core design goal.
> 
> In the core, we have only two backends indeed: one using VC, and another 
> for EDE.
> 
> Though I'm not sure if the latter has any users, and its implementation 
> is very simplistic.

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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 06 Mar 2020 16:54:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: 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.

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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 06 Mar 2020 17:13:02 GMT) Full text and rfc822 format available.

Message #225 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: 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 06 Mar 2020 22:35:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sat, 7 Mar 2020 00:34:36 +0200
On 06.03.2020 19:12, Eli Zaretskii wrote:
> For starters, how do you explain what a "project" is, when
> the only example we can give is a repository?

The way we should either way: with a higher level description.

Something like:

A project is set of files. Which we usually define through a list of 
directories where the files reside, and a list of ignore rules that 
exclude some files within said directories from being considered a part 
of the project.

The above information is provided by the project backend that is in use. 
The main backend supplied with Emacs is based on VC, and it uses 
repository markers and associated ignore files (as well as the 
`project-vc-ignores` variable).

> 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.

As long as it doesn't say that a project is a VC repository.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sat, 07 Mar 2020 07:38:01 GMT) Full text and rfc822 format available.

Message #231 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: Sat, 07 Mar 2020 09:37:09 +0200
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 7 Mar 2020 00:34:36 +0200
> 
> On 06.03.2020 19:12, Eli Zaretskii wrote:
> > For starters, how do you explain what a "project" is, when
> > the only example we can give is a repository?
> 
> The way we should either way: with a higher level description.
> 
> Something like:
> 
> A project is set of files. Which we usually define through a list of 
> directories where the files reside, and a list of ignore rules that 
> exclude some files within said directories from being considered a part 
> of the project.

This is too abstract: it doesn't tell the reader how to "create a
project".  Without knowing that, all the rest of the information about
the commands is mostly useless, because the commands cannot be used in
practice.

> The above information is provided by the project backend that is in use. 
> The main backend supplied with Emacs is based on VC, and it uses 
> repository markers and associated ignore files (as well as the 
> `project-vc-ignores` variable).

Still falls short of clarifying the above.

We are talking about the Emacs User manual.  The project API is
extensible on the Lisp programmer level, not on the user level.  So
the user-level information should describe what is available to users;
too much abstractions is inappropriate.

> > 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.
> 
> As long as it doesn't say that a project is a VC repository.

But with the VC back-end, it really is, isn't it?  Then why not say
that the type of project supported by Emacs OOTB is a VCS repository?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 08 Mar 2020 00:50:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sun, 8 Mar 2020 02:49:24 +0200
On 07.03.2020 9:37, Eli Zaretskii wrote:

>> Something like:
>>
>> A project is set of files. Which we usually define through a list of
>> directories where the files reside, and a list of ignore rules that
>> exclude some files within said directories from being considered a part
>> of the project.
> 
> This is too abstract: it doesn't tell the reader how to "create a
> project".  Without knowing that, all the rest of the information about
> the commands is mostly useless, because the commands cannot be used in
> practice.

We don't provide a command to create a project, and we probably won't in 
the future either.

I disagree about useless, since most users deal with existing projects 
99% of the time. But I can see how a manual would seem incomplete 
without such information. It doesn't have to be contained in the 
definition of "what is a project", however.

> We are talking about the Emacs User manual.  The project API is
> extensible on the Lisp programmer level, not on the user level.  So
> the user-level information should describe what is available to users;
> too much abstractions is inappropriate.

Still, I'd prefer if it did that without conflating the terms.

>>> 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.
>>
>> As long as it doesn't say that a project is a VC repository.
> 
> But with the VC back-end, it really is, isn't it?

The relation is reverse (all repositories are projects, but not all 
projects are repositories), but yes.

> Then why not say
> that the type of project supported by Emacs OOTB is a VCS repository?

Sure, we can say that. Maybe also add an adjective like "main" (the main 
type of project ...), since EDE is also a part of Emacs.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 08 Mar 2020 01:06:01 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Sun, 08 Mar 2020 02:47:57 +0200
>> Regarding vc-dir, I see no better name than 'vc-dir-default'
>> meaning that it uses root-dir by default.
>
> But the question is not what the default is (which will be VC root), but
> whether to prompt the user or use that value right away.
>
> So I was thinking more along the lines of vc-dir-prompt-p. Or, more
> verbosely, vc-dir-prompt-for-directory.

'vc-dir-default' was intended both as option name and command name,
so users can choose either to customize it, or bind 'C-x v d' to command.

'vc-dir-root' may be a better name.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 08 Mar 2020 09:58:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Sun, 8 Mar 2020 11:57:37 +0200
On 08.03.2020 2:47, Juri Linkov wrote:
> 'vc-dir-default' was intended both as option name and command name,
> so users can choose either to customize it, or bind 'C-x v d' to command.
> 
> 'vc-dir-root' may be a better name.

I think both of these work better as the command name. I also like 
vc-dir-root best.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 09 Mar 2020 17:25:01 GMT) Full text and rfc822 format available.

Message #243 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, 09 Mar 2020 19:24:46 +0200
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sun, 8 Mar 2020 02:49:24 +0200
> 
> >> A project is set of files. Which we usually define through a list of
> >> directories where the files reside, and a list of ignore rules that
> >> exclude some files within said directories from being considered a part
> >> of the project.
> > 
> > This is too abstract: it doesn't tell the reader how to "create a
> > project".  Without knowing that, all the rest of the information about
> > the commands is mostly useless, because the commands cannot be used in
> > practice.
> 
> We don't provide a command to create a project, and we probably won't in 
> the future either.

I don't think having commands to create a project is really
necessary.  If a project can be "created" by some external command,
like by placing some special file in the project root, or even by
defining a few Emacs variables, that is enough.

> I disagree about useless, since most users deal with existing projects 
> 99% of the time.

In Emacs?  Can you give examples of such existing projects, and how
users could use the commands we are discussing with those projects?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 09 Mar 2020 22:48:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Tue, 10 Mar 2020 00:47:36 +0200
On 09.03.2020 19:24, Eli Zaretskii wrote:

> I don't think having commands to create a project is really
> necessary.  If a project can be "created" by some external command,
> like by placing some special file in the project root, or even by
> defining a few Emacs variables, that is enough.

'git init' would do the trick. No extra files (for the VC project 
backend, at least), nor having to change any variables.

>> I disagree about useless, since most users deal with existing projects
>> 99% of the time.
> 
> In Emacs?  Can you give examples of such existing projects,

An Emacs repository checkout itself, for instance? Or about any other 
project where VC recognizes a root.

> and how
> users could use the commands we are discussing with those projects?

With 'M-x project-find-file' or 'M-x project-find-regexp' while being 
inside the directory tree of any of such projects.

I thought you've tried and used these commands already.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Tue, 10 Mar 2020 18:19:01 GMT) Full text and rfc822 format available.

Message #249 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: Tue, 10 Mar 2020 20:18:23 +0200
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Tue, 10 Mar 2020 00:47:36 +0200
> 
> On 09.03.2020 19:24, Eli Zaretskii wrote:
> 
> > I don't think having commands to create a project is really
> > necessary.  If a project can be "created" by some external command,
> > like by placing some special file in the project root, or even by
> > defining a few Emacs variables, that is enough.
> 
> 'git init' would do the trick. No extra files (for the VC project 
> backend, at least), nor having to change any variables.
> 
> >> I disagree about useless, since most users deal with existing projects
> >> 99% of the time.
> > 
> > In Emacs?  Can you give examples of such existing projects,
> 
> An Emacs repository checkout itself, for instance? Or about any other 
> project where VC recognizes a root.
> 
>  > and how
>  > users could use the commands we are discussing with those projects?
> 
> With 'M-x project-find-file' or 'M-x project-find-regexp' while being 
> inside the directory tree of any of such projects.

OK, my misunderstanding: I asked all those questions because I thought
you were saying these commands are used with projects other than VC
projects.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 11 Mar 2020 13:37:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Wed, 11 Mar 2020 15:35:58 +0200
On 10.03.2020 20:18, Eli Zaretskii wrote:
> OK, my misunderstanding: I asked all those questions because I thought
> you were saying these commands are used with projects other than VC
> projects.

That's the main purpose of this package: to have an extension point that 
allows us to write commands in such a way that would work with 
potentially any kind of projects, as long as the [third-party] project 
implementation makes an effort to interface.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 11 Mar 2020 16:15:02 GMT) Full text and rfc822 format available.

Message #255 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: Wed, 11 Mar 2020 18:14:13 +0200
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 11 Mar 2020 15:35:58 +0200
> 
> On 10.03.2020 20:18, Eli Zaretskii wrote:
> > OK, my misunderstanding: I asked all those questions because I thought
> > you were saying these commands are used with projects other than VC
> > projects.
> 
> That's the main purpose of this package: to have an extension point that 
> allows us to write commands in such a way that would work with 
> potentially any kind of projects, as long as the [third-party] project 
> implementation makes an effort to interface.

Of course, but this loses context: we were discussing whether and how
to document these commands in the user manual.  For that manual,
extensions that exist only in theory are not really relevant.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Wed, 11 Mar 2020 23:55:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Thu, 12 Mar 2020 01:54:30 +0200
On 11.03.2020 18:14, Eli Zaretskii wrote:

>> That's the main purpose of this package: to have an extension point that
>> allows us to write commands in such a way that would work with
>> potentially any kind of projects, as long as the [third-party] project
>> implementation makes an effort to interface.
> 
> Of course, but this loses context: we were discussing whether and how
> to document these commands in the user manual.  For that manual,
> extensions that exist only in theory are not really relevant.

What if an extension materializes right after Emacs 27's release?

E.g. it's not hard to write a good project.el backend that uses 
Projectile (a popular third-party package for project-related 
functionality). Actually, a couple of ad-hoc integrations are already 
floating around. I should probably write [a better] one myself. And 
right after the release seems like a good time.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Thu, 12 Mar 2020 14:58:01 GMT) Full text and rfc822 format available.

Message #261 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: Thu, 12 Mar 2020 16:57:07 +0200
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Thu, 12 Mar 2020 01:54:30 +0200
> 
> On 11.03.2020 18:14, Eli Zaretskii wrote:
> 
> >> That's the main purpose of this package: to have an extension point that
> >> allows us to write commands in such a way that would work with
> >> potentially any kind of projects, as long as the [third-party] project
> >> implementation makes an effort to interface.
> > 
> > Of course, but this loses context: we were discussing whether and how
> > to document these commands in the user manual.  For that manual,
> > extensions that exist only in theory are not really relevant.
> 
> What if an extension materializes right after Emacs 27's release?

How can we describe such an extension in advance in the user manual?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 13 Mar 2020 12:25:02 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Fri, 13 Mar 2020 14:23:51 +0200
On 12.03.2020 16:57, Eli Zaretskii wrote:

>>> Of course, but this loses context: we were discussing whether and how
>>> to document these commands in the user manual.  For that manual,
>>> extensions that exist only in theory are not really relevant.
>>
>> What if an extension materializes right after Emacs 27's release?
> 
> 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.

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.

I'm not insisting or anything, but that's how I'd do it. How do we 
document completion-at-point, for instance? It's also extensible.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Fri, 13 Mar 2020 14:32:02 GMT) Full text and rfc822 format available.

Message #267 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: Fri, 13 Mar 2020 16:30:31 +0200
> 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.

> 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.

> 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").




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sun, 15 Mar 2020 21:58:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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: 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?

Keeping a certain level of abstraction is a good thing.

>> 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?

>> 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)?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 16 Mar 2020 03:26:02 GMT) Full text and rfc822 format available.

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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 16 Mar 2020 08:04:01 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
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 10:02:58 +0200
On 16.03.2020 5:25, Eli Zaretskii wrote:
> 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.

In that case, let's stop here. We can continue if/when you decide to add 
the manual entries upon discussion.

I hope that I made doing that that at least a little easier in the 
preceding discussion.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Sat, 21 Mar 2020 11:29:02 GMT) Full text and rfc822 format available.

Message #279 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: Sat, 21 Mar 2020 13:28:00 +0200
> Cc: 12492 <at> debbugs.gnu.org, larsi <at> gnus.org, juri <at> linkov.net
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Mon, 16 Mar 2020 10:02:58 +0200
> 
> On 16.03.2020 5:25, Eli Zaretskii wrote:
> > 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.
> 
> In that case, let's stop here. We can continue if/when you decide to add 
> the manual entries upon discussion.

Done, please take a look.  (I also found some issues/problems with
project.el itself, and fixed what I found.)

> I hope that I made doing that that at least a little easier in the 
> preceding discussion.

You did, thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#12492; Package emacs. (Mon, 30 Mar 2020 02:36:24 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 12492 <at> debbugs.gnu.org,  Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Sun, 29 Mar 2020 02:08:29 +0200
>> 'vc-dir-default' was intended both as option name and command name,
>> so users can choose either to customize it, or bind 'C-x v d' to command.
>> 'vc-dir-root' may be a better name.
>
> I think both of these work better as the command name. I also like
> vc-dir-root best.

vc-dir-root is now pushed to master without keybinding as discussed
in bug#34949.

Please close this report if you think everything is done here.




Reply sent to Dmitry Gutov <dgutov <at> yandex.ru>:
You have taken responsibility. (Mon, 30 Mar 2020 02:36:50 GMT) Full text and rfc822 format available.

Notification sent to Dmitry Gutov <dgutov <at> yandex.ru>:
bug acknowledged by developer. (Mon, 30 Mar 2020 02:36:50 GMT) Full text and rfc822 format available.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: 12492-done <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier
 and faster)
Date: Sun, 29 Mar 2020 14:09:46 +0300
On 29.03.2020 02:08, Juri Linkov wrote:
> vc-dir-root is now pushed to master without keybinding as discussed
> in bug#34949.

Yes, it's all good. Thanks Juri!

> Please close this report if you think everything is done here.

I remembered why I called it vc-dir-quick, though: aside from using the 
root, it avoids refreshing pre-existing vc-dir buffer, which was an 
important improvement for me at the time (these days--less so). But this 
can be introduced as an option in a separate discussion.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 27 Apr 2020 11:24:11 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 337 days ago.

Previous Next


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