From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: vc.el: asynchronous annotations Date: Mon, 16 Jul 2007 13:29:32 -0400 Message-ID: References: <85k5t12qzs.fsf@lola.goethe.zz> <86hco472b4.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1184607019 23566 80.91.229.12 (16 Jul 2007 17:30:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2007 17:30:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 16 19:30:16 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IAUOm-0008Qt-GR for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2007 19:30:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IAUOl-0004iH-Vh for ged-emacs-devel@m.gmane.org; Mon, 16 Jul 2007 13:30:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IAUOA-0003lW-5p for emacs-devel@gnu.org; Mon, 16 Jul 2007 13:29:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IAUO8-0003hw-JN for emacs-devel@gnu.org; Mon, 16 Jul 2007 13:29:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IAUO8-0003hP-5A for emacs-devel@gnu.org; Mon, 16 Jul 2007 13:29:36 -0400 Original-Received: from tomts13.bellnexxia.net ([209.226.175.34] helo=tomts13-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IAUO6-0006q1-AG; Mon, 16 Jul 2007 13:29:34 -0400 Original-Received: from pastel.home ([70.53.192.24]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070716172933.VNGR13659.tomts13-srv.bellnexxia.net@pastel.home>; Mon, 16 Jul 2007 13:29:33 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id EFFDF800D; Mon, 16 Jul 2007 13:29:32 -0400 (EDT) In-Reply-To: <86hco472b4.fsf@lola.quinscape.zz> (David Kastrup's message of "Mon\, 16 Jul 2007 18\:15\:11 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Solaris 8 (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:74904 Archived-At: >> 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.