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

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

[Marshall, Simon]

In 21.1, if you run Compile | Compile... RET or Compile | Recompile in a
*compilation* buffer, point is initially placed at point-max, which
means that point stays at point-max as compilation output is inserted
into the buffer and Emacs scrolls the window to keep the latest output
visible.  Very convenient.

In 21.1.90, point is placed at point-min, so that you have to actively
scroll the window to see compilation output.  I really don't like it!

Simon.

In GNU Emacs 22.1.90.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2008-01-31 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''

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
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Compilation

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t



Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[Chong Yidong]

"Marshall, Simon" <Simon.Marshall@misys.com> writes:

> In 21.1, if you run Compile | Compile... RET or Compile | Recompile in a
> *compilation* buffer, point is initially placed at point-max, which
> means that point stays at point-max as compilation output is inserted
> into the buffer and Emacs scrolls the window to keep the latest output
> visible.  Very convenient.
>
> In 21.1.90, point is placed at point-min, so that you have to actively
> scroll the window to see compilation output.  I really don't like it!

I think this is due to the following change:

2007-12-27  Richard Stallman  <rms@gnu.org>

	* progmodes/compile.el (compilation-start): Set initial visible
	point properly even when compilation buffer already current.

Which was meant to address this complaint:

    From: Drew Adams Sent: Monday, December 11, 2006 3:21 PM
    Previously in Emacs 22, as well as in previous releases, , repeating
    grep in the *grep* buffer would put you at the top of the buffer. This
    was true at least as late as a build from 2006-07-19.
    
    Now, it puts you at the end of the buffer, so you must do M-< to get
    back to the beginning. Quite annoying.

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

[Marshall, Simon]

Wow, thanks for the quick response.  Well, the report is pre-21.1 and
the change is post-21.1, so we now have a change in behaviour from a
released version.  Did anyone complain about this post 21.1?

I, for one, prefer the 21.1 behaviour for *compilation* buffers.

But, I can see that the change is likely better for *grep* buffers.

Perhaps *compilation* should behave differently from *grep* in this
respect?

-----Original Message-----
From: Chong Yidong [mailto:cyd@stupidchicken.com] 
Sent: 04 February 2008 15:14
To: Marshall, Simon
Cc: Drew Adams; emacs-pretest-bug@gnu.org
Subject: Re: [21.1.90]: point put at point-min in *compilation*

"Marshall, Simon" <Simon.Marshall@misys.com> writes:

> In 21.1, if you run Compile | Compile... RET or Compile | Recompile in
a
> *compilation* buffer, point is initially placed at point-max, which
> means that point stays at point-max as compilation output is inserted
> into the buffer and Emacs scrolls the window to keep the latest output
> visible.  Very convenient.
>
> In 21.1.90, point is placed at point-min, so that you have to actively
> scroll the window to see compilation output.  I really don't like it!

I think this is due to the following change:

2007-12-27  Richard Stallman  <rms@gnu.org>

	* progmodes/compile.el (compilation-start): Set initial visible
	point properly even when compilation buffer already current.

Which was meant to address this complaint:

    From: Drew Adams Sent: Monday, December 11, 2006 3:21 PM
    Previously in Emacs 22, as well as in previous releases, , repeating
    grep in the *grep* buffer would put you at the top of the buffer.
This
    was true at least as late as a build from 2006-07-19.
    
    Now, it puts you at the end of the buffer, so you must do M-< to get
    back to the beginning. Quite annoying.


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[Drew Adams]

> Well, the report is pre-21.1 and
> the change is post-21.1, so we now have a change in behaviour from a
> released version.  Did anyone complain about this post 21.1?

My report was not only post-21.1; it was near the end of the Emacs 22
development cycle.

> I, for one, prefer the 21.1 behaviour for *compilation* buffers.

I have no preference for compilation buffers. My report was about grep.

> But, I can see that the change is likely better for *grep* buffers.

We agree about that.

