From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Automatic updating (of display?) of the buffer *cvs* fails Date: 11 Oct 2003 01:46:35 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1065829809 25082 80.91.224.253 (10 Oct 2003 23:50:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 10 Oct 2003 23:50:09 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Oct 11 01:50:08 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A871L-0000nR-00 for ; Sat, 11 Oct 2003 01:50:07 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1A871L-0003Qg-00 for ; Sat, 11 Oct 2003 01:50:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A86z6-00038I-Vu for emacs-devel@quimby.gnus.org; Fri, 10 Oct 2003 19:47:48 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1A86yc-000380-Fx for emacs-devel@gnu.org; Fri, 10 Oct 2003 19:47:18 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1A86y6-0002oG-Bk for emacs-devel@gnu.org; Fri, 10 Oct 2003 19:47:17 -0400 Original-Received: from [193.162.153.4] (helo=pfepc.post.tele.dk) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A86y5-0002mr-Nr for emacs-devel@gnu.org; Fri, 10 Oct 2003 19:46:45 -0400 Original-Received: from kfs-l.imdomain.dk.cua.dk (0x503e2644.bynxx3.adsl-dhcp.tele.dk [80.62.38.68]) by pfepc.post.tele.dk (Postfix) with SMTP id 074E42628B4 for ; Sat, 11 Oct 2003 01:46:44 +0200 (CEST) Original-To: emacs-devel@gnu.org Original-Lines: 111 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17027 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17027 Marcus Rost and others have reported that *cvs* buffer fails to update correctly when cvs process terminates ... I have seen this myself occasionally (when I'm not hacking on emacs itself - and when it happens, I already did the updates, so there's no way to repeat it, sigh!). But so far, I have never managed to find a way to provoke this error at all when I've actually tried to track it down. When it has happened to me, it was quite clear that emacs thought that the display had been updated (at least to some extent) which could be seen by moving the cursor -- it jumped in seemingly strange ways because the buffer positions and window positions were not in sync. Since C-l fixes it, it seems that the buffer contents have been updated correctly by the sentinel, but it somehow forgot to redisplay the *cvs* window (process output from the cvs program goes into another buffer, and it is the sentinel which updates the *cvs* buffer when the cvs program terminates). Can any of you think of where this glitch is happening? Since the sentinel is using insert, I would expect MODIFF to be updated ... so who forgets to look at it? > From: storm@cua.dk (Kim F. Storm) > Date: 20 Aug 2003 14:01:10 +0200 > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 > > Hi Markus, > > Is the following problem still present in CVS emacs? > Date: Wed, 20 Aug 2003 17:18:42 -0400 (EDT) > From: Markus Rost > > Yes, it is still present, with a new bootstrapped version of today. I > don't understand why other people did not report this as well. I see > it on Emacs built on Solaris and GNU/Linux, running under X on a Sun > (I don't have another terminal available, I can only login to a > gnu-linux machine via ssh.). Stefan said that he sees this problem > occasionally, but I see it with EVERY run of cvs update. Markus Rost writes: > I don't know how to provide more details than I did already, except > for the fact that I am running emacs on X on Solaris and GNU/Linux. > > Can you please tell me exactly what to type, starting with `emacs -q'? > My Emacs checkout is in ~/emacs. > > I'll try. > > This is for the current CVS emacs on X on Solaris and GNU/Linux. Here > are the results of C-u M-x emacs-version : > > GNU Emacs 21.3.50.5 (sparc-sun-solaris2.9, X toolkit) of 2003-06-27 on hampton > > GNU Emacs 21.3.50.7 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2003-06-28 on euler > > The problem is not present with emacs -nw. > > Start Emacs with emacs -q > > Type > > M-x cvs-examine ~/emacs RET (where ~/emacs is the Emacs checkout directory) > > Move point up to a line with a "Need-Update" file info, like > > Need-Update lisp/ChangeLog > > (Hopefully there is such a line when you test this.) > > Hit key "O" (cvs-mode-update) > > Eventually the minibuffer displays the message > > CVS process has completed in *cvs* > > However, the buffer *cvs* is not visibly updated. Only after C-g or > C-l it gets visibly updated. > > A critical function seems to be here the function cvs-sentinel. It > contains the following part: > > (save-excursion (eval cvs-postproc)) > ;; check whether something is left > (unless cvs-postprocess > ;; IIRC, we enable undo again once the process is finished > ;; for cases where the output was inserted in *vc-diff* or > ;; in a file-like buffer. -stef > (buffer-enable-undo) > (with-current-buffer cvs-buffer > (cvs-update-header nil nil) ;FIXME: might need to be inline > (message "CVS process has completed in %s" (buffer-name))))) > > Here (eval cvs-postproc) in the first line does the updating of buffer > *cvs*, and the message "CVS process has completed ..." comes from the > last line. Since I can see that message, without seeing the updated > version of buffer *cvs*, it seems that there is a problem with the > display engine. > -- Kim F. Storm http://www.cua.dk