[lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Richard Stallman]

[I sent this message twice but did not get a response.]

Would someone please DTRT and ack?

------- Start of forwarded message -------
Date: Sat, 16 Dec 2006 14:02:48 +0100
From: Lennart Borgman <lennart.borgman.073@student.lu.se>
MIME-Version: 1.0
To: Emacs Devel <emacs-devel@gnu.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Subject: compilation-previous-error fails if first error is at start of
	buffer
X-Spam-Status: No, score=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS 
	autolearn=no version=3.0.4

If the compilation buffer begins with error lines right at the top:

c:/EmacsW32/etc/EmacsW32Util.html:7:5: Warning: <link> inserting "type" 
attribute
c:/EmacsW32/etc/EmacsW32Util.html:12:19: Warning: <table> lacks 
"summary" attribute
c:/EmacsW32/etc/EmacsW32Util.html:29:5: Warning: <table> lacks "summary" 
attribute

then if point is on second line compilation-previous-error fails.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
------- End of forwarded message -------

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Jan Djärv]

Richard Stallman skrev:
> [I sent this message twice but did not get a response.]
> 
> Would someone please DTRT and ack?
> 
> ------- Start of forwarded message -------
> Date: Sat, 16 Dec 2006 14:02:48 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> MIME-Version: 1.0
> To: Emacs Devel <emacs-devel@gnu.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Subject: compilation-previous-error fails if first error is at start of
> 	buffer
> X-Spam-Status: No, score=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS 
> 	autolearn=no version=3.0.4
> 
> If the compilation buffer begins with error lines right at the top:
> 
> c:/EmacsW32/etc/EmacsW32Util.html:7:5: Warning: <link> inserting "type" 
> attribute
> c:/EmacsW32/etc/EmacsW32Util.html:12:19: Warning: <table> lacks 
> "summary" attribute
> c:/EmacsW32/etc/EmacsW32Util.html:29:5: Warning: <table> lacks "summary" 
> attribute
> 
> then if point is on second line compilation-previous-error fails.
> 

What is the error message?

	Jan D.

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Nick Roberts]

 > > If the compilation buffer begins with error lines right at the top:
 > > 
 > > c:/EmacsW32/etc/EmacsW32Util.html:7:5: Warning: <link> inserting "type" 
 > > attribute
 > > c:/EmacsW32/etc/EmacsW32Util.html:12:19: Warning: <table> lacks 
 > > "summary" attribute
 > > c:/EmacsW32/etc/EmacsW32Util.html:29:5: Warning: <table> lacks "summary" 
 > > attribute
 > > 
 > > then if point is on second line compilation-previous-error fails.
 > > 
 > 
 > What is the error message?

Warnings and errors are equivalent in the compilation buffer.  I don't see how
Lennart gets error lines right at the top as I always get the following four
lines:

    -*- mode: compilation; default-directory: "~/" -*-
    Compilation started at Mon Jan  8 21:22:48

    `command used for my compilation'


Perhaps this is for his patched version.  Anyway there's not much point fixing
it when, like the heads of the Lernaean Hydra, two new bugs will take it's
place in FOR-RELEASE.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Jan Djärv]

Nick Roberts skrev:
>  > > If the compilation buffer begins with error lines right at the top:
>  > > 
>  > > c:/EmacsW32/etc/EmacsW32Util.html:7:5: Warning: <link> inserting "type" 
>  > > attribute
>  > > c:/EmacsW32/etc/EmacsW32Util.html:12:19: Warning: <table> lacks 
>  > > "summary" attribute
>  > > c:/EmacsW32/etc/EmacsW32Util.html:29:5: Warning: <table> lacks "summary" 
>  > > attribute
>  > > 
>  > > then if point is on second line compilation-previous-error fails.
>  > > 
>  > 
>  > What is the error message?
> 
> Warnings and errors are equivalent in the compilation buffer.

I was referring to some message in the minibuffer and *Messages*, like:

   compilation-next-error: Moved back before first error

> I don't see how
> Lennart gets error lines right at the top as I always get the following four
> lines:
> 
>     -*- mode: compilation; default-directory: "~/" -*-
>     Compilation started at Mon Jan  8 21:22:48
> 
>     `command used for my compilation'
> 

I always get these too.

> 
> Perhaps this is for his patched version.  Anyway there's not much point fixing
> it when, like the heads of the Lernaean Hydra, two new bugs will take it's
> place in FOR-RELEASE.

