bug#2223: 23.0.90; *compilation* hangs and fails to scroll

["Marshall, Simon" <Simon.Marshall@misys.com>]

[-- Attachment #1: Type: text/plain, Size: 3842 bytes --]

This may be 2 unrelated problems.  However, I'll report them with this
one email since the reproduction requires the same steps.

I have a Makefile which builds a library out of a large number of object
files.  The compilation command that is output by make is 2826 chars
long.  Unfortunately, Emacs hangs part-way through inserting the command
into the *compilation* window and then leaves point part-way through the
line even though compilation-scroll-output it t.

You will need a Makefile that is going to output a long line.  This
works for me:

all:
	@echo the very long line copied from my real makefile

Now emacs -Q and eval in *scratch*

(setq compilation-scroll-output t)
(setq special-display-frame-alist nil)
(setq compile-frame-alist
      (append '((width . 150) (height . 15))
	      '((left . 25) (top . 75))
	      '((menu-bar-lines . 1))
	      special-display-frame-alist))
(setq special-display-buffer-names
      (list (cons "*compilation*" compile-frame-alist)))

Now do Tools > Compile... RET and I see Emacs create the *compilation*
window frame and:

(1) insert part of the echo output before hanging (in that the cursor
stops blinking and Emacs fails to refresh any frame that you might make
visible) for a few seconds, then

(2) resume inserting the echo output but leave point part way through
the echo output, then

(3) hang again for a few seconds

After make has finished, point is left as described in (2).  I think the
position of point when Emacs hangs in (1) is not the same position of
point when Emacs stops scrolling, however that might just be an artifact
of the lack of redisplay.

If compile-frame-alist is nil, so that a special frame is not created
for the *compilation* window, then (2) does not occur, however (1) and
(3) still do.

I also raised the scroll problem (2) with an email "[22.1.91]: scrolling
occasionally stops in *compilation*" on 27 Feb 2008.  I don't have a
reply archived, but I seem to remember someone saying it was fixed in
the then trunk with a patch that was not easily applied to the branch.

In GNU Emacs 23.0.90.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2009-02-03 on risksun2
Windowing system distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--x-includes=/usr/openwin/include:/usr/dt/include:/usr/local/include:/u
sr/local/X11/include'
'--x-libraries=/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/usr/local/X1
1/lib' '--with-x-toolkit=motif' '--with-jpeg=no' '--with-gif=no'
'--with-tiff=no''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t




"Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: One Kingdom Street, London W2 6BL, United Kingdom. For a list of Misys group operating companies please go to http://www.misys.com/corp/About_Us/misys_operating_companies.html. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing. 

[-- Attachment #2: Type: text/html, Size: 7689 bytes --]