> Perhaps *compilation* should behave differently from *grep* in this
> respect?

Agreed again. Or perhaps we could have a user option (or two).

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

[Marshall, Simon]

> > Well, the report is pre-21.1 and
> > the change is post-21.1, so we now have a change in behaviour from a
> > released version.  Did anyone complain about this post 21.1?
> 
> My report was not only post-21.1; it was near the end of the Emacs 22
> development cycle.

Sorry, my typos, I meant pre-22.1.  You reported it pre-22.1, the fix
went in post-22.1, so I wondered whether anyone complained about this in
22.1 itself.

> > Perhaps *compilation* should behave differently from *grep* in this
> > respect?
> 
> Agreed again. Or perhaps we could have a user option (or two).

Simon.


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[Chong Yidong]

"Marshall, Simon" <Simon.Marshall@misys.com> writes:

> In 21.1, if you run Compile | Compile... RET or Compile | Recompile in a
> *compilation* buffer, point is initially placed at point-max, which
> means that point stays at point-max as compilation output is inserted
> into the buffer and Emacs scrolls the window to keep the latest output
> visible.  Very convenient.
>
> In 21.1.90, point is placed at point-min, so that you have to actively
> scroll the window to see compilation output.  I really don't like it!

I think this is due to the following change:

2007-12-27  Richard Stallman  <rms@gnu.org>

            * progmodes/compile.el (compilation-start): Set initial visible
            point properly even when compilation buffer already current.

Which was meant to address this complaint:

    From: Drew Adams Sent: Monday, December 11, 2006 3:21 PM
    Previously in Emacs 22, as well as in previous releases, , repeating
    grep in the *grep* buffer would put you at the top of the buffer. This
    was true at least as late as a build from 2006-07-19.
    
    Now, it puts you at the end of the buffer, so you must do M-< to get
    back to the beginning. Quite annoying.

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

[Glenn Morris]

Chong Yidong wrote:

> I think this is due to the following change:
>
> 2007-12-27  Richard Stallman  <rms@gnu.org>
>
>             * progmodes/compile.el (compilation-start): Set initial visible
>             point properly even when compilation buffer already current.

This change seems to have made the behaviour consistent between
compilation invocations, AFAICS.

compilation-scroll-output (and grep-scroll-output) can be customized
to change the behaviour.

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

[Richard Stallman]

    In 21.1.90, point is placed at point-min, so that you have to actively
    scroll the window to see compilation output.  I really don't like it!

I made that change because someone complained about the old behavior.
The old behavior is inconsistent, doing one thing in the first compilation
and something else in a recompilation.

The new behavior is consistent: it does the same thing for the second
compilation and the first.

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

[Marshall, Simon]

> From: Richard Stallman [mailto:rms@gnu.org] 
> 
>     In 21.1.90, point is placed at point-min, so that you have to
actively
>     scroll the window to see compilation output.  I really don't like
it!
> 
> I made that change because someone complained about the old behavior.
> The old behavior is inconsistent, doing one thing in the 
> first compilation
> and something else in a recompilation.
> 
> The new behavior is consistent: it does the same thing for the second
> compilation and the first.

Ok.

Glenn Morris pointed out that I could use compilation-scroll-output and
grep-scroll-output to change the behaviour.  However, they aren't
mentioned in NEWS and they are not autoloaded, so I wasn't able to
discover what to do about this change.

I don't know what the guidelines are for autoloading custom options, but
perhaps at least there should be a NEWS entry to explain the change to
this behaviour, with a mention of these options (and any other
equivalents for other similar modes)?  

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.

Simon.


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[Stefan Monnier]

> 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,


        Stefan

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

[Richard Stallman]

    > 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?

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

[David Kastrup]

Richard Stallman <rms@gnu.org> 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?

It is frequently said that GCC is doing a good job at slowing down
compilation.  I also think that at least on some platforms
process-adaptive-read-buffering has some helpful effects (it did for
tramp until tramp put in some special code temporarily nilling it).

