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

[John Yates]

On Fri, Feb 10, 2023 at 6:47 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> 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?).

Actually, what I wrote was:
|  That said, vc-annotate is a jarring presentation.  As I browse through
|  different revisions I want the major mode to remain that of the original
|  (non-annotated) file.  I want syntax-based highlighting, lsp support, etc.

I do not wantdestructive editing.  A revision buffer presents a view
of an immutable revision.  I should never be allowed to alter history
(unless, of course, I do choose to rewrite history, but then, as we all
know, I am actually creating new revisions with new revision IDs).
What I would like is to be able to operate within a revision buffer using
all non-destructive commands and modes.

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

I agree that stepping linearly through the revisions on a branch often
is not the interface one would want.  But that is beside the point.
vc-annotate is a gussied-up presentation of the output of a backend
database join.  To me it shoves in my face how smart it is because
it can tell me, for every line, the revision, the author and the date when
that line was last modified.  Further, to present a color coded sense
of time, it presents my source in a jarring, and utterly unfamiliar style.

I view the vc-timemachine framework as one that simply knows, given
a file, how to display arbitrary revisions on its branch.  How the next
revision to display is chosen is orthogonal.  Today, vc-timemachine
supports the analogs of vc-annotate's 'n' and 'p', plus "search the
revision subject lines" and "jump to the n'th revision on the branch".
I am working on date based navigation.  There is no fundamental
reason why, over time, other vc-annotate -like navigation functions
cannot be added.

> Finally, some nits about the first patch:
> - It moves from the cache-by-default behavior to dont-cache-by-default.

Correct.  Stefan endorsed that change.

> - It removes an existing user option without a deprecation period.

The option did not go away.  Originally, I changed its name to reflect
the new default.  Stefan had much the same objection that you did.
I have since restored the original name and changed only the default.

> - It adds a timemachine-related variable to vc.el (vc-tm--revision ?).
> Timemachine will be a separate package, right?

No.  vc-timemachine is a properly integrated vc concept.  (RMS explicity
requested that it be so.)  Any VCS backend can support vc-timemachine
functionality by implementing one (optionally two) methods.

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

That would be a different cache.  This cache addresses cases where the
cost simply to retrieve a revision is high, independent of whether or not
that revision is then annotated.