Re: [21.1.90]: point put at point-min in *compilation*

[Stephen J. Turnbull]

Richard Stallman writes:
 >     To achieve the former, comint could have a third setting for how it
 >     moves point, where point movement would be on a timer (by default
 >     expiring somewhere in the neighborhood of 300ms at a guess).  Or if
 >     you're multitasking and checking progress only in your peripheral
 >     vision, you could slow it to 1000ms or even more.  Probably instead of
 >     scrolling at the end of the window, which would result in jumps, do a
 >     recenter after each forward-line.
 > 
 > I can't see concreteley what sort of point movement you have in mind
 > to do when the timer goes off.  So I don't understand the idea.
 > But I think that having point move a few times a second would be
 > disastrous for any attempt to do editing.

s/point/window-point/.  A disastrous abbreviation, sorry.

Well, you wrote that the screen scrolling was too fast.  You specified
a workaround of slowing down the compiler, but that seems silly since
Emacs will buffer as much text as the compiler wants to throw at it.
So I propose slowing down the scrolling to a pace at which you can
keep up with it, which of course will vary depending on how heavily
multitasked you are.

I haven't watched Emacs build in a long time, but on my system which
is reasonably slow, I have no trouble following an XEmacs build in my
peripheral vision.  I'd guess typically 1-3 files compile per second
(thus the 300ms pace for scrolling I suggested) and at that pace
warnings stick out like a sore thumb.  Ditto for Linux kernel and git
builds (actually, more so since they don't print out command line
options and such, just stuff like "CC kobject.c").

I have no problem editing in one window while window-point is moving
in another.  Unless there are so many warnings that I stop thinking
about what I'm doing in favor of thinking about fixing them.  But
that's a feature. ;-)