And people say that Emacs redisplay is also getting increasingly more
helpful here.

-- 
David Kastrup

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

[Marshall, Simon]

>     > 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.

But scrolling still has to occur for you to be able to see if there's
anything to read.  So, with a default of nil, you still have to scroll
the *compilation* window to see if there's anything worth reading and to
see what the progress is.  With a default of t, you only need to
intervene if you see something you want to linger on - and only then if
the compilation did not stop anyway because the something was a
compilation error - and you get the progress for free.


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[Richard Stallman]

    But scrolling still has to occur for you to be able to see if there's
    anything to read.

That is not true.  Starting a new compilation erases the buffer.
So you will certainly see that the output has started.  Then you
can read it at your own pace.

Or you can type M-> if I want to have it all scroll past.

      With a default of t, you only need to
    intervene if you see something you want to linger on - and only then if
    the compilation did not stop anyway because the something was a
    compilation error - and you get the progress for free.

If it scrolls automatically I often can't even SEE if there is
something I want to look at.  And supposing I do see, by the time
I can get my hands on the keyboard to type anything, a lot more
output will usually have come out.

My decision is not to change the default to t.

Stefan said:

    Has someone tried to use my new compilation-auto-jump-to-first-error?
    It stops the scrolling as soon as the first error is spotted.

I have not tried it, but it sounds like a good idea.
Is it installed already?  

Perhaps it should be another value of compilation-scroll-output,
rather than a separate option.

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

[Stefan Monnier]

>     Has someone tried to use my new compilation-auto-jump-to-first-error?
>     It stops the scrolling as soon as the first error is spotted.

> I have not tried it, but it sounds like a good idea.
> Is it installed already?  

Yes, it's been in the trunk for a few months now.

> Perhaps it should be another value of compilation-scroll-output,
> rather than a separate option.

That would be a different feature, then.
compilation-auto-jump-to-first-error only stops the scrolling as
a side-effect.  Its main effect is to do the equivalent of `next-error'
when an error is spotted, so it really jumps to the source code where
the first error was spotted.


        Stefan

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

[Richard Stallman]

    That would be a different feature, then.
    compilation-auto-jump-to-first-error only stops the scrolling as
    a side-effect.  Its main effect is to do the equivalent of `next-error'
    when an error is spotted, so it really jumps to the source code where
    the first error was spotted.

Indeed, that is not what I thought you meant.  That seems too drastic
to me.

