Re: VC command for showing outgoing changes

[Stefan Monnier]

>> [ Another option might be to specify the `outgoing' or `incoming' as
>> arguments to vc-print-log or vc-diff.  Basically your `vc-(in|out)going'
>> is like (vc-print-log from-upstream to working-revision).  ]
> That looks like it would make vc-print-log more complex

Actually I really meant vc-print-log-internal and I don't think it would
make it any more complex (it might even stay almost unchanged).
The affected code would be the `print-log' operations in the backends.

But I don't know enough about how the various backends should/could
support incoming/outgoing to know whether it should be folded into the
`print-log' operation, or have its own backend operation(s).

We can keep them separate for now as your patch did.  We can always add
default implementations which redirect those to the `print-log'
backend operation.

> and would make this feature harder to find.

That wouldn't preclude new vc-log-incoming and vc-log-outgoing front ends.

> How about key bindings?

No opinions here, except that they should preferably be related to
"log" somehow.

>> Also incoming/outgoing will probably want to obey vc-log-short-style, so
>> we really want to use as much of vc-print-log-internal as possible here.

> It won't work: outgoing/incoming are project wide, so the directory vs
> file logic used for vc-log-short-style does not apply.

I don't see why it wouldn't work: what you're saying is that it will
always follow the `directory' part of that logic.  It's OK.

Note that there is no fundamental reason why `incoming' and `outgoing'
should always apply to the whole tree (tho there might be such
a limitation in all current implementations of the backends, but that's
another question altogether).

> Now there's a permanent-local variable `log-view-type', the values
> used for it are 'long 'short 'log-outgoing 'log-incoming.
> Currently only 'short is used in any logic. 

Thanks.  Really what this var does is specify the format used, and it
will mostly be used in a backend-specific way (after all, you almost
always need to know the backend in order to understand the format
anyway), so there is no strong need to standardize on particular values.

> It would be nice if log-view-mode had an optional parameter to pass
> this info.  But maybe adding optional arguments to major modes is
> a big no-no.

For one, it's a big no-no, indeed.  But also, log-view-type really
describes the buffer's content, so it makes a lot of sense for it to be
permanent-local.

Actually, for that same reason, we may prefer to name it vc-log-type.
Look at it this way: it's called "log-view-type", is declared in
log-view.el, and yet log-view.el doesn't make any use of it:  Not good.

>> We could still define a generic `log-view-type' or `log-view-format'
>> variable for it, tho.  The idea is that the generic part of the code may
>> want to use it, e.g. to display it in the mode-line (and let button-2
>> run a command that changes the format to something else).  But it should
>> be set by the backend's `print-log' operation rather than by the
>> generic code.
> Why should the backend set this?

Because it's (currently) only ever used in the backend's log-view-mode,
i.e. it's really an internal issue of the backend.  Many backends don't
have that much choice, other backends allow more choices of formats,
also some backends may prefer to use a vc-log-message-re that simply
matches all relevant formats, thu not needing log-view-type at all.

> It looks more cumbersome if all backends had to take care of doing it.

Not all of them would need it.  And it would make it easier to extend
the set of formats for specific backends.

Your new patch looks closer, thanks.  But we also still need to factor
out the commonality between vc-incoming-outgoing-internal and
vc-print-log-internal.


        Stefan