If it is for some patched version, we can probably ignore it.  There is no way 
I can reproduce it with the given information anyway.

	Jan D.

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Lennart Borgman (gmail)]

Nick Roberts wrote:
>  > > If the compilation buffer begins with error lines right at the top:
>  > > 
>  > > c:/EmacsW32/etc/EmacsW32Util.html:7:5: Warning: <link> inserting "type" 
>  > > attribute
>  > > c:/EmacsW32/etc/EmacsW32Util.html:12:19: Warning: <table> lacks 
>  > > "summary" attribute
>  > > c:/EmacsW32/etc/EmacsW32Util.html:29:5: Warning: <table> lacks "summary" 
>  > > attribute
>  > > 
>  > > then if point is on second line compilation-previous-error fails.
>  > > 
>  > 
>  > What is the error message?
> 
> Warnings and errors are equivalent in the compilation buffer.  I don't see how
> Lennart gets error lines right at the top as I always get the following four
> lines:
> 
>     -*- mode: compilation; default-directory: "~/" -*-
>     Compilation started at Mon Jan  8 21:22:48
> 
>     `command used for my compilation'


The output is from a library not included in Emacs (actually a version 
of tidy.el). The output does not have the lines above at the beginning. 
It would be rather inconvenient if it had, but maybe those line still 
should be there for some reason?


> 
> Perhaps this is for his patched version.  Anyway there's not much point fixing
> it when, like the heads of the Lernaean Hydra, two new bugs will take it's
> place in FOR-RELEASE.

I do not send bug report for the patched version, of course. (And I have 
tried to make it clear on download page on my site that you should use 
the unpatched version for bug reports.)

Here is a way to reproduce the error (CVS Emacs from 2007-01-03):

     emacs -Q
     M-: (switch-to-buffer "TEST")

Paste these lines (inside the "cut lines") into the buffer:

 >>>>> cut here >>>>>>>
c:/EmacsW32/nxml/nxhtml/doc/temp.htm:9:5: Warning: missing </h1> before 
</h3>
c:/EmacsW32/nxml/nxhtml/doc/temp.htm:10:5: Warning: discarding 
unexpected </h3>
c:/EmacsW32/nxml/nxhtml/doc/temp.htm:9:5: Warning: trimming empty <h1>
Info: Doctype given is "-//W3C//DTD XHTML 1.1//EN"
Info: Document content looks like XHTML 1.1
3 warnings, 0 errors were found!
<<<<<<<< cut here <<<<<<<<<<<<

so that the first error is on the first line of the buffer TEST, the 
second error on the second line and the third error on the third line. 
(You may have to edit this a bit because of line breaks in this mail 
message.) Now do

     M-x compilation-mode

Go to the beginning of the buffer. Press TAB. The point should move to 
the second error line. Press TAB again -> to third line.

Now press S-TAB. Should go to second line. S-TAB again should go to 
first line, but it does not.

Is this enough to reproduce it for you?

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Jan Djärv]

Lennart Borgman (gmail) skrev:
> Nick Roberts wrote:
>>  > > If the compilation buffer begins with error lines right at the top:
>>  > >  > > c:/EmacsW32/etc/EmacsW32Util.html:7:5: Warning: <link> 
>> inserting "type"  > > attribute
>>  > > c:/EmacsW32/etc/EmacsW32Util.html:12:19: Warning: <table> lacks 
>>  > > "summary" attribute
>>  > > c:/EmacsW32/etc/EmacsW32Util.html:29:5: Warning: <table> lacks 
>> "summary"  > > attribute
>>  > >  > > then if point is on second line compilation-previous-error 
>> fails.
>>  > >  >  > What is the error message?
>>
>> Warnings and errors are equivalent in the compilation buffer.  I don't 
>> see how
>> Lennart gets error lines right at the top as I always get the 
>> following four
>> lines:
>>
>>     -*- mode: compilation; default-directory: "~/" -*-
>>     Compilation started at Mon Jan  8 21:22:48
>>
>>     `command used for my compilation'
> 
> 
> The output is from a library not included in Emacs (actually a version 
> of tidy.el). The output does not have the lines above at the beginning. 
> It would be rather inconvenient if it had, but maybe those line still 
> should be there for some reason?
> 

Yes there is a reason.  Compilation mode uses previous-single-property-change 
to scan backwards to find the correct position to go to.  But if a line begins 
at buffer start, there is no property change and 
previous-single-property-change return nil.