However, feature that would stop scrolling at the first error and
leave point there, but would not go ahead and visit the source code on
its own, might be a good third option for `compilation-scroll-output'.

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

[Marshall, Simon]

>     But scrolling still has to occur for you to be able to see if
there's
>     anything to read.
> 
> That is not true.  Starting a new compilation erases the buffer.
> So you will certainly see that the output has started.  Then you
> can read it at your own pace.

Yes, you can read it by scrolling through it - that was my point above.
With a default of nil you still _always_ have to scroll yourself,
whereas with a default of t you _only_ have to scroll yourself if (a)
you see there is something worth reading and (b) the compilation hasn't
stopped anyway because that something was a fatal error.  And with t you
get the visual cue of progress status.

> If it scrolls automatically I often can't even SEE if there is
> something I want to look at.  And supposing I do see, by the time
> I can get my hands on the keyboard to type anything, a lot more
> output will usually have come out.

Iff you think you might have missed something, then you can scroll back.
But how is that different from scrolling forward, which you _always_
have to do with a default of nil?

If you care about compilation output and/or progress, a default of nil
means that you always have to do something (ie scroll), whereas with a
default of t you only occasionally have to do something.

> My decision is not to change the default to t.

Ok.  Though it is worth pointing out that the other few who have
expressed a preference have said that the default would be better as t.
It is also worth pointing out that the other (non-Emacs) build tool I
use also behaves that way.
Emacs 21 and 22.1 also behave that way (apart from the first invocation)
and I bet nobody complained about that.  (As I understand it, Drew was
complaining about M-x grep, which I agree with, and its default would be
better as nil.)

>     Has someone tried to use my new
compilation-auto-jump-to-first-error?
>     It stops the scrolling as soon as the first error is spotted.
> 
> I have not tried it, but it sounds like a good idea.
> Is it installed already?  

I would try it if it was in Emacs 22.


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[Miles Bader]

"Marshall, Simon" <Simon.Marshall@misys.com> writes:
> Ok.  Though it is worth pointing out that the other few who have
> expressed a preference have said that the default would be better as t.
> It is also worth pointing out that the other (non-Emacs) build tool I
> use also behaves that way.

Personally I'd prefer it scroll, and then stop at the first sign of an
error.  That seems like the best of both worlds...

-Miles

-- 
Hers, pron. His.

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

[David Kastrup]

"Marshall, Simon" <Simon.Marshall@misys.com> writes:

>>     But scrolling still has to occur for you to be able to see if
> there's
>>     anything to read.
>> 
>> That is not true.  Starting a new compilation erases the buffer.
>> So you will certainly see that the output has started.  Then you
>> can read it at your own pace.
>
> Yes, you can read it by scrolling through it - that was my point above.
> With a default of nil you still _always_ have to scroll yourself,
> whereas with a default of t you _only_ have to scroll yourself if (a)
> you see there is something worth reading and (b) the compilation hasn't
> stopped anyway because that something was a fatal error.  And with t you
> get the visual cue of progress status.
>
>> If it scrolls automatically I often can't even SEE if there is
>> something I want to look at.  And supposing I do see, by the time
>> I can get my hands on the keyboard to type anything, a lot more
>> output will usually have come out.
>
> Iff you think you might have missed something, then you can scroll
> back.

Uh no, you can't.  By the time you found the Prior button, twenty pages
of material will have gone by.

-- 
David Kastrup

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

[Marshall, Simon]

> > Iff you think you might have missed something, then you can scroll
> > back.

> Uh no, you can't.  By the time you found the Prior button, twenty
pages
> of material will have gone by.

Uh yes, you can.  Hit Prior "twenty" times.  Or was your point something
else?

Simon.


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[David Kastrup]

"Marshall, Simon" <Simon.Marshall@misys.com> writes:

>> > Iff you think you might have missed something, then you can scroll
>> > back.
>
>> Uh no, you can't.  By the time you found the Prior button, twenty
>> pages of material will have gone by.
>
> Uh yes, you can.  Hit Prior "twenty" times.

If it actually was 20 times...

> Or was your point something else?

I don't see how your argument maps to support this as the most
convenient setting.  Which is pretty much what this is supposed to be
about.

-- 
David Kastrup

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

[Marshall, Simon]

> I don't see how your argument maps to support this as the most
> convenient setting.  Which is pretty much what this is supposed to be
> about.

My point is that with the default of nil, I always have to actively
scroll the *compilation* window if I want either to see compilation
output and/or compilation progress.

With the default of t, I only have to scroll if there is some
compilation output that I want to see and that it didn't cause
compilation to stop anyway.

Convenient is a good choice of word: with the default of t, for me, the
convenience is that my effort is minimised.  I never have to do more
scrolling than if the default were nil, and I usually have to do nothing
at all.

But I am curious in understanding how, if you are interested in
compilation output and/or compilation progress, you interact with the
new *compilation* behaviour.  Do you always scroll through the
compilation output?  All 20 pages of it, to use your example?  If you do
not, I presume you are not interested in the output.  In which case, the
default value does not matter for you.  If you do, why do you prefer
that Emacs does not do almost all of the scrolling for you?

Simon.


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[David Kastrup]

"Marshall, Simon" <Simon.Marshall@misys.com> writes:

>> I don't see how your argument maps to support this as the most
>> convenient setting.  Which is pretty much what this is supposed to be
>> about.
>
> But I am curious in understanding how, if you are interested in
> compilation output and/or compilation progress, you interact with the
> new *compilation* behaviour.  Do you always scroll through the
> compilation output?

If I am looking for something, sure.

> All 20 pages of it, to use your example?  If you do not, I presume you
> are not interested in the output.  In which case, the default value
> does not matter for you.  If you do, why do you prefer that Emacs does
> not do almost all of the scrolling for you?

Because Emacs' speed of scrolling does not agree with my speed of reading.

-- 
David Kastrup

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

[Marshall, Simon]

> > All 20 pages of it, to use your example?  If you do not, I presume
you
> > are not interested in the output.  In which case, the default value
> > does not matter for you.  If you do, why do you prefer that Emacs
does
> > not do almost all of the scrolling for you?

> Because Emacs' speed of scrolling does not agree with my speed of
reading.

Ok, our solutions differ - I scroll back and read whatever it was if it
was too quick to scan at the time.  If there's nothing to read, I don't
have to scroll.
You always have to scroll regardless of whether there's anything to
read, because you don't know if there's anything to read unless you
scroll.



Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[Stefan Monnier]

>>> But scrolling still has to occur for you to be able to see if
>> there's
>>> anything to read.
>>> 
>>> That is not true.  Starting a new compilation erases the buffer.
>>> So you will certainly see that the output has started.  Then you
>>> can read it at your own pace.
>> 
>> Yes, you can read it by scrolling through it - that was my point above.
>> With a default of nil you still _always_ have to scroll yourself,
>> whereas with a default of t you _only_ have to scroll yourself if (a)
>> you see there is something worth reading and (b) the compilation hasn't
>> stopped anyway because that something was a fatal error.  And with t you
>> get the visual cue of progress status.
>> 
>>> If it scrolls automatically I often can't even SEE if there is
>>> something I want to look at.  And supposing I do see, by the time
>>> I can get my hands on the keyboard to type anything, a lot more
>>> output will usually have come out.
>> 
>> Iff you think you might have missed something, then you can scroll
>> back.

> Uh no, you can't.  By the time you found the Prior button, twenty pages
> of material will have gone by.

Both options are a M-< (resp. M->) away from one another in this
respect, so it doesn't really matter whether 1 or 20 pages follow or
precede the interesting spot.


        Stefan

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

[Juri Linkov]

> Ok.  Though it is worth pointing out that the other few who have
> expressed a preference have said that the default would be better as t.

I agree that the default value for compilation-scroll-output as t (or
maybe a new option `first-error') is more useful than nil, because when
the user is not interested in reading all output, but only wants to see
the result of compilation or its error messages, then there is no need to
switch to the compilation buffer and use scrolling commands in it, because
all necessary information will be displayed at the end of compilation
(either with point at the end of the compilation buffer or on the first
error).  Additionally, this will display the progress of compilation.
But when the user wants to read the whole compilation buffer, then M-< is
just the first scrolling command to type among many other to navigate in
the compilation buffer.

