guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] Support Guile backtraces in compilation mode.


From: Stefan Monnier
Subject: Re: [PATCH 1/3] Support Guile backtraces in compilation mode.
Date: Fri, 08 Aug 2014 09:29:32 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

> @@ -477,6 +505,8 @@ File = \\(.+\\), Line = \\([0-9]+\\)\\(?:, Column = 
> \\([0-9]+\\)\\)?"
>       ;;
>       "^\\([^ \t\r\n(]+\\) (\\([0-9]+\\):\\([0-9]+\\)) "
>       1 2 3)
> +    (guile-file "^In \\(.+\\):\n" compilation-guile-in-find-file)
> +    (guile-line "^ *\\([0-9]+\\): *\\([0-9]+\\)" nil 1 2)
>      )
>    "Alist of values for `compilation-error-regexp-alist'.")
 
Quick comments:
- You can collapse all three patches into a single one.
- Both of those Guile regexps are much too generic (i.e. likely to
  appear in non-Guile output), while the corresponding handler you
  provide is clearly very Guile-specific.  This is a *serious* problem.
- I think a good way to solve it would be to push the problem upstream ;-)
  IOW, convince the Guile guys to follow the GNU convention.  This could
  look somewhat like:

   * Guile backtraces
   
   Backtrace:
   /some/where/ice-9/boot-9.scm:157:
      6 [catch #t #<catch-closure 196e3e0> ...]
   unknown file:?:
      5 [apply-smob/1 #<catch-closure 196e3e0>]
   /some/where/ice-9/boot-9.scm:63:
      4 [call-with-prompt prompt0 ...]
   /some/where/ice-9/eval.scm:432:
      3 [eval # #]
   unknown file:?:
      2 [eval (main (command-line)) #<directory (gud-break) 1962510>]
   /home/janneke/vc/guile/examples/gud-break.scm:1038:
      1 [main ("gud-break.scm")]
      0 [stderr "~a:hello world\n" (# # #)]

  With the above, you might not even need to change compile.el.  Tho,
  admittedly, the above lines might end up highlighted as "errors"
  whereas they should probably be treated as "info", so some annotation
  on the "FILE:LINE:" lines would be helpful to let Emacs know that it's
  not an "error" location, but just an "info".  Not sure if the GNU
  conventions already include such an annotation, but I can't see why
  that couldn't be arranged.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]