From: David Engster <deng@randomsample.de>
To: Glenn Morris <rgm@gnu.org>
Cc: "18444@debbugs.gnu.org" <18444@debbugs.gnu.org>,
Martin Apel <martin.apel@simpack.de>
Subject: bug#18444: 24.3.93; Error running timer 'compilation-auto-jump' from grep-mode
Date: Sat, 20 Sep 2014 11:10:31 +0200 [thread overview]
Message-ID: <87fvfmverc.fsf@engster.org> (raw)
In-Reply-To: <xgd2b1hh2o.fsf@fencepost.gnu.org> (Glenn Morris's message of "Thu, 11 Sep 2014 19:29:19 -0400")
Glenn Morris writes:
> Glenn Morris wrote:
>
>> (I think it mistakenly tries to find a hit in the "Grep started" line for
>> some reason.)
>
> It's because
>
> Grep started at Thu Sep 11 16:25:19
>
> matches the first element of grep-regexp-alist:
>
> "^\\(.+?\\)\\(:[ \t]*\\)\\([1-9][0-9]*\\)\\2"
I've looked into this a bit, and I think this must be fixed in
compile.el itself. The underlying problem is that compile.el will parse
its own output for errors, and this is clearly wrong. This does not only
happen with the the above "Grep started at ..." message, but also the
final line "Grep finished (...) at". Funny thing is that RMS himself had
seen this latter problem as well in 2002, and added the following to
`compilation-handle-exit' (rev. 42924):
;; Prevent that message from being recognized as a compilation error.
(add-text-properties omax (point)
(append '(compilation-handle-exit t) nil))
However, that part which actually checked for that text property in
`compilation-parse-errors' somehow vanished in one of the later
refactorings, so that does not work anymore.
I see the following ways to solve this:
- Following RMS initial idea, use a text property to mark text which
should not be parsed for errors.
- Use buffer-local-variables to remember where the actual
compilation/grep output starts and ends, and use that as an
lower/upper bound when calling `compilation--parse-region' in
`compilation--ensure-parse'.
Whatever we do to fix it, I'm leaning towards doing this in trunk. The
code in compile.el is quite intricate, and it's easy to make
mistakes. Also, this was apparently broken for years...
-David
next prev parent reply other threads:[~2014-09-20 9:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 12:24 bug#18444: 24.3.93; Error running timer 'compilation-auto-jump' from grep-mode Martin Apel
2014-09-10 19:09 ` Glenn Morris
2014-09-11 7:06 ` Martin Apel
2014-09-11 15:59 ` Glenn Morris
2014-09-11 23:29 ` Glenn Morris
2014-09-11 23:41 ` Glenn Morris
2014-09-12 6:49 ` Martin Apel
2014-09-20 9:10 ` David Engster [this message]
2014-09-20 20:41 ` Stefan Monnier
2014-09-20 21:40 ` Glenn Morris
2022-02-10 8:19 ` Lars Ingebrigtsen
2022-02-10 8:27 ` APEL Martin via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-10 8:29 ` Lars Ingebrigtsen
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fvfmverc.fsf@engster.org \
--to=deng@randomsample.de \
--cc=18444@debbugs.gnu.org \
--cc=martin.apel@simpack.de \
--cc=rgm@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.