emacs-devel
[Top][All Lists]
Advanced

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

Re: vc-find-revision-no-save?


From: Dmitry Gutov
Subject: Re: vc-find-revision-no-save?
Date: Sat, 11 Feb 2023 01:46:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

Hi John,

On 31/01/2023 13:57, John Yates wrote:
Towards the end of Oct 2022, each of you contributed to the above named
emacs-devel email thread.

With issue #61071 on debbugs.gnu.org, I have attempted to address some
of the points mentioned in the email thread via:

     [PATCH 1/3] Refactor and document vc-find-revision caching

I append the cover letter and commit message below.

This is my very first attempt to contribute to Emacs.  So far I have
received no feedback.  If I am doing something wrong, please let me know.

You've done everything correctly regarding the submission, but it seems like nobody highly interested in this particular addition has found the time to review it so far.

Myself, I just saw the title (vc-timemachine) and skipped it. It wasn't obvious that some existing VC code was altered and needed reviewing. Sorry.

We're also close to releasing Emacs 29, so it seemed like higher priority.

Otherwise, though, it can be a good idea to ping a bug report a week or two after receiving to response. If nobody else does, the head maintainer usually ends up responding.

I will also use this opportunity to complain about the lack of code review tools here. Some of the reviewers here might be able to quote attached patches inline, but I don't use Gnus, so that's not a real option. Just a lot of opening the patches externally and copying and pasting. We could move the review to EMBA, though: https://emba.gnu.org/emacs/emacs/-/merge_requests

Now, to go back to the original thread you referred to, I mentioned vc-annotate, and you agreed that it has similar features but misses some stuff. Such as syntax highlighting. And editing support (is that necessary?).

Overall, I think it might be better to add features to vc-annotate than add a very similar but different feature. Especially since it has unique features of its own, such as showing and being able to jump to a revision that last modified a given line. Or the one before it, etc. IME, that's usually more useful than going through a file history linearly. But that's my opinion.

If that idea holds your interest, Stefan might also give a couple of recommendations, since as I recall he suggested something like that in the past. E.g. one of the ideas was to remove the sidebar text from the buffer text when processing, and instead store it in overlays or some such. Then put the buffer into a corresponding major mode which will apply font-lock and etc. But keep the (hidable) sidebar using overlays, for example. Or put it in the margin (also using overlays). And keep the navigation commands. The latter conflicts with having the buffer editable (if we're going to keep the one-char bindings). I haven't looked yet how it's solved with timemachine. The bindings might depend on whether the buffer is in read-only mode or not, though.

Finally, some nits about the first patch:
- It moves from the cache-by-default behavior to dont-cache-by-default.
- It removes an existing user option without a deprecation period.
- It adds a timemachine-related variable to vc.el (vc-tm--revision ?). Timemachine will be a separate package, right?

The overall idea seems sound. But if we choose the route of improving vc-annotate, a revision cache will probably not help because we would be caching the 'git annotate' output instead. Thus making it specific to that feature only.



reply via email to

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