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

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
Tags: patch

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

vc-dir.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
Same patch, with ChangeLog entries.

vc-dir.diff (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
In reply to this post by Dmitry Gutov
I don't agree with either point.  This should be optional with the
current behaviour left as the default.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
Dmitry Gutov <[hidden email]> 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, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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?



Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
The repository root doesn't always coincide with the subsystem root.

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

Ivan Shmakov
In reply to this post by Dmitry Gutov
>>>>> Dmitry Gutov <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Ivan Shmakov
>>>>> Stefan Monnier <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Ivan Shmakov
>>>>> Stefan Monnier <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Dmitry Gutov
Dmitry Gutov <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Dmitry Gutov <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Dmitry Gutov
Dmitry Gutov <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Juri Linkov <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Juri Linkov-2
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.



12345