I think you should modify your library to add an empty line at the top, or 
maybe some informative text.

	Jan D.

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Lennart Borgman (gmail)]

Jan Djärv wrote:

>> The output is from a library not included in Emacs (actually a version 
>> of tidy.el). The output does not have the lines above at the 
>> beginning. It would be rather inconvenient if it had, but maybe those 
>> line still should be there for some reason?
>>
> 
> Yes there is a reason.  Compilation mode uses 
> previous-single-property-change to scan backwards to find the correct 
> position to go to.  But if a line begins at buffer start, there is no 
> property change and previous-single-property-change return nil.
> 
> I think you should modify your library to add an empty line at the top, 
> or maybe some informative text.



Thanks, I modified the libraries a while ago when I realized this. And 
then I forgot about it. No one else seemed to care.

I agree that there is no need to change Emacs behaviour here, but since 
no one understood from the beginning what is going on it might perhaps 
be good to document it.

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Stefan Monnier]

> Yes there is a reason.  Compilation mode uses
> previous-single-property-change to scan backwards to find the correct
> position to go to.  But if a line begins at buffer start, there is no
> property change and previous-single-property-change return nil.

Can't it be fixed to handle the case where previous-single-property-change
returns nil?


        Stefan

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Jan Djärv]

Stefan Monnier skrev:
>> Yes there is a reason.  Compilation mode uses
>> previous-single-property-change to scan backwards to find the correct
>> position to go to.  But if a line begins at buffer start, there is no
>> property change and previous-single-property-change return nil.
> 
> Can't it be fixed to handle the case where previous-single-property-change
> returns nil?

Maybe, but AFAIK it uses that return value to determine if the error message 
is the first one.

	Jan D.

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Richard Stallman]

    Yes there is a reason.  Compilation mode uses previous-single-property-change 
    to scan backwards to find the correct position to go to.  But if a line begins 
    at buffer start, there is no property change and 
    previous-single-property-change return nil.

It would be easy to fix the code to DTRT at the start of the buffer.
Why not make it more robust?

Bug reporting (was: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer])

[Stefan Monnier]

> I do not send bug report for the patched version, of course. (And I have
> tried to make it clear on download page on my site that you should use the
> unpatched version for bug reports.)

The recommendation should *always* be to do M-x report-emacs-bug.
And make sure that the patched version changes report-emacs-bug-address and
report-emacs-bug-pretest-address to your own address.


        Stefan

Re: Bug reporting

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> I do not send bug report for the patched version, of course. (And I have
>> tried to make it clear on download page on my site that you should use the
>> unpatched version for bug reports.)
> 
> The recommendation should *always* be to do M-x report-emacs-bug.
> And make sure that the patched version changes report-emacs-bug-address and
> report-emacs-bug-pretest-address to your own address.


Yes, that is a good way to do it. Less to remember for the users.

And then perhaps include some text that makes the situation clear. 
Something about "try the unpatched version bla bla ....".


I will change this as soon as I get time.

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Nick Roberts]

 >...
 > (You may have to edit this a bit because of line breaks in this mail 
 > message.) Now do
 > 
 >      M-x compilation-mode
 > 
 > Go to the beginning of the buffer. Press TAB. The point should move to 
 > the second error line. Press TAB again -> to third line.
 > 
 > Now press S-TAB. Should go to second line. S-TAB again should go to 
 > first line, but it does not.
 > 
 > Is this enough to reproduce it for you?

Does this fix it?  You'll need to gorilla test it to check there are no new
bugs.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


