bug#12492: 24.2.50; Open vc-dir buffer easier and faster

bug#12492: 24.2.50; Open vc-dir buffer easier and faster

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

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.

[-- Attachment #2: vc-dir.diff --]
[-- Type: text/plain, Size: 2297 bytes --]

=== modified file 'lisp/vc/vc-dir.el'
--- lisp/vc/vc-dir.el	2012-08-13 21:31:56 +0000
+++ lisp/vc/vc-dir.el	2012-09-22 22:43:38 +0000
@@ -1227,12 +1227,25 @@
     (setq backend (vc-responsible-backend dir)))
   (let (pop-up-windows)		      ; based on cvs-examine; bug#6204
     (pop-to-buffer (vc-dir-prepare-status-buffer "*vc-dir*" dir backend)))
-  (if (derived-mode-p 'vc-dir-mode)
-      (vc-dir-refresh)
+  ;; If the mode matches, the buffer was only buried and should be up to date.
+  (unless (derived-mode-p 'vc-dir-mode)
     ;; FIXME: find a better way to pass the backend to `vc-dir-mode'.
     (let ((use-vc-backend backend))
       (vc-dir-mode))))
 
+;;;###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."
+  (interactive)
+  (let* ((backend (vc-backend (buffer-file-name)))
+         (dir (and backend (vc-call-backend backend 'root buffer-file-name))))
+    (if dir
+        (vc-dir dir backend)
+      (call-interactively 'vc-dir))))
+
 (defun vc-default-dir-extra-headers (_backend _dir)
   ;; Be loud by default to remind people to add code to display
   ;; backend specific headers.

=== modified file 'lisp/vc/vc-hooks.el'
--- lisp/vc/vc-hooks.el	2012-07-11 23:13:41 +0000
+++ lisp/vc/vc-hooks.el	2012-09-22 21:31:00 +0000
@@ -923,7 +923,7 @@
     (define-key map "a" 'vc-update-change-log)
     (define-key map "b" 'vc-switch-backend)
     (define-key map "c" 'vc-rollback)
-    (define-key map "d" 'vc-dir)
+    (define-key map "d" 'vc-root-dir)
     (define-key map "g" 'vc-annotate)
     (define-key map "h" 'vc-insert-headers)
     (define-key map "i" 'vc-register)
@@ -1005,9 +1005,9 @@
     (bindings--define-key map [vc-register]
       '(menu-item "Register" vc-register
 		  :help "Register file set into a version control system"))
-    (bindings--define-key map [vc-dir]
-      '(menu-item "VC Dir"  vc-dir
-		  :help "Show the VC status of files in a directory"))
+    (bindings--define-key map [vc-root-dir]
+      '(menu-item "VC Dir"  vc-root-dir
+		  :help "Show the VC status of the repository"))
     map))
 
 (defalias 'vc-menu-map vc-menu-map)

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 36 bytes --]

Same patch, with ChangeLog entries.

[-- Attachment #2: vc-dir.diff --]
[-- Type: text/plain, Size: 2784 bytes --]

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2012-09-22 15:24:26 +0000
+++ lisp/ChangeLog	2012-09-22 23:29:54 +0000
@@ -1,3 +1,11 @@
+2012-09-22  Dmitry Gutov  <dgutov@yandex.ru>
+
+	* vc/vc-hooks.el (vc-prefix-map): Bind vc-root-dir to "d".
+	(vc-menu-map): Make "VC Dir" menu item call vc-root-dir.
+
+	* vc/vc-dir.el (vc-dir): Don't refresh the buffer.
+	(vc-root-dir): New function.
+
 2012-09-22  Chong Yidong  <cyd@gnu.org>
 
 	* repeat.el (repeat): Doc fix (Bug#12348).

=== modified file 'lisp/vc/vc-dir.el'
--- lisp/vc/vc-dir.el	2012-08-13 21:31:56 +0000
+++ lisp/vc/vc-dir.el	2012-09-22 23:25:15 +0000
@@ -1227,12 +1227,25 @@
     (setq backend (vc-responsible-backend dir)))
   (let (pop-up-windows)		      ; based on cvs-examine; bug#6204
     (pop-to-buffer (vc-dir-prepare-status-buffer "*vc-dir*" dir backend)))
-  (if (derived-mode-p 'vc-dir-mode)
-      (vc-dir-refresh)
+  ;; If the mode matches, the buffer was only buried and should be up to date.
+  (unless (derived-mode-p 'vc-dir-mode)
     ;; FIXME: find a better way to pass the backend to `vc-dir-mode'.
     (let ((use-vc-backend backend))
       (vc-dir-mode))))
 
+;;;###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."
+  (interactive)
+  (let* ((backend (vc-backend (buffer-file-name)))
+         (dir (and backend (vc-call-backend backend 'root buffer-file-name))))
+    (if dir
+        (vc-dir dir backend)
+      (call-interactively 'vc-dir))))
+
 (defun vc-default-dir-extra-headers (_backend _dir)
   ;; Be loud by default to remind people to add code to display
   ;; backend specific headers.

=== modified file 'lisp/vc/vc-hooks.el'
--- lisp/vc/vc-hooks.el	2012-07-11 23:13:41 +0000
+++ lisp/vc/vc-hooks.el	2012-09-22 23:25:58 +0000
@@ -923,7 +923,7 @@
     (define-key map "a" 'vc-update-change-log)
     (define-key map "b" 'vc-switch-backend)
     (define-key map "c" 'vc-rollback)
-    (define-key map "d" 'vc-dir)
+    (define-key map "d" 'vc-root-dir)
     (define-key map "g" 'vc-annotate)
     (define-key map "h" 'vc-insert-headers)
     (define-key map "i" 'vc-register)
@@ -1005,9 +1005,9 @@
     (bindings--define-key map [vc-register]
       '(menu-item "Register" vc-register
 		  :help "Register file set into a version control system"))
-    (bindings--define-key map [vc-dir]
-      '(menu-item "VC Dir"  vc-dir
-		  :help "Show the VC status of files in a directory"))
+    (bindings--define-key map [vc-root-dir]
+      '(menu-item "VC Dir"  vc-root-dir
+		  :help "Show the VC status of the repository"))
     map))
 
 (defalias 'vc-menu-map vc-menu-map)

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

>> +;;;###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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Lars Ingebrigtsen]

Juri Linkov <juri@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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Lars Ingebrigtsen]

Juri Linkov <juri@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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Lars Ingebrigtsen]

Juri Linkov <juri@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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

On 05.07.2019 16:09, Lars Ingebrigtsen wrote:
> Juri Linkov <juri@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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Lars Ingebrigtsen]

Juri Linkov <juri@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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#41779: Fall back between vc-diff and diff-backup

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

Tags: patch

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

Now this annoyance finally got me - using these keys throws an error
most of the time: when files are not yet registered in vc I use `M-=',
but after registering them in vc, I continue typing the same key `M-='
and get that annoying error.  The situation with `C-x v =' is not better:
often after forgetting that a file is not yet under vc control, typing
`C-x v =' raises the same error.  Therefore, this patch to the rescue:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vc-diff-backup.patch --]
[-- Type: text/x-diff, Size: 1815 bytes --]

diff --git a/lisp/vc/diff.el b/lisp/vc/diff.el
index 9e7e771963..c94c442af8 100644
--- a/lisp/vc/diff.el
+++ b/lisp/vc/diff.el
@@ -230,10 +233,16 @@ diff-backup
     (if (backup-file-name-p file)
 	(setq bak file
 	      ori (file-name-sans-versions file))
-      (setq bak (or (diff-latest-backup-file file)
-		    (error "No backup found for %s" file))
+      (setq bak (diff-latest-backup-file file)
 	    ori file))
-    (diff bak ori switches)))
+    (if bak
+        (diff bak ori switches)
+      ;; Fall back to vc-diff
+      (if (vc-backend file)
+          (let ((vc-diff-switches switches))
+            (vc-diff-internal
+             t (list (vc-backend file) (list file)) nil nil t))
+        (error "No backup found for %s" file)))))
 
 ;;;###autoload
 (defun diff-latest-backup-file (fn)
diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index c640ba0420..a0363bd774 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -1888,11 +1890,15 @@ vc-diff
 The optional argument NOT-URGENT non-nil means it is ok to say no to
 saving the buffer."
   (interactive (list current-prefix-arg t))
-  (if historic
-      (call-interactively 'vc-version-diff)
-    (when buffer-file-name (vc-buffer-sync not-urgent))
-    (vc-diff-internal t (vc-deduce-fileset t) nil nil
-		      (called-interactively-p 'interactive))))
+  (if (vc-deduce-backend)
+      (if historic
+          (call-interactively 'vc-version-diff)
+        (when buffer-file-name (vc-buffer-sync not-urgent))
+        (vc-diff-internal t (vc-deduce-fileset t) nil nil
+		          (called-interactively-p 'interactive)))
+    ;; Fall back to non-vc diff-backup
+    (diff-backup (if (derived-mode-p 'dired-mode) (dired-get-filename) buffer-file-name)
+                 vc-diff-switches)))
 
 ;;;###autoload
 (defun vc-diff-mergebase (_files rev1 rev2)

bug#41779: Fall back between vc-diff and diff-backup

[Dmitry Gutov]

On 10.06.2020 02:35, Juri Linkov wrote:
>   Therefore, this patch to the rescue:

Considering that 'M-=' is not a default binding, and diff-backup doesn't 
have one, how about creating a new command? You could just as well bind 
it to 'M-='.

The command could be called 'diff-dwim'. Or 'diff-vc-or-backup'.

Regarding the proposed patch, I'm somewhat uneasy making 'vc-diff' (the 
command which purpose is to compare edits against the "saved" snapshot 
in version control) diff against the backup (lifetime of which is very 
unclear to me). Or vice versa.

bug#41779: Fall back between vc-diff and diff-backup

[Juri Linkov]

> Considering that 'M-=' is not a default binding, and diff-backup doesn't
> have one, how about creating a new command? You could just as well bind 
> it to 'M-='.
>
> The command could be called 'diff-dwim'. Or 'diff-vc-or-backup'.
>
> Regarding the proposed patch, I'm somewhat uneasy making 'vc-diff' (the
> command which purpose is to compare edits against the "saved" snapshot 
> in version control) diff against the backup (lifetime of which is very
> unclear to me). Or vice versa.

Why do you think that throwing an error is more useful than doing
some nice fallback?

bug#41779: Fall back between vc-diff and diff-backup

[Dmitry Gutov]

On 11.06.2020 00:53, Juri Linkov wrote:
> Why do you think that throwing an error is more useful than doing
> some nice fallback?

It's... imprecise? Like, if I'm using the 'C-x v' prefix, I expect to 
work against a VC repository. Having a command like that succeed despite 
the lack of said repository could give a wrong impression to the user.

Not a big problem, but the cost of implementing a different solution 
doesn't seem to be high either.

Admittedly, I use diff-backup very rarely (though it does happen from 
time to time), so I might not understand your usage scenarios well.

bug#41779: Fall back between vc-diff and diff-backup

[Juri Linkov]

>> Why do you think that throwing an error is more useful than doing
>> some nice fallback?
>
> It's... imprecise? Like, if I'm using the 'C-x v' prefix, I expect to work
> against a VC repository. Having a command like that succeed despite the
> lack of said repository could give a wrong impression to the user.
>
> Not a big problem, but the cost of implementing a different solution
> doesn't seem to be high either.
>
> Admittedly, I use diff-backup very rarely (though it does happen from time
> to time), so I might not understand your usage scenarios well.

So for the normal usage, users won't notice this additional feature,
and in case of the user error it comes to the rescue.

But I don't insist on this feature, I can handle this in my init file.
I proposed it as a patch only because Lars mentioned the same problem.

bug#41779: Fall back between vc-diff and diff-backup

[Dmitry Gutov]

On 11.06.2020 02:17, Juri Linkov wrote:
> So for the normal usage, users won't notice this additional feature,
> and in case of the user error it comes to the rescue.

In a way that is likely to make the user miss the fact that there was a 
misconception.

> But I don't insist on this feature, I can handle this in my init file.
> I proposed it as a patch only because Lars mentioned the same problem.

I think my suggestion is not significantly worse or more awkward to use.

bug#41779: Fall back between vc-diff and diff-backup

[Juri Linkov]

tags 41779 wontfix
close 41779 28.0.50
quit

>> But I don't insist on this feature, I can handle this in my init file.
>> I proposed it as a patch only because Lars mentioned the same problem.
>
> I think my suggestion is not significantly worse or more awkward to use.

It seems my request was too specific, so I retract it.
It's easy to achieve this fallback in the init file with:

(advice-add 'diff-backup :around
            (lambda (orig-fun file &optional switches)
              (condition-case err
                  (funcall orig-fun file switches)
                (error
                 ;; Fall back to vc-diff
                 (if (vc-backend file)
                     (let ((vc-diff-switches switches))
                       (require 'vc)
                       (vc-diff-internal
                        t (list (vc-backend file) (list file)) nil nil t))
                   (error (cadr err))))))
            '((name . diff-backup-fallback-to-vc-diff)))

(advice-add 'vc-diff :around
            (lambda (orig-fun &rest args)
              (if (vc-deduce-backend)
                  (apply orig-fun args)
                ;; Fall back to non-vc diff-backup
                (diff-backup (if (derived-mode-p 'dired-mode)
                                 (dired-get-filename)
                               buffer-file-name)
                             vc-diff-switches)))
            '((name . vc-diff-fallback-to-diff-backup)))

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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?

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

"Non-standard UI", was: Re: bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

On 06.03.2020 1:59, Juri Linkov wrote:
> rgrep/vc-git-grep provides good UI.

No, it doesn't. It's the bare-bone-est UI possible, and it wastes a lot 
of horizontal space. It doesn't provide a means to search-and-replace. 
And it's not fit for programmatic construction, so Xref can't use it.

So we can't standardize on it, no matter how much you are used to it.

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

I asked where that command is defined, linked a webpage, you said yes.

But apparently you instead meant the newer version that's only on Github.

Okay then. Only visiting files that have matches is better. But not good 
enough when a string I entered ends up in having an arbitrary number of 
buffers visited, even if that's less than 4000.

It is one of "quality of life" things I have spent quite some effort on 
improving, and to be frank I don't appreciate you handwaving all that 
away by simply saying "non-standard".

None of the "standard" UIs you mentioned provide the functionality we 
need. Grep is async, but cumbersome and has no provision of doing 
anything with the matches: Wgrep is not in Emacs, not even in GNU ELPA, 
and there's no quick "replace matching string with xxx" feature in it 
anyway. Occur only works with buffers, it's not async either, and the 
overhead of visiting who knows how many buffers is basically unlimited 
(Grep is way faster at finding matches than Emacs at visiting files). 
It's objectively *worse* for the purpose at hand, which will be 
especially evident in bigger projects.

Re: "Non-standard UI",

[Juri Linkov]

>> rgrep/vc-git-grep provides good UI.
>
> No, it doesn't. It's the bare-bone-est UI possible, and it wastes a lot of
> horizontal space. It doesn't provide a means to search-and-replace. And
> it's not fit for programmatic construction, so Xref can't use it.

If you don't like the grep output format, you can replace 'grep-filter'
with your own process filter that would transform it to any other format.

> So we can't standardize on it, no matter how much you are used to it.

> It is one of "quality of life" things I have spent quite some effort on
> improving, and to be frank I don't appreciate you handwaving all that 
> away by simply saying "non-standard".

We already had 2 different formats: grep and occur, and now came a new
3rd format: xref.  I think any attempt to standardize on the output format
should be welcome.  Of course, a general UI should be customizable enough
to provide look and feel of any of the current formats.

> None of the "standard" UIs you mentioned provide the functionality we
> need. Grep is async, but cumbersome and has no provision of doing 
> anything with the matches: Wgrep is not in Emacs, not even in GNU ELPA, and
> there's no quick "replace matching string with xxx" feature in it
> anyway. Occur only works with buffers, it's not async either, and the 
> overhead of visiting who knows how many buffers is basically unlimited
> (Grep is way faster at finding matches than Emacs at visiting files). 
> It's objectively *worse* for the purpose at hand, which will be especially
> evident in bigger projects.

Why not take the best parts from these contenders?
Take async part of finding matches from grep and
transform its output to any format you like.

Re: "Non-standard UI"

[Dmitry Gutov]

On 08.03.2020 2:53, Juri Linkov wrote:
>>> rgrep/vc-git-grep provides good UI.
>>
>> No, it doesn't. It's the bare-bone-est UI possible, and it wastes a lot of
>> horizontal space. It doesn't provide a means to search-and-replace. And
>> it's not fit for programmatic construction, so Xref can't use it.
> 
> If you don't like the grep output format, you can replace 'grep-filter'
> with your own process filter that would transform it to any other format.

Or I can reuse the existing code.

The suggestion is not bad, but the grep-filter approach isn't going to 
work for Xref, at least, because the data format is a list of values.

And there's not much point in writing code to re-create Xref's UI in yet 
another way, if it can't replace the existing builder.

Overall, grep itself is fast, and we've done enough optimization on the 
way its results are processed that it being synchronous shouldn't be a 
significant problem on modern systems with small-to-medium projects, at 
least. But, of course, we could do better.

> We already had 2 different formats: grep and occur, and now came a new
> 3rd format: xref.  I think any attempt to standardize on the output format
> should be welcome.

Of course. But that would take some concerted effort, and not a 
dismissive attitude.

All three have some valuable features (Occur's inline editing feature 
comes to mind), but they also have each own domain of application thus 
far. So it would require work to make the features work everywhere (e.g. 
have Occur's inline editing work without visiting all files in advance).

> Of course, a general UI should be customizable enough
> to provide look and feel of any of the current formats.

So far, Xref provides variables xref-show-xrefs-function and 
xref-show-definitions-function, and I know for a fact that there are 
third-party packages out there that take advantage of these variables.

> Why not take the best parts from these contenders?
> Take async part of finding matches from grep and
> transform its output to any format you like.

I surely wouldn't refuse an extension of Xref API to asynchronous 
fetching of results. It's unlikely to work though grep-filter, though.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 3 Mar 2020 00:11:48 +0200
> Cc: 12492@debbugs.gnu.org, Lars Ingebrigtsen <larsi@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?

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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?

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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?

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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?

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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?

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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").

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

On 13.03.2020 16:30, Eli Zaretskii wrote:
>> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
>> From: Dmitry Gutov <dgutov@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)?

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 15 Mar 2020 23:57:11 +0200
> 
> On 13.03.2020 16:30, Eli Zaretskii wrote:
> >> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> >> From: Dmitry Gutov <dgutov@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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Eli Zaretskii]

> Cc: 12492@debbugs.gnu.org, larsi@gnus.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vc-dir-default-directory.patch --]
[-- Type: text/x-diff, Size: 3272 bytes --]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Andreas Schwab]

On Sep 23 2012, Dmitry Gutov <dgutov@yandex.ru> wrote:

> +(defun vc-root-dir ()

This is already defined in vc.el.

Andreas.

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

On 01.07.2019 11:02, Andreas Schwab wrote:
> On Sep 23 2012, Dmitry Gutov <dgutov@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)))))

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

>>> +(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)

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

>>>> +(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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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
> 

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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?

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Juri Linkov]

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

bug#12492: Acknowledgement (24.2.50; Open vc-dir buffer easier and faster)

[Dmitry Gutov]

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.

bug#12492: 24.2.50; Open vc-dir buffer easier and faster

[Andreas Schwab]

I don't agree with either point.  This should be optional with the
current behaviour left as the default.

Andreas.

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

bug#12492: 24.2.50; Open vc-dir buffer easier and faster

[Dmitry Gutov]

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.

bug#12492: 24.2.50; Open vc-dir buffer easier and faster

[Andreas Schwab]

Dmitry Gutov <dgutov@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#12492: 24.2.50; Open vc-dir buffer easier and faster

[Dmitry Gutov]

On 23.09.2012 12:46, Andreas Schwab wrote:
> Dmitry Gutov <dgutov@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?

bug#12492: 24.2.50; Open vc-dir buffer easier and faster

[Andreas Schwab]

The repository root doesn't always coincide with the subsystem root.

Andreas.

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

bug#12492: 24.2.50; Open vc-dir buffer easier and faster

[Dmitry Gutov]

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.

Re: bug#12492: vc-dir vs. vc-root-dir

[Ivan Shmakov]

>>>>> Dmitry Gutov <dgutov@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

bug#12492: vc-dir vs. vc-root-dir

[Stefan Monnier]

> 	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

bug#12492: vc-dir vs. vc-root-dir

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@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

bug#12492: vc-dir vs. vc-root-dir

[Stefan Monnier]

> 	Why is that a problem?

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


        Stefan

bug#12492: vc-dir vs. vc-root-dir

[Ivan Shmakov]

>>>>> Stefan Monnier <monnier@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

bug#12492: vc-dir vs. vc-root-dir

[Ivan Shmakov]

>>>>> Dmitry Gutov <dgutov@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