From: "Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: 60830@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors
Date: Thu, 05 Oct 2023 18:21:02 +0200 [thread overview]
Message-ID: <m25y3lyr9t.fsf@me.com> (raw)
In-Reply-To: <909EF5E1-6F30-4A35-84E8-2EF4333115FD@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
Mattias Engdegård <mattias.engdegard@gmail.com> writes:
> This pattern matches some lines normally matched by the `gnu` rule
> which comes later in the rule list. I don't know if it's a big problem
> -- it may cause misclassification of some messages which should be of
> 'warning' or 'info' type.
Good to know! So, I studied 'luaL_traceback' in 'lauxlib.c' in Lua and
made the regular expression more precise. No more mis-classification!
> I'm actually slightly more bothered by this message because it would
> conflict with possible future (re-)relaxation of the `gnu` rule with
> respect to leading whitespace. The matter does come up from time to
> time, and it would be nice to at least have the option to do that.
Ditto; I made other expression more precise as well!
> The 'omake' rule has now been disabled by default for other reasons
> (it's something that has been discussed in the past), so there is at
> least precedence for doing this.
/Note:/ I rebased on top of 'master' (and so the 'omake' patch).
See the new patch, with more precise regular expressions, attached
below. While on it, I also added support for stack frames with no line
number, as per Lua source code. Lastly, I added a NEWS entry, as well
as, improved the commit message a bit.
How about now? :)
Rudy
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-the-Compilation-mode-recognize-Lua-errors.patch --]
[-- Type: text/x-patch, Size: 4001 bytes --]
From a267051c042b89b650e2a15597d226fe26579826 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= <salutis@me.com>
Date: Tue, 3 Oct 2023 09:07:40 +0200
Subject: [PATCH] Make the Compilation mode recognize Lua errors
Emacs comes with built-in support for the Lua programming language in
the form of the Lua mode and now also the Lua Tree-sitter mode. This
patch further improves Lua support in Emacs by making the Compilation
mode recognize Lua errors and stack traces.
Reported as bug#60830.
* lisp/progmodes/compile.el (compilation-error-regexp-alist-alist):
Add regexps to aid Lua development, namely the 'lua' regexp that
matches Lua errors and the 'lua-stack' regexp that matches Lua stack
frames.
* test/lisp/progmodes/compile-tests.el (compile-tests--test-regexps-data):
(compile-test-error-regexps): Test the new 'lua' and 'lua-stack'
regexps added to the 'compilation-error-regexp-alist-alist'.
---
etc/NEWS | 5 +++++
lisp/progmodes/compile.el | 7 +++++++
test/lisp/progmodes/compile-tests.el | 15 +++++++++++++--
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/etc/NEWS b/etc/NEWS
index 12c2d52a4ab..cf98e8d6f43 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -307,6 +307,11 @@ This is because it partly acts by modifying other rules which may
occasionally be surprising. It can be re-enabled by adding 'omake' to
'compilation-error-regexp-alist'.
+*** Lua errors and stack traces are now recognized.
+The compilation mode now recognizes Lua language errors and stack
+traces. Every Lua error is recognized as a compilation error, and
+every Lua stack frame is recognized as a compilation info.
+
** VC
---
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 9e441dbfcf7..97d4be52286 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -362,6 +362,13 @@ compilation-error-regexp-alist-alist
(ruby-Test::Unit
"^ [[ ]?\\([^ (].*\\):\\([1-9][0-9]*\\)\\(\\]\\)?:in " 1 2)
+ (lua
+ "^[^:\n\t]+: \\([^: \n\t]+\\):\\([0-9]+\\): .*?\nstack traceback:\n\t"
+ 1 2 nil 2 1)
+ (lua-stack
+ "^\t\\([^:\n\t]+\\):\\(\\([0-9]+\\):\\)? in "
+ 1 3 nil 0 1)
+
(gmake
;; Set GNU make error messages as INFO level.
;; It starts with the name of the make program which is variable,
diff --git a/test/lisp/progmodes/compile-tests.el b/test/lisp/progmodes/compile-tests.el
index d497644c389..18c422a5afe 100644
--- a/test/lisp/progmodes/compile-tests.el
+++ b/test/lisp/progmodes/compile-tests.el
@@ -206,6 +206,17 @@ compile-tests--test-regexps-data
1 0 31 "/usr/include/c++/3.3/backward/iostream.h")
(gcc-include " from test_clt.cc:1:"
1 nil 1 "test_clt.cc")
+ ;; Lua
+ (lua "lua: database.lua:10: assertion failed!\nstack traceback:\n\t"
+ 6 nil 10 "database.lua")
+ (lua "/usr/local/bin/lua: core/database.lua:20: assertion failed!\nstack traceback:\n\t"
+ 21 nil 20 "core/database.lua")
+ (lua-stack " database.lua: in field 'statement'"
+ 2 nil nil "database.lua" 0)
+ (lua-stack " database.lua:10: in field 'statement'"
+ 2 nil 10 "database.lua" 0)
+ (lua-stack " core/database.lua:20: in field 'statement'"
+ 2 nil 20 "core/database.lua" 0)
;; gmake
(gmake "make: *** [Makefile:20: all] Error 2" 12 nil 20 "Makefile" 0)
(gmake "make[4]: *** [sub/make.mk:19: all] Error 127" 15 nil 19
@@ -507,9 +518,9 @@ compile-test-error-regexps
1 15 5 "alpha.c")))
(compile--test-error-line test))
- (should (eq compilation-num-errors-found 100))
+ (should (eq compilation-num-errors-found 102))
(should (eq compilation-num-warnings-found 35))
- (should (eq compilation-num-infos-found 28)))))
+ (should (eq compilation-num-infos-found 31)))))
(ert-deftest compile-test-grep-regexps ()
"Test the `grep-regexp-alist' regexps.
--
2.39.3 (Apple Git-145)
[-- Attachment #3: Type: text/plain, Size: 190 bytes --]
--
"If you're thinking without writing, you only think you're thinking."
--- Leslie Lamport
Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
next prev parent reply other threads:[~2023-10-05 16:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-15 11:33 bug#60830: 30.0.50; The *Compilation* buffer does not recognize Lua errors Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-13 14:55 ` Stefan Kangas
2023-10-02 12:04 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-02 18:37 ` Stefan Kangas
2023-10-03 8:12 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-03 9:37 ` Stefan Kangas
2023-10-03 20:03 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-05 11:27 ` Mattias Engdegård
2023-10-05 16:21 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-10-06 11:38 ` Mattias Engdegård
2023-10-06 13:21 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 14:00 ` Mattias Engdegård
2023-10-06 14:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 16:20 ` Mattias Engdegård
2023-10-06 16:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07 11:18 ` Mattias Engdegård
2023-10-07 15:22 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 10:45 ` Mattias Engdegård
2023-10-08 14:47 ` Mattias Engdegård
2023-10-07 21:02 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08 9:59 ` Mattias Engdegård
2023-10-12 8:12 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 8:17 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 14:32 ` Mattias Engdegård
2023-12-10 22:53 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 13:48 ` Stefan Kangas
2024-01-10 16:37 ` Mattias Engdegård
2024-01-10 17:09 ` Stefan Kangas
2024-01-10 17:45 ` Mattias Engdegård
2023-10-08 15:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-12 8:14 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m25y3lyr9t.fsf@me.com \
--to=bug-gnu-emacs@gnu.org \
--cc=60830@debbugs.gnu.org \
--cc=mattias.engdegard@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=salutis@me.com \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).