> It is also worth pointing out that the other (non-Emacs) build tool I
> use also behaves that way.
> Emacs 21 and 22.1 also behave that way (apart from the first invocation)
> and I bet nobody complained about that.  (As I understand it, Drew was
> complaining about M-x grep, which I agree with, and its default would be
> better as nil.)

Yes, unlike compilation, in the grep buffer it is important to start reading
the output from the top.

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Richard Stallman]

    Iff you think you might have missed something, then you can scroll back.
    But how is that different from scrolling forward, which you _always_
    have to do with a default of nil?

It is more natural to look through output in forward order
than in reverse order.

Also, the rapid output is very visually disturbing.
Unless I ignore it completely and block it out,
I find it quite annoying until I type M-< to make it stop.

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

[Stefan Monnier]

> 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?

Hmm.. I don't actually read it: I also watch it scroll and pick up a few
symbols here and there that allow me to figure out if things are going
smoothly or not.

When it doesn't scroll, the first screen is filled immediately with text
that I generally don't care about (most build procedures I use seem to
start with a lot of "boilerplate output"), so I have to scroll manually
to see the rest.

Of course, using C-x ` will jump to the interesting spot in either case.

Has someone tried to use my new compilation-auto-jump-to-first-error?
It stops the scrolling as soon as the first error is spotted.


        Stefan

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

[Juri Linkov]

> Has someone tried to use my new compilation-auto-jump-to-first-error?
> It stops the scrolling as soon as the first error is spotted.

I have tried compilation-auto-jump-to-first-error, and I like how it
automatically moves point to the first error in the compilation buffer.

But I can't use it because it also visits the source buffer without my
request by switching the current buffer where I am doing other things
during compilation.

For now, I commented out the call to `(compile-goto-error)' in
`compilation-auto-jump' locally.  Could you make this optional in CVS?

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Stefan Monnier]

>> Has someone tried to use my new compilation-auto-jump-to-first-error?
>> It stops the scrolling as soon as the first error is spotted.

> I have tried compilation-auto-jump-to-first-error, and I like how it
> automatically moves point to the first error in the compilation buffer.

> But I can't use it because it also visits the source buffer without my
> request by switching the current buffer where I am doing other things
> during compilation.

> For now, I commented out the call to `(compile-goto-error)' in
> `compilation-auto-jump' locally.  Could you make this optional in CVS?

Feel free to extend this feature.  It probably makes sense to make it
either not jump to the source (only jump to the error message itself) as
you suggest, or to use pop-to-buffer (so that people who set
pop-up-frames do not get bothered either).


        Stefan

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

[Juri Linkov]

> Feel free to extend this feature.  It probably makes sense to make it
> either not jump to the source (only jump to the error message itself)

The patch below adds a third option to compilation-scroll-output,
as Richard suggested, by reusing a part of the functionality of
compilation-auto-jump-to-first-error.

> or to use pop-to-buffer (so that people who set pop-up-frames do not
> get bothered either).

Maybe, the default value of compilation-auto-jump-to-first-error
should depend on pop-up-frames?

Index: lisp/progmodes/compile.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/progmodes/compile.el,v
retrieving revision 1.451
diff -c -r1.451 compile.el
*** lisp/progmodes/compile.el	14 Jan 2008 15:41:33 -0000	1.451
--- lisp/progmodes/compile.el	7 Feb 2008 19:57:04 -0000
***************
*** 762,768 ****
  (defun compilation-auto-jump (buffer pos)
    (with-current-buffer buffer
      (goto-char pos)
!     (compile-goto-error)))
  
  ;; This function is the central driver, called when font-locking to gather
  ;; all information needed to later jump to corresponding source code.
--- 762,769 ----
  (defun compilation-auto-jump (buffer pos)
    (with-current-buffer buffer
      (goto-char pos)
!     (if compilation-auto-jump-to-first-error
! 	(compile-goto-error))))
  
  ;; This function is the central driver, called when font-locking to gather
  ;; all information needed to later jump to corresponding source code.
***************
*** 1054,1061 ****
  
  Setting it causes the Compilation mode commands to put point at the
  end of their output window so that the end of the output is always
! visible rather than the beginning."
!   :type 'boolean
    :version "20.3"
    :group 'compilation)
  
--- 1055,1067 ----
  
  Setting it causes the Compilation mode commands to put point at the
  end of their output window so that the end of the output is always
! visible rather than the beginning.
! 
! The value `first-error' stops scrolling on encountering the first error,
! and moves point to its location in the *compilation* buffer."
!   :type '(choice (const :tag "No scrolling" nil)
! 		 (const :tag "Scroll compilation output" t)
! 		 (const :tag "Stop scrolling on the first error" first-error))
    :version "20.3"
    :group 'compilation)
  
