Re: vc.el: asynchronous annotations

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> OTOH it reminds me of a proposed feature: make it possible to exchange the
>> text (plus related data like text-properties, markers, overlays) of
>> two buffers.

> That would not require much Lisp, I guess.

No, that would be implemented at the C level.

> It would probably be easiest to just append the new stuff at the end of
> the current buffer in an invisible overlay, then move the point, delete
> the old material and make the new stuff visible.

Sounds like a good way to get into trouble: invisible text is still visible
to most Lisp code (e.g. save etc...).

>> With such a feature, we could indeed run the async process in
>> another buffer and then bring the result into the old buffer.  The
>> original motivation for such a feature was tar-mode where we'd like
>> to move the tarball bytes into an auxiliary buffer (kept in unibyte
>> mode) and have the "main" buffer only contain the tar listing (in
>> multibyte mode).  This would save us from constantly switching
>> between multibyte and unibyte modes and would clean up the code.

> Shadow-buffers don't help in this case?

What are shadow buffers?  The issue is basically that we start with the tar
file's content in buffer "foo.tar", but we want in the end to have there
only the listing of the contents.  Currently we do what you propose above
(with narrowing instead of invisible), but that's a bit delicate at times
and requires switching regularly from unibyte to multibyte which is an
operation whose cost is proportional to the size of the buffer.  What we'd
want instead is to have two buffers, one multibyte and the other unibyte,
but the one buffer that has to have the multibyte content is the one that we
receive with the unibyte content.  So we'd need to exchange the contents of
the two buffers.  We can do it with just an `insert-buffer-substring', but
if the buffer is very large (as can happen often with tar buffers), this can
be a problem.  A primitive "buffer-exchange-text" would be a lot
more efficient.

>> I strongly dislike this part.  The buffer should be shown immediately.
>> Just as is the case when you do N and P (so any problem from which this may
>> suffer has to be fixed anyway for other cases).
>> Or are you saying that it is shown anyway because of the call to
>> vc-annotate-display-select?

> No, I've taken the pop-to-buffer out as you can see.  You are
> basically proposing to exchange the one case where the behavior is
> tolerable with intolerable behavior throughout, for consistency's
> sake.  I'd rather like it the other way round...

No, I'm saying that I don't want a half fix.  I want to fix the N and
P cases as well, so there's no point trying to hack around the problem at
the one place where it can be done more easily.

>> I'm not sure why you moved the vc-call outside of the
>> with-output-to-temp-buffer.

> I removed the with-output-to-temp-buffer altogether.  I think that the
> motivation was that with-output-to-temp-buffer made it very obscure
> for annotate-command to influence the encoding in which the command
> output was interpreted from the annotate command, and in which it was
> written out.

Hmm... I'm not in love with with-output-to-temp-buffer, so I can agree with
the idea, but then we have to be careful to check that it doesn't change too
much of the behavior.  E.g. IIRC with-output-to-temp-buffer puts the buffer
in view-mode and marks it as unmodified.

>>> !       (vc-exec-after
>>> !        `(progn
>>> ! 	  (goto-line ,current-line ,temp-buffer-name)
>>> ! 	  (pop-to-buffer ,temp-buffer-name)
>>> ! 	  (unless (active-minibuffer-window)
>>> ! 	    (message "Annotating... done")))))))
>> 
>> Doing a pop-to-buffer from a process sentinel is a problem: it
>> works, but can be very annoying for the user (especially, but not
>> only, if she's looking at her keyboard while typing).

> Don't commands like man and woman also do that?

That doesn't mean it's a feature.


        Stefan


PS: My local version of man.el was hacked to not do that, BTW.
I haven't submitted a patch for it yet because it's an ugly hack.