unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
@ 2021-09-13 15:47 Manuel Giraud
  2021-09-13 16:10 ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud @ 2021-09-13 15:47 UTC (permalink / raw)
  To: 50572

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


When calling 'vc-next-action' on an unregistered file, VC could choose a
backend that is very far above this file in the directory hierarchy.

In my case, it chooses SVN as backend (because I have one in my homedir)
but I wanted it to choose the Git backend of the directory this file
resides.

This patch solves this issue by selecting the backend with the most
specific (in fact, the longest string) path to the file.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-let-VC-find-a-responsible-backend-with-the-most-spec.patch --]
[-- Type: text/x-patch, Size: 1371 bytes --]

From 9e673edc28f84a75f3bf0f53e7fba01c2f50e51c Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Mon, 13 Sep 2021 17:31:31 +0200
Subject: [PATCH] let VC find a responsible backend with the most specific
 path.

---
 lisp/vc/vc.el | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index 4fcba65ab4..7160c98820 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -937,11 +937,16 @@ vc-backend-for-registration
 use."
   (catch 'found
     ;; First try: find a responsible backend, it must be a backend
-    ;; under which FILE is not yet registered.
-    (dolist (backend vc-handled-backends)
-      (and (not (vc-call-backend backend 'registered file))
-	   (vc-call-backend backend 'responsible-p file)
-	   (throw 'found backend)))
+    ;; under which FILE is not yet registered and with the most
+    ;; specific path to FILE.
+    (let ((max 0) bk)
+      (dolist (backend vc-handled-backends)
+        (when (not (vc-call-backend backend 'registered file))
+          (let* ((path (vc-call-backend backend 'responsible-p file))
+                 (len (length path)))
+            (when (and len (> len max))
+              (setq max len bk backend)))))
+      (when bk (throw 'found bk)))
     ;; no responsible backend
     (let* ((possible-backends
 	    (let (pos)
-- 
2.33.0


[-- Attachment #3: Type: text/plain, Size: 7259 bytes --]



In GNU Emacs 28.0.50 (build 1, x86_64-unknown-openbsd7.0, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-09-13 built on elite.giraud
Repository revision: 5ee05fa75d517fdd13c9795aa78e12489140e388
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: OpenBSD elite.giraud 7.0 GENERIC.MP#211 amd64

Configured using:
 'configure --prefix=/home/manuel/emacs --bindir=/home/manuel/bin
 --with-x-toolkit=athena --without-sound --without-json
 CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2
LIBOTF LIBXML2 M17N_FLT MODULES NOTIFY KQUEUE PDUMPER PNG RSVG THREADS
TIFF TOOLKIT_SCROLL_BARS X11 XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Outline

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  auto-revert-mode: t
  bug-reference-mode: t
  show-paren-mode: t
  icomplete-mode: t
  display-time-mode: t
  shell-dirtrack-mode: t
  windmove-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/manuel/.el/google-maps.el/google-maps hides /home/manuel/.el/google-maps
/home/manuel/.emacs.d/elpa/magit-20210909.434/magit-section-pkg hides /home/manuel/.emacs.d/elpa/magit-section-20210829.1849/magit-section-pkg
/home/manuel/.emacs.d/elpa/transient-20210819.2118/transient hides /home/manuel/emacs/share/emacs/28.0.50/lisp/transient

Features:
(shadow sort bbdb-message mail-extr gnus-msg emacsbug magit-extras
face-remap magit-submodule magit-obsolete magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit magit-repos magit-apply magit-wip magit-log
which-func imenu magit-diff smerge-mode diff git-commit rx log-edit
pcvs-util add-log magit-core magit-autorevert autorevert filenotify
magit-margin magit-transient magit-process magit-mode transient
magit-git magit-section misearch multi-isearch bug-reference cl-print
debug backtrace dabbrev pulse vc-annotate vc-filewise eieio-opt speedbar
ezimage dframe shortdoc help-fns radix-tree vc-mtn vc-hg vc-git
diff-mode vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs vc-dir ewoc vc
vc-dispatcher gnus-dired with-editor em-unix em-term term ehelp
em-script em-prompt em-ls em-hist em-pred em-glob em-cmpl em-dirs
esh-var em-basic em-banner em-alias esh-mode eshell esh-cmd esh-ext
esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util
magit-utils dash cl-extra help-mode paredit paren icomplete time battery
cus-load exwm-randr xcb-randr exwm-config exwm exwm-input xcb-keysyms
exwm-manage exwm-floating xcb-cursor xcb-render exwm-layout
exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xkb xcb-xproto
xcb-types xcb-debug server modus-operandi-theme modus-themes pcase
google-maps google-maps-static google-maps-geocode google-maps-base
osm-mode url-cache gnuplot info-look transmission color calc-bin
calc-ext calc calc-loaddefs rect calc-macs w3m-load mu4e mu4e-org
mu4e-main mu4e-view mu4e-view-gnus gnus-art mm-uu mml2015 mm-view
mml-smime smime dig gnus-sum gnus-group gnus-undo gnus-start gnus-dbus
dbus gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec
gnus-int gnus-range gnus-win gnus nnheader wid-edit mu4e-view-common
mu4e-headers mu4e-compose mu4e-context mu4e-draft mu4e-actions ido
rfc2368 smtpmail sendmail mu4e-mark mu4e-proc mu4e-utils doc-view
jka-compr image-mode exif mu4e-lists mu4e-message shr kinsoku svg xml
dom flow-fill mule-util hl-line mu4e-vars message rmc puny rfc822 mml
mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr mail-utils gmm-utils mailheader
mu4e-meta supercite regi bbdb-anniv diary-lib diary-loaddefs bbdb-mua
bbdb-com crm mailabbrev bbdb bbdb-site timezone org ob ob-tangle ob-ref
ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint
org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp
ob-core ob-eval org-table ol org-keys org-compat org-macs org-loaddefs
find-func cal-menu calendar cal-loaddefs visual-basic-mode web-mode
disp-table erlang-start smart-tabs-mode skeleton cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
movitz-slime cl slime-asdf grep slime-tramp tramp tramp-loaddefs
trampver tramp-integration files-x tramp-compat shell pcomplete
parse-time iso8601 time-date ls-lisp format-spec slime-fancy
slime-indentation slime-cl-indent cl-indent slime-trace-dialog
slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree advice slime-scratch slime-presentations
bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context
slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl slime-parse slime
compile text-property-search etags fileloop generator xref project
arc-mode archive-mode noutline outline pp comint ansi-color ring
hyperspec thingatpt slime-autoloads dired-aux dired-x dired
dired-loaddefs edmacro kmacro windmove easy-mmode tex-site info package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind kqueue lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 612471 87337)
 (symbols 48 53625 7)
 (strings 32 170780 9764)
 (string-bytes 1 5553540)
 (vectors 16 88025)
 (vector-slots 8 1152335 56459)
 (floats 8 545 390)
 (intervals 56 4332 940)
 (buffers 992 33))

-- 
Manuel Giraud

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-13 15:47 bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path Manuel Giraud
@ 2021-09-13 16:10 ` Eli Zaretskii
  2021-09-13 23:48   ` Dmitry Gutov
  2021-09-14  7:50   ` Manuel Giraud
  0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2021-09-13 16:10 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: 50572

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Date: Mon, 13 Sep 2021 17:47:19 +0200
> 
> When calling 'vc-next-action' on an unregistered file, VC could choose a
> backend that is very far above this file in the directory hierarchy.
> 
> In my case, it chooses SVN as backend (because I have one in my homedir)
> but I wanted it to choose the Git backend of the directory this file
> resides.
> 
> This patch solves this issue by selecting the backend with the most
> specific (in fact, the longest string) path to the file.

Isn't that already available with "C-u C-x v v"?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-13 16:10 ` Eli Zaretskii
@ 2021-09-13 23:48   ` Dmitry Gutov
  2021-09-14  2:28     ` Eli Zaretskii
  2021-09-14  7:57     ` Manuel Giraud
  2021-09-14  7:50   ` Manuel Giraud
  1 sibling, 2 replies; 21+ messages in thread
From: Dmitry Gutov @ 2021-09-13 23:48 UTC (permalink / raw)
  To: Eli Zaretskii, Manuel Giraud; +Cc: 50572

On 13.09.2021 19:10, Eli Zaretskii wrote:
>> From: Manuel Giraud<manuel@ledu-giraud.fr>
>> Date: Mon, 13 Sep 2021 17:47:19 +0200
>>
>> When calling 'vc-next-action' on an unregistered file, VC could choose a
>> backend that is very far above this file in the directory hierarchy.
>>
>> In my case, it chooses SVN as backend (because I have one in my homedir)
>> but I wanted it to choose the Git backend of the directory this file
>> resides.
>>
>> This patch solves this issue by selecting the backend with the most
>> specific (in fact, the longest string) path to the file.
> Isn't that already available with "C-u C-x v v"?

A better default is an improvement anyway.

I think the patch is a good idea, especially given that 
vc-responsible-backend has only recently been changed in the same way 
(commit 2697123933).





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-13 23:48   ` Dmitry Gutov
@ 2021-09-14  2:28     ` Eli Zaretskii
  2021-09-14  7:57     ` Manuel Giraud
  1 sibling, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2021-09-14  2:28 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 50572, manuel

> Cc: 50572@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 14 Sep 2021 02:48:11 +0300
> 
> >> This patch solves this issue by selecting the backend with the most
> >> specific (in fact, the longest string) path to the file.
> > Isn't that already available with "C-u C-x v v"?
> 
> A better default is an improvement anyway.

But it looks like we've lost that feature of "C-x v v" somehow,
because it doesn't seem to work here.  Which is too bad.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-13 16:10 ` Eli Zaretskii
  2021-09-13 23:48   ` Dmitry Gutov
@ 2021-09-14  7:50   ` Manuel Giraud
  2021-09-14 11:38     ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: Manuel Giraud @ 2021-09-14  7:50 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50572

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Date: Mon, 13 Sep 2021 17:47:19 +0200
>> 
>> When calling 'vc-next-action' on an unregistered file, VC could choose a
>> backend that is very far above this file in the directory hierarchy.
>> 
>> In my case, it chooses SVN as backend (because I have one in my homedir)
>> but I wanted it to choose the Git backend of the directory this file
>> resides.
>> 
>> This patch solves this issue by selecting the backend with the most
>> specific (in fact, the longest string) path to the file.
>
> Isn't that already available with "C-u C-x v v"?

It does not work for me. It still tries to register in my homedir
subversion. FWIW, I think the most specific should be the default of
"C-x v v" and maybe I could try to get the least specific for "C-u C-x v
v"
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-13 23:48   ` Dmitry Gutov
  2021-09-14  2:28     ` Eli Zaretskii
@ 2021-09-14  7:57     ` Manuel Giraud
  1 sibling, 0 replies; 21+ messages in thread
From: Manuel Giraud @ 2021-09-14  7:57 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 50572

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.09.2021 19:10, Eli Zaretskii wrote:
>>> From: Manuel Giraud<manuel@ledu-giraud.fr>
>>> Date: Mon, 13 Sep 2021 17:47:19 +0200
>>>
>>> When calling 'vc-next-action' on an unregistered file, VC could choose a
>>> backend that is very far above this file in the directory hierarchy.
>>>
>>> In my case, it chooses SVN as backend (because I have one in my homedir)
>>> but I wanted it to choose the Git backend of the directory this file
>>> resides.
>>>
>>> This patch solves this issue by selecting the backend with the most
>>> specific (in fact, the longest string) path to the file.
>> Isn't that already available with "C-u C-x v v"?
>
> A better default is an improvement anyway.
>
> I think the patch is a good idea, especially given that
> vc-responsible-backend has only recently been changed in the same way
> (commit 2697123933).

I see: this is the same functionality. Should I package this selection
into a function then?
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-14  7:50   ` Manuel Giraud
@ 2021-09-14 11:38     ` Eli Zaretskii
  2021-09-14 12:08       ` Manuel Giraud
                         ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Eli Zaretskii @ 2021-09-14 11:38 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: 50572

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 50572@debbugs.gnu.org
> Date: Tue, 14 Sep 2021 09:50:22 +0200
> 
> > Isn't that already available with "C-u C-x v v"?
> 
> It does not work for me. It still tries to register in my homedir
> subversion.

It didn't work for me, either.  Which is a pity, since the manual says
it should.  I guess we lost this at some point; patches to fix that
are welcome.

> FWIW, I think the most specific should be the default of
> "C-x v v"

I'm worried that we are arbitrarily changing the defaults, for the
sole reason that the new default plays better with someone's
workflows.  AFAIR, it used to be the case that the order of VCS names
in vc-handled-backends determined the way the default is sought out
and set.  This change (and I think the other one Dmitry mentioned in
his response?) change that in a way that doesn't leave any "fire
escape" to users who might be setting things up to have a meaningful
(for them) order in that list.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-14 11:38     ` Eli Zaretskii
@ 2021-09-14 12:08       ` Manuel Giraud
  2021-09-14 12:57         ` Eli Zaretskii
  2021-09-14 15:15       ` Manuel Giraud
  2021-09-15 10:41       ` Dmitry Gutov
  2 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud @ 2021-09-14 12:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50572

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: 50572@debbugs.gnu.org
>> Date: Tue, 14 Sep 2021 09:50:22 +0200
>> 
>> > Isn't that already available with "C-u C-x v v"?
>> 
>> It does not work for me. It still tries to register in my homedir
>> subversion.
>
> It didn't work for me, either.  Which is a pity, since the manual says
> it should.  I guess we lost this at some point; patches to fix that
> are welcome.

Ok. I could try to work on this issue then but maybe I should file
another bug report, no?

>> FWIW, I think the most specific should be the default of
>> "C-x v v"
>
> I'm worried that we are arbitrarily changing the defaults, for the
> sole reason that the new default plays better with someone's
> workflows.

I think you are right and as you said the "choose the correct backend"
behaviour is already documented in the manual (in "Advanced Control in
‘C-x v v’").

> AFAIR, it used to be the case that the order of VCS names in
> vc-handled-backends determined the way the default is sought out and
> set.  This change (and I think the other one Dmitry mentioned in his
> response?) change that in a way that doesn't leave any "fire escape"
> to users who might be setting things up to have a meaningful (for
> them) order in that list.

Yes, in "Customizing VC", the manual insists on the order importance of
the vc-handled-backends list. So maybe, just fixing "C-u C-x v v" and
remember this customization is enough here.
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-14 12:08       ` Manuel Giraud
@ 2021-09-14 12:57         ` Eli Zaretskii
  0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2021-09-14 12:57 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: 50572

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 50572@debbugs.gnu.org
> Date: Tue, 14 Sep 2021 14:08:36 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Isn't that already available with "C-u C-x v v"?
> >> 
> >> It does not work for me. It still tries to register in my homedir
> >> subversion.
> >
> > It didn't work for me, either.  Which is a pity, since the manual says
> > it should.  I guess we lost this at some point; patches to fix that
> > are welcome.
> 
> Ok. I could try to work on this issue then but maybe I should file
> another bug report, no?

Yes, please.

> > I'm worried that we are arbitrarily changing the defaults, for the
> > sole reason that the new default plays better with someone's
> > workflows.
> 
> I think you are right and as you said the "choose the correct backend"
> behaviour is already documented in the manual (in "Advanced Control in
> ‘C-x v v’").
> 
> > AFAIR, it used to be the case that the order of VCS names in
> > vc-handled-backends determined the way the default is sought out and
> > set.  This change (and I think the other one Dmitry mentioned in his
> > response?) change that in a way that doesn't leave any "fire escape"
> > to users who might be setting things up to have a meaningful (for
> > them) order in that list.
> 
> Yes, in "Customizing VC", the manual insists on the order importance of
> the vc-handled-backends list. So maybe, just fixing "C-u C-x v v" and
> remember this customization is enough here.

Let's wait for Dmitry to chime in, as I expect he will have different
opinions.

Thanks





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-14 11:38     ` Eli Zaretskii
  2021-09-14 12:08       ` Manuel Giraud
@ 2021-09-14 15:15       ` Manuel Giraud
  2021-09-14 16:03         ` Eli Zaretskii
  2021-09-15 10:41       ` Dmitry Gutov
  2 siblings, 1 reply; 21+ messages in thread
From: Manuel Giraud @ 2021-09-14 15:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50572

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: 50572@debbugs.gnu.org
>> Date: Tue, 14 Sep 2021 09:50:22 +0200
>> 
>> > Isn't that already available with "C-u C-x v v"?
>> 
>> It does not work for me. It still tries to register in my homedir
>> subversion.
>
> It didn't work for me, either.  Which is a pity, since the manual says
> it should.  I guess we lost this at some point; patches to fix that
> are welcome.

FTR, I don't if it was lost at some point because reading the code it
seems that prefix is taken into account if the file is already
registered into some backend… but for unregistered file it seems that
nothing is done with the prefix.
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-14 15:15       ` Manuel Giraud
@ 2021-09-14 16:03         ` Eli Zaretskii
  2021-09-15  9:17           ` Manuel Giraud
  2021-09-15 10:35           ` Dmitry Gutov
  0 siblings, 2 replies; 21+ messages in thread
From: Eli Zaretskii @ 2021-09-14 16:03 UTC (permalink / raw)
  To: Manuel Giraud; +Cc: 50572

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 50572@debbugs.gnu.org
> Date: Tue, 14 Sep 2021 17:15:14 +0200
> 
> > It didn't work for me, either.  Which is a pity, since the manual says
> > it should.  I guess we lost this at some point; patches to fix that
> > are welcome.
> 
> FTR, I don't if it was lost at some point because reading the code it
> seems that prefix is taken into account if the file is already
> registered into some backend… but for unregistered file it seems that
> nothing is done with the prefix.

So maybe this never worked for registering, in which case I think it
would be good to add that.  Because the manual says this should work
for "C-x v v" in general, not just under some conditions.  And what's
the most natural occasion to determine the backend if not when you
register a file?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-14 16:03         ` Eli Zaretskii
@ 2021-09-15  9:17           ` Manuel Giraud
  2021-09-15 10:35           ` Dmitry Gutov
  1 sibling, 0 replies; 21+ messages in thread
From: Manuel Giraud @ 2021-09-15  9:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50572

Eli Zaretskii <eliz@gnu.org> writes:

> So maybe this never worked for registering, in which case I think it
> would be good to add that.  Because the manual says this should work
> for "C-x v v" in general, not just under some conditions.  And what's
> the most natural occasion to determine the backend if not when you
> register a file?

Yes. I'll look into it and open a new bug report when I have
something.

In fact, it seems hard to me to find an example where choosing a backend
for an already registered file (in another backend) is a useful next
action.
-- 
Manuel Giraud





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-14 16:03         ` Eli Zaretskii
  2021-09-15  9:17           ` Manuel Giraud
@ 2021-09-15 10:35           ` Dmitry Gutov
  2021-09-15 11:20             ` Eli Zaretskii
  1 sibling, 1 reply; 21+ messages in thread
From: Dmitry Gutov @ 2021-09-15 10:35 UTC (permalink / raw)
  To: Eli Zaretskii, Manuel Giraud; +Cc: 50572

On 14.09.2021 19:03, Eli Zaretskii wrote:
> So maybe this never worked for registering, in which case I think it
> would be good to add that.  Because the manual says this should work
> for "C-x v v" in general, not just under some conditions.  And what's
> the most natural occasion to determine the backend if not when you
> register a file?

I don't know what the manual says, but vc-next-section's signature calls 
the prefix argument's value VERBOSE, and vc-register doesn't have a way 
to trigger backend-prompting either. So it might be difficult to add 
that feature in a backward-compatible manner.

vc-register doesn't work with C-u at all, though (shows an error), so it 
might be possible to do something in that area.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-14 11:38     ` Eli Zaretskii
  2021-09-14 12:08       ` Manuel Giraud
  2021-09-14 15:15       ` Manuel Giraud
@ 2021-09-15 10:41       ` Dmitry Gutov
  2021-09-15 11:22         ` Eli Zaretskii
  2 siblings, 1 reply; 21+ messages in thread
From: Dmitry Gutov @ 2021-09-15 10:41 UTC (permalink / raw)
  To: Eli Zaretskii, Manuel Giraud; +Cc: 50572

On 14.09.2021 14:38, Eli Zaretskii wrote:
>> FWIW, I think the most specific should be the default of
>> "C-x v v"
> I'm worried that we are arbitrarily changing the defaults, for the
> sole reason that the new default plays better with someone's
> workflows.  AFAIR, it used to be the case that the order of VCS names
> in vc-handled-backends determined the way the default is sought out
> and set.  This change (and I think the other one Dmitry mentioned in
> his response?) change that in a way that doesn't leave any "fire
> escape" to users who might be setting things up to have a meaningful
> (for them) order in that list.

It's really more of a discussion for bug#42966. Because no matter how 
one feels about that change (I don't have a strong opinion), these two 
pieces of code should follow the same pattern.

Now, the change in vc-responsible-backend might seem controversial, as 
it decreases customizability and performance (a bit), but it was made a 
year ago, and we've received no substantial complaints. And there have 
been multiple reports (all linked) about the previous behavior.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-15 10:35           ` Dmitry Gutov
@ 2021-09-15 11:20             ` Eli Zaretskii
  2021-09-15 11:36               ` Dmitry Gutov
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2021-09-15 11:20 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 50572, manuel

> Cc: 50572@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 15 Sep 2021 13:35:14 +0300
> 
> On 14.09.2021 19:03, Eli Zaretskii wrote:
> > So maybe this never worked for registering, in which case I think it
> > would be good to add that.  Because the manual says this should work
> > for "C-x v v" in general, not just under some conditions.  And what's
> > the most natural occasion to determine the backend if not when you
> > register a file?
> 
> I don't know what the manual says, but vc-next-section's signature calls 
> the prefix argument's value VERBOSE, and vc-register doesn't have a way 
> to trigger backend-prompting either. So it might be difficult to add 
> that feature in a backward-compatible manner.

We could use a different arg value, for example "C-u" will do one
thing and "C-u C-u" another.  There's precedence for that.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-15 10:41       ` Dmitry Gutov
@ 2021-09-15 11:22         ` Eli Zaretskii
  2021-09-15 11:37           ` Dmitry Gutov
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2021-09-15 11:22 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 50572, manuel

> Cc: 50572@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 15 Sep 2021 13:41:57 +0300
> 
> Now, the change in vc-responsible-backend might seem controversial, as 
> it decreases customizability and performance (a bit), but it was made a 
> year ago, and we've received no substantial complaints. And there have 
> been multiple reports (all linked) about the previous behavior.

That doesn't alleviate my worries, unfortunately.  Many people either
don't use VC or use it very "narrowly", so they never bump into these
rarely-used-but-very-useful features.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-15 11:20             ` Eli Zaretskii
@ 2021-09-15 11:36               ` Dmitry Gutov
  0 siblings, 0 replies; 21+ messages in thread
From: Dmitry Gutov @ 2021-09-15 11:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50572, manuel

On 15.09.2021 14:20, Eli Zaretskii wrote:
>> I don't know what the manual says, but vc-next-section's signature calls
>> the prefix argument's value VERBOSE, and vc-register doesn't have a way
>> to trigger backend-prompting either. So it might be difficult to add
>> that feature in a backward-compatible manner.
> We could use a different arg value, for example "C-u" will do one
> thing and "C-u C-u" another.  There's precedence for that.

That's an option, yes.

We can also look into whether "verbose" applies to the "register" step 
of vc-next-action, and if not, or it doesn't conflict, add 
"switch-backend" feature to it.

If, like you said, the manual says 'C-u' will do this for all commands, 
it wouldn't be great to have to use different prefixes for different 
commands. But an escape hatch is better than no escape hatch, of course.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-15 11:22         ` Eli Zaretskii
@ 2021-09-15 11:37           ` Dmitry Gutov
  2021-09-15 11:44             ` Eli Zaretskii
  0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Gutov @ 2021-09-15 11:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50572, manuel

On 15.09.2021 14:22, Eli Zaretskii wrote:
>> Cc:50572@debbugs.gnu.org
>> From: Dmitry Gutov<dgutov@yandex.ru>
>> Date: Wed, 15 Sep 2021 13:41:57 +0300
>>
>> Now, the change in vc-responsible-backend might seem controversial, as
>> it decreases customizability and performance (a bit), but it was made a
>> year ago, and we've received no substantial complaints. And there have
>> been multiple reports (all linked) about the previous behavior.
> That doesn't alleviate my worries, unfortunately.  Many people either
> don't use VC or use it very "narrowly", so they never bump into these
> rarely-used-but-very-useful features.

I don't think we have a better way of making that choice now than 
waiting for more reports.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-15 11:37           ` Dmitry Gutov
@ 2021-09-15 11:44             ` Eli Zaretskii
  2021-09-15 11:47               ` Dmitry Gutov
  0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2021-09-15 11:44 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 50572, manuel

> Cc: manuel@ledu-giraud.fr, 50572@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 15 Sep 2021 14:37:14 +0300
> 
> On 15.09.2021 14:22, Eli Zaretskii wrote:
> >> Cc:50572@debbugs.gnu.org
> >> From: Dmitry Gutov<dgutov@yandex.ru>
> >> Date: Wed, 15 Sep 2021 13:41:57 +0300
> >>
> >> Now, the change in vc-responsible-backend might seem controversial, as
> >> it decreases customizability and performance (a bit), but it was made a
> >> year ago, and we've received no substantial complaints. And there have
> >> been multiple reports (all linked) about the previous behavior.
> > That doesn't alleviate my worries, unfortunately.  Many people either
> > don't use VC or use it very "narrowly", so they never bump into these
> > rarely-used-but-very-useful features.
> 
> I don't think we have a better way of making that choice now than 
> waiting for more reports.

<Shrug> Well, you have mine.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-15 11:44             ` Eli Zaretskii
@ 2021-09-15 11:47               ` Dmitry Gutov
  2021-09-16 12:55                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Gutov @ 2021-09-15 11:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 50572, manuel

On 15.09.2021 14:44, Eli Zaretskii wrote:
>> I don't think we have a better way of making that choice now than
>> waiting for more reports.
> <Shrug> Well, you have mine.

Reports with some specific broken scenarios.

So far I don't see anything actionable in yours. Maybe Lars does?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path.
  2021-09-15 11:47               ` Dmitry Gutov
@ 2021-09-16 12:55                 ` Lars Ingebrigtsen
  0 siblings, 0 replies; 21+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-16 12:55 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 50572, manuel

Dmitry Gutov <dgutov@yandex.ru> writes:

> So far I don't see anything actionable in yours. Maybe Lars does?

Nope.

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





^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2021-09-16 12:55 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-13 15:47 bug#50572: 28.0.50; [PATCH] fix VC to find the responsible backend with the most specific path Manuel Giraud
2021-09-13 16:10 ` Eli Zaretskii
2021-09-13 23:48   ` Dmitry Gutov
2021-09-14  2:28     ` Eli Zaretskii
2021-09-14  7:57     ` Manuel Giraud
2021-09-14  7:50   ` Manuel Giraud
2021-09-14 11:38     ` Eli Zaretskii
2021-09-14 12:08       ` Manuel Giraud
2021-09-14 12:57         ` Eli Zaretskii
2021-09-14 15:15       ` Manuel Giraud
2021-09-14 16:03         ` Eli Zaretskii
2021-09-15  9:17           ` Manuel Giraud
2021-09-15 10:35           ` Dmitry Gutov
2021-09-15 11:20             ` Eli Zaretskii
2021-09-15 11:36               ` Dmitry Gutov
2021-09-15 10:41       ` Dmitry Gutov
2021-09-15 11:22         ` Eli Zaretskii
2021-09-15 11:37           ` Dmitry Gutov
2021-09-15 11:44             ` Eli Zaretskii
2021-09-15 11:47               ` Dmitry Gutov
2021-09-16 12:55                 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).