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

[Stephen J. Turnbull]

Richard Stallman writes:

 >     > I would guess that a default of t for
 >     > compilation-scroll-output would be better that the current
 >     > default of nil, but YMMV.  When I'm compiling, I generally
 >     > want to see progress, so I generally want Emacs to scroll the
 >     > window for me.
 > 
 >     Agreed,
 > 
 > I disagree.  I find that I can't read the output of compilation if it
 > scrolls.  Compilers are too fast these days!  Now, if we could slow them
 > down, maybe it would be ok to scroll the output.  Any ideas?

Two different use cases here.  For Richard, the actual output is
important; for example, maybe he wants to see compilation warnings.
For the others, only motion (scrolling) is important as an indicator
of progress, and they want to see the error (if any) or successful
completion immediately when it happens.

I think that the latter should be default, personally.

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.  You'd also probably want a
precommand hook where any user input in that window deactivated the
timer.  Maybe an option where the default on user input is to set
mark, then jump to the end (the idea is that you find out immediately
whather the build succeeded, but then you can jump right back to the
neighborhood of a warning that caught your attention).