Re: vc.el: asynchronous annotations

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

> I have gone through with an example backend of my own as well as with
> vc-cvs (which inexplicably still works synchronously here),

Can you give me more information about your setup?  The CVS annotate is only
asynchronous if the repository is remote and if vc-stay-local is t.
Maybe your test repository is local?

> I am not sure I like the behavior when doing P or N or similar in the
> annotation buffer: since the buffer is reused, it is cleared and
> filled with new material while being displayed on the screen.

It's not ideal, but there isn't much we can do about it.  The best is to
provide an option for the user to choose something else (e.g. to force
synchronous behavior).

> There are two ways around that, I guess.  One way would be to switch
> back to the source buffer while the operation progresses.

What do you mean "switch"?  As in `switch-to-buffer'?  That will fail if the
window is dedicated.

> Another way would be to _not_ reuse the buffer but instead delete the old
> buffer once the new one is complete.

Again, this will fail if the window is dedicated.

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.

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.

> Anyway, here is a patch regarding the current working state at my end.
> Stefan, what do you say?

> *** vc.el	09 Jul 2007 23:10:04 +0200	1.432
> --- vc.el	16 Jul 2007 01:09:39 +0200	
> ***************
> *** 3123,3129 ****
>   use; you may override this using the second optional arg MODE."
>     (interactive)
>     (if mode (setq vc-annotate-display-mode mode))
> !   (pop-to-buffer (or buffer (current-buffer)))
>     (cond ((null vc-annotate-display-mode)
>            ;; The ratio is global, thus relative to the global color-map.
>            (kill-local-variable 'vc-annotate-color-map)
> --- 3123,3129 ----
>   use; you may override this using the second optional arg MODE."
>     (interactive)
>     (if mode (setq vc-annotate-display-mode mode))
> !   (if buffer (set-buffer buffer))
>     (cond ((null vc-annotate-display-mode)
>            ;; The ratio is global, thus relative to the global color-map.
>            (kill-local-variable 'vc-annotate-color-map)

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?

> --- 3192,3215 ----
>   	      (rename-buffer temp-buffer-name t)
>   	      ;; In case it had to be uniquified.
>   	      (setq temp-buffer-name (buffer-name))))
> !     (vc-call annotate-command file temp-buffer-name rev)
> !     ;; we must setup the mode first, and then set our local
> !     ;; variables before the show-function is called
> !     (with-current-buffer temp-buffer-name
> !       (if (not (equal major-mode 'vc-annotate-mode))
> ! 	  (vc-annotate-mode))
> !       (set (make-local-variable 'vc-annotate-backend) (vc-backend file))
> !       (set (make-local-variable 'vc-annotate-parent-file) file)
> !       (set (make-local-variable 'vc-annotate-parent-rev) rev)
> !       (set (make-local-variable 'vc-annotate-parent-display-mode)
> ! 	   display-mode)
> !       (vc-annotate-display-select temp-buffer-name)
  
I'm not sure why you moved the vc-call outside of the
with-output-to-temp-buffer.  It seems harmless, but it also seems pointless,
so unless it's just an accident (resulting for other temporary attempts at
something) I'd like to know why this was done.

Similarly, what was the motivation for moving the call to
vc-annotate-display-select?

> !       (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).


        Stefan
In-Reply-To: <85k5t12qzs.fsf@lola.goethe.zz> (David Kastrup's message of "Mon, 16 Jul 2007 01:20:55 +0200")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)
Date: Mon, 16 Jul 2007 11:42:26 -0400