***************
*** 1168,1174 ****
  	(if highlight-regexp
  	    (set (make-local-variable 'compilation-highlight-regexp)
  		 highlight-regexp))
!         (if compilation-auto-jump-to-first-error
              (set (make-local-variable 'compilation-auto-jump-to-next) t))
  	;; Output a mode setter, for saving and later reloading this buffer.
  	(insert "-*- mode: " name-of-mode
--- 1174,1181 ----
  	(if highlight-regexp
  	    (set (make-local-variable 'compilation-highlight-regexp)
  		 highlight-regexp))
!         (if (or compilation-auto-jump-to-first-error
! 		(eq compilation-scroll-output 'first-error))
              (set (make-local-variable 'compilation-auto-jump-to-next) t))
  	;; Output a mode setter, for saving and later reloading this buffer.
  	(insert "-*- mode: " name-of-mode
***************
*** 2159,2165 ****
    ;; compilations, to set the beginning of "this compilation", it's a good
    ;; place to reset compilation-auto-jump-to-next.
    (set (make-local-variable 'compilation-auto-jump-to-next)
!        compilation-auto-jump-to-first-error))
  
  ;;;###autoload
  (add-to-list 'auto-mode-alist '("\\.gcov\\'" . compilation-mode))
--- 2166,2173 ----
    ;; compilations, to set the beginning of "this compilation", it's a good
    ;; place to reset compilation-auto-jump-to-next.
    (set (make-local-variable 'compilation-auto-jump-to-next)
!        (or compilation-auto-jump-to-first-error
! 	   (eq compilation-scroll-output 'first-error))))
  
  ;;;###autoload
  (add-to-list 'auto-mode-alist '("\\.gcov\\'" . compilation-mode))

-- 
Juri Linkov
http://www.jurta.org/emacs/

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

[Marshall, Simon]

Hi Juri, this looks good.  (I think unilaterally jumping to the first
error is a bit intrusive for me.)

I'd try this, particularly if it could distinguish between warnings and
errors if the infrastructure allowed it (ie, I might prefer to stop on
errors but not warnings) and it could make it into 22.2...

-----Original Message-----
From: Juri Linkov [mailto:juri@jurta.org] 
Sent: 07 February 2008 19:57
To: Stefan Monnier
Cc: rms@gnu.org; emacs-pretest-bug@gnu.org; Marshall, Simon
Subject: Re: [21.1.90]: point put at point-min in *compilation*

> Feel free to extend this feature.  It probably makes sense to make it
> either not jump to the source (only jump to the error message itself)

The patch below adds a third option to compilation-scroll-output,
as Richard suggested, by reusing a part of the functionality of
compilation-auto-jump-to-first-error.

> or to use pop-to-buffer (so that people who set pop-up-frames do not
> get bothered either).

Maybe, the default value of compilation-auto-jump-to-first-error
should depend on pop-up-frames?


Misys and Misys International Banking Systems is a trading name for Misys International Banking Systems Limited which is registered in England and Wales under company registration number 00971479 and with its registered office address at Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP.    THIS E-MAIL DOES NOT CONSTITUTE THE COMMENCEMENT OF LEGAL RELATIONS BETWEEN YOU AND MISYS INTERNATIONAL BANKING SYSTEMS LIMITED. 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.

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

[Stefan Monnier]

> I'd try this, particularly if it could distinguish between warnings and
> errors if the infrastructure allowed it (ie, I might prefer to stop on
> errors but not warnings) and it could make it into 22.2...

Check compilation-skip-threshold,


        Stefan

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).

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

[Stefan Monnier]

>> > 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.

If you use compilation-auto-jump-first-error, then whether it jumps to
the first error or the first warning depends on your
compilation-skip-threshold.


        Stefan

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

[Richard Stallman]

    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.

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. ;-)

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

[Richard Stallman]

    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.

It sounds like this means it would scroll more slowly, but steadily,
unless/until it catches up with the end of the output.

It sounds worth a try.

    I have no problem editing in one window while window-point is moving
    in another.

I too can do that, if I block out whatever happens in the other
window.