emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39380: closed (26.3: Opening files in vc-dir-mode with differing roo


From: GNU bug Tracking System
Subject: bug#39380: closed (26.3: Opening files in vc-dir-mode with differing root and working dir fails)
Date: Tue, 11 Feb 2020 22:37:02 +0000

Your message dated Wed, 12 Feb 2020 00:36:15 +0200
with message-id <address@hidden>
and subject line Re: bug#39380: 26.3: Opening files in vc-dir-mode with 
differing root and working dir fails
has caused the debbugs.gnu.org bug report #39380,
regarding 26.3: Opening files in vc-dir-mode with differing root and working 
dir fails
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
39380: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39380
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 26.3: Opening files in vc-dir-mode with differing root and working dir fails Date: Sat, 1 Feb 2020 01:13:39 +0100 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
Here is another per-tree/per-directory bug, I just found:

1. Prepare a Mercurial repository `check-hgs` with sub directories `sub1`
   and `sub2` and the files `sub1/a`, `sub2/x`,

   .. code-block:: sh

      mkdir -p check-hgs/sub1 check-hgs/sub2
      touch check-hgs/sub1/a check-hgs/sub2/x
      cd check-hgs && hg init

2. Find file `check-hgs/sub1/a`.

3. Press `C-x v d RET`, which will show a "Working dir" different from "Root":

   .. code-block:: text

      Working dir: check-hgs/sub1/
      Root       : check-hgs

                           ./
                           sub1/
      unregistered         sub1/a
                           sub2/
      unregistered         sub2/x

4. Go to line

   "unregistered         sub2/x"

   and press `f`.

5. Press `C-x d`.

   The default directory is "check-hgs/sub1/sub2/", which is wrong. It
   should be "check-hgs/sub2/".

The problem results from the call to `expand-file-name` in
`vc-dir-current-file`, which uses the default directory, but
`vc-dir-fileinfo->name` delivers a filename relative to the root
directory.

.. code-block:: elisp

   (defun vc-dir-current-file ()
     (let ((node (ewoc-locate vc-ewoc)))
       (unless node
     (error "No file available"))
       (expand-file-name (vc-dir-fileinfo->name (ewoc-data node)))))


However, modifying `vc-dir-current-file` does not solve the problem,
since all other invocations of `vc-dir-fileinfo->name` ultimately
suffer from the same deficiency.

It is IMHO better to remove the hybrid state of `vc-dir-mode`, where
the default directory is different from the root directory.
“

--- End Message ---
--- Begin Message --- Subject: Re: bug#39380: 26.3: Opening files in vc-dir-mode with differing root and working dir fails Date: Wed, 12 Feb 2020 00:36:15 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
Version: 27.1

On 08.02.2020 12:11, Eli Zaretskii wrote:
Cc: address@hidden, address@hidden
From: Dmitry Gutov <address@hidden>
Date: Sat, 8 Feb 2020 12:36:46 +0300

If I say "hg status" in a subdirectory, I by default get file names
relative to the root.  Wouldn't Mercurial users be surprised that
Emacs produces a different display?  (I understand that there's a
recent tendency to make it easier to produce relative file names, and
there's even a config option to make that the default, but I'm asking
whether we should force this behavior on users even if their
preference is not to.)

VC is intended to provide a unified interface across backends, even if
it's at times different from the "native" behaviors.

Anyway, it's very easy to get the names against the root anyway: just
open VC-Dir there. And it's the default input: M-x vc-dir RET.

OK.

Taking this as the approval of the patch, pushed.

Using "re:" adds a bit of a performance overhead, but it's probably not really noticeable on small-to-medium projects (and on a big one it was ~100ms where without it dir-status-files takes ~1s).


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]