*** compile.el	09 Jan 2007 17:31:50 +1300	1.414
--- compile.el	11 Jan 2007 17:03:44 +1300	
*************** Just inserts the text, but uses `insert-
*** 1500,1508 ****
  	  (error ,error compilation-error))
        ;; prop 'message usually has 2 changes, on and off, so re-search if off
        (or (setq msg (get-text-property pt 'message))
! 	  (if (setq pt (,property-change pt 'message))
! 	      (setq msg (get-text-property pt 'message)))
! 	  (error ,error compilation-error))
        (or (< (cadr msg) compilation-skip-threshold)
  	  (if different-file
  	      (eq (prog1 last (setq last (nth 2 (car msg))))
--- 1500,1510 ----
  	  (error ,error compilation-error))
        ;; prop 'message usually has 2 changes, on and off, so re-search if off
        (or (setq msg (get-text-property pt 'message))
! 	  (progn
! 	    (setq pt (or (,property-change pt 'message)
! 			 (if (> n 0) (point-max) (point-min))))
! 	    (unless (setq msg (get-text-property pt 'message))
! 	      (error ,error compilation-error))))
        (or (< (cadr msg) compilation-skip-threshold)
  	  (if different-file
  	      (eq (prog1 last (setq last (nth 2 (car msg))))
*************** Does NOT find the source line like \\[ne
*** 1543,1551 ****
  			    (if (get-buffer-process (current-buffer))
  				"No more %ss yet"
  			      "Moved past last %s"))
- 	;; Don't move "back" to message at or before point.
- 	;; Pass an explicit (point-min) to make sure pt is non-nil.
- 	(setq pt (previous-single-property-change pt 'message nil (point-min)))
  	(compilation-loop < previous-single-property-change 1+
  			  "Moved back before first %s")))
      (goto-char pt)
--- 1545,1550 ----

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Nick Roberts]

Nick Roberts writes:
 >  >...
 >  > (You may have to edit this a bit because of line breaks in this mail 
 >  > message.) Now do
 >  > 
 >  >      M-x compilation-mode
 >  > 
 >  > Go to the beginning of the buffer. Press TAB. The point should move to 
 >  > the second error line. Press TAB again -> to third line.
 >  > 
 >  > Now press S-TAB. Should go to second line. S-TAB again should go to 
 >  > first line, but it does not.
 >  > 
 >  > Is this enough to reproduce it for you?
 > 
 > Does this fix it?  You'll need to gorilla test it to check there are no new
 > bugs.
 > 

Have you tested it?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Richard Stallman]

    Perhaps this is for his patched version.  Anyway there's not much point fixing
    it when, like the heads of the Lernaean Hydra, two new bugs will take it's
    place in FOR-RELEASE.

If you don't fix bugs, you will have to wait for me to have time to
fix them.

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Nick Roberts]

 >     Perhaps this is for his patched version.  Anyway there's not much point
 >     fixing it when, like the heads of the Lernaean Hydra, two new bugs will
 >     take it's place in FOR-RELEASE.
 > 
 > If you don't fix bugs, you will have to wait for me to have time to
 > fix them.

I stopped waiting long ago.  If the bugs are filed as proper bug reports, in a
proper bug database, then I think you are more likely to find someone who is
willing/able to fix them.  This bug evidently never occurs in a normal
compilation buffer, so it is a marginal one at best.  I can't see how anyone
benefits from holding back the release for such bugs, except, perhaps,
the vendors of proprietary software.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [lennart.borgman.073@student.lu.se: compilation-previous-error fails if first error is at start of buffer]

[Chris Moore]

Richard Stallman <rms@gnu.org> writes:

> [I sent this message twice but did not get a response.]

I responded before you sent either of them.

> If the compilation buffer begins with error lines right at the top:

Compilation buffers don't begin with error lines.  They begin like
this:

  -*- mode: compilation; default-directory: "~/" -*-
  Compilation started at Mon Jan  8 14:08:26

and they are read-only, too, so I'd have to go out of my way to make
them start with an error line.

On other news: Python-mode can't parse C code and dired doesn't work
if the dired buffer doesn't contain a directory listing.

bug reporting

[Benjamin Dreux]

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

Hi i'm a emacs22 user. I really appreciate it.
Like i say in the titile i found a bug in the parentheses matching. I'm
coding into c++ and i worte that:
bool flotte::continuer()
{
  return nbBateau[5]>nbBateau[6];
}

If you try it you will see that the > thake the place of the }.

In the hope that could help you.
Thanks a lot for the fsf work.
Benjamin DREUX

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

Re: bug reporting

[Chong Yidong]

"Benjamin Dreux" <benjiiiiii@gmail.com> writes:

> Like i say in the titile i found a bug in the parentheses
> matching. I'm coding into c++ and i worte that:
>
> bool flotte::continuer()
> {
>   return nbBateau[5]>nbBateau[6];
> }
>
> If you try it you will see that the > thake the place of the }.

I can't reproduce this.  Could you give a more precise recipe?

Re: bug reporting

[martin rudalics]

> bool flotte::continuer()
> {
>   return nbBateau[5]>nbBateau[6];
> }

Could you please move the cursor immediately before the > type

M-x: describe-char RET

and post here what Emacs tells you.