unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Changes to emacs/doc/emacs/building.texi,v
@ 2008-11-16 23:57 Juri Linkov
  2008-11-17  1:53 ` Chong Yidong
  2008-11-17  4:25 ` Stefan Monnier
  0 siblings, 2 replies; 5+ messages in thread
From: Juri Linkov @ 2008-11-16 23:57 UTC (permalink / raw)
  To: emacs-devel

In the 2008-10-31 commit of building.texi I noticed the following change:

   @findex compile-goto-error
  +@vindex compilation-auto-jump-to-first-error
     You can visit the source for any particular error message by moving
   point in the @samp{*compilation*} buffer to that error message and
   typing @key{RET} (@code{compile-goto-error}).  Alternatively, you can
   click @kbd{Mouse-2} on the error message; you need not switch to the
  - <at> samp{*compilation*} buffer first.
  +@samp{*compilation*} buffer first.  If you set the variable
  +@code{compilation-auto-jump-to-first-error} to a non-@code{nil} value,
  +Emacs automatically jumps to the first error (if any exists) once
  +compilation finishes.

Actually it jumps to the first error immediately after it occurs.

Perhaps this is caused by the inaccuracy in the doc string of
`compilation-auto-jump-to-first-error' that says:

  If non-nil, automatically jump to the first error after `compile'.

A better variant would be:

  If non-nil, automatically jump to the first error during `compile'.

BTW, maybe a new option `first-error' of `compilation-scroll-output'
should be documented in the manual too?

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




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

* Re: Changes to emacs/doc/emacs/building.texi,v
  2008-11-16 23:57 Changes to emacs/doc/emacs/building.texi,v Juri Linkov
@ 2008-11-17  1:53 ` Chong Yidong
  2008-11-17  4:25 ` Stefan Monnier
  1 sibling, 0 replies; 5+ messages in thread
From: Chong Yidong @ 2008-11-17  1:53 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

Juri Linkov <juri@jurta.org> writes:

> Actually it jumps to the first error immediately after it occurs.

Thanks.  I've fixed the manual and the docstring.

> BTW, maybe a new option `first-error' of `compilation-scroll-output'
> should be documented in the manual too?

Yes.  I've fixed the manual.  It also needed a NEWS entry---I've added
that.




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

* Re: Changes to emacs/doc/emacs/building.texi,v
  2008-11-16 23:57 Changes to emacs/doc/emacs/building.texi,v Juri Linkov
  2008-11-17  1:53 ` Chong Yidong
@ 2008-11-17  4:25 ` Stefan Monnier
  2008-11-17 22:35   ` Juri Linkov
  1 sibling, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2008-11-17  4:25 UTC (permalink / raw)
  To: Juri Linkov; +Cc: emacs-devel

>   If non-nil, automatically jump to the first error after `compile'.
> A better variant would be:
>   If non-nil, automatically jump to the first error during `compile'.

I'm not convinced: `compile' runs the command asynchronously, so the
jump is definitely done *after* compile, strictly speaking.  Maybe it
should just not say `compile', especially since it's also used in
circumstances where `compile' is not involved (e.g. sml-compile which
passes the compilation request to an inferior process running in
a comint buffer).

So, I'd prefer "during compilation" rather than "during `compile'".


        Stefan




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

* Re: Changes to emacs/doc/emacs/building.texi,v
  2008-11-17  4:25 ` Stefan Monnier
@ 2008-11-17 22:35   ` Juri Linkov
  2008-11-17 22:49     ` martin rudalics
  0 siblings, 1 reply; 5+ messages in thread
From: Juri Linkov @ 2008-11-17 22:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

>>   If non-nil, automatically jump to the first error after `compile'.
>> A better variant would be:
>>   If non-nil, automatically jump to the first error during `compile'.
>
> I'm not convinced: `compile' runs the command asynchronously, so the
> jump is definitely done *after* compile, strictly speaking.  Maybe it
> should just not say `compile', especially since it's also used in
> circumstances where `compile' is not involved (e.g. sml-compile which
> passes the compilation request to an inferior process running in
> a comint buffer).
>
> So, I'd prefer "during compilation" rather than "during `compile'".

Certainly, there is uncertainty in the phrase "after `compile'"
as it can mean both "after starting" and "after finishing".
I agree that the phrase "during compilation" has no such problems.

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




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

* Re: Changes to emacs/doc/emacs/building.texi,v
  2008-11-17 22:35   ` Juri Linkov
@ 2008-11-17 22:49     ` martin rudalics
  0 siblings, 0 replies; 5+ messages in thread
From: martin rudalics @ 2008-11-17 22:49 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel

 >> So, I'd prefer "during compilation" rather than "during `compile'".
 >
 > Certainly, there is uncertainty in the phrase "after `compile'"
 > as it can mean both "after starting" and "after finishing".
 > I agree that the phrase "during compilation" has no such problems.

Maybe we should explain in two or three sentences what really happens
instead of using such fuzzy terms.

martin





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

end of thread, other threads:[~2008-11-17 22:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-16 23:57 Changes to emacs/doc/emacs/building.texi,v Juri Linkov
2008-11-17  1:53 ` Chong Yidong
2008-11-17  4:25 ` Stefan Monnier
2008-11-17 22:35   ` Juri Linkov
2008-11-17 22:49     ` martin rudalics

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