unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Automatic updating (of display?) of the buffer *cvs* fails
@ 2003-10-10 23:46 Kim F. Storm
  2003-10-11  0:01 ` Kim F. Storm
  0 siblings, 1 reply; 2+ messages in thread
From: Kim F. Storm @ 2003-10-10 23:46 UTC (permalink / raw)



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 <rost@math.ohio-state.edu>
> 
> 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 <rost@math.ohio-state.edu> 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 <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Automatic updating (of display?) of the buffer *cvs* fails
  2003-10-10 23:46 Automatic updating (of display?) of the buffer *cvs* fails Kim F. Storm
@ 2003-10-11  0:01 ` Kim F. Storm
  0 siblings, 0 replies; 2+ messages in thread
From: Kim F. Storm @ 2003-10-11  0:01 UTC (permalink / raw)
  Cc: emacs-devel


storm@cua.dk (Kim F. Storm) writes:

> Marcus Rost and others have reported that *cvs* buffer fails to update
> correctly when cvs process terminates ...

Marcus,

Since you (as the only one so far) can reproduce this reliably (and
you reported that it started sometime around May/June), it would
help a lot if you could  try to identify the change that caused this.

Could you try to checkout a version from CVS around 2003-06-01 and see
if the problem was present there (see the -D option to cvs).

If so, then gradually go further back; otherwise go forward (like a
binary search) to narrow down which change or set of changes (see
src/ChangeLog) caused this to happen.

Since I made quite a huge number of changes to buffer and window
code this spring, those changes could of course be the reason.
But there have also been changes to process.c around May/June which
could be involved...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-10-11  0:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-10 23:46 Automatic updating (of display?) of the buffer *cvs* fails Kim F. Storm
2003-10-11  0:01 ` Kim F. Storm

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).