* bug#13369: 24.1; compile message parsing slow because of omake hack
@ 2013-01-06 20:03 Mattias Engdegård
2013-01-07 1:24 ` Glenn Morris
0 siblings, 1 reply; 16+ messages in thread
From: Mattias Engdegård @ 2013-01-06 20:03 UTC (permalink / raw)
To: 13369
Parsing compilation messages in compilation-mode can be very slow for
large buffers (thousands of error lines); it can take many
seconds. Experiments show that it is the presence of omake in
compilation-error-regexp-alist that causes most of the trouble; removing
it mostly cures the problem.
The omake regexp does not look too troublesome, but there are some
omake-specific hacks in compile.el that are more worrying. In
particular, this code (in compilation-parse-errors) looks suspicious:
(cond
((not (memq 'omake compilation-error-regexp-alist)) nil)
((string-match "\\`\\([^^]\\|^\\( \\*\\|\\[\\)\\)" pat)
nil) ;; Not anchored or anchored but already allows empty
spaces.
(t (setq pat (concat "^ *" (substring pat 1)))))
The slightly alarming concept of regexp-matching a regexp aside, this
one doesn't make sense - shouldn't the ^ (following the \|) be escaped?
Apparently the code was at some time changed from
(when (and (= ?^ (aref pat 0)) ; anchored: starts with "^"
;; but does not allow an arbitrary number of leading
spaces
(not (and (= ? (aref pat 1)) (= ?* (aref pat 2)))))
which looks more correct, and conveys the intent somewhat better
(and may be more efficient than the regexp for all I know).
It's not clear to me how the present code could ever have worked.
At the very least the regexp in compilation-parse-errors should
be fixed.
In GNU Emacs 24.1.1 (powerpc-apple-darwin, NS apple-appkit-1038.36)
of 2012-06-10 on bob.porkrind.org
Windowing system distributor `Apple', version 10.3.949
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-06 20:03 bug#13369: 24.1; compile message parsing slow because of omake hack Mattias Engdegård
@ 2013-01-07 1:24 ` Glenn Morris
2013-01-07 1:41 ` Mattias Engdegård
0 siblings, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2013-01-07 1:24 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13369
Mattias Engdegård wrote:
> Parsing compilation messages in compilation-mode can be very slow for
> large buffers (thousands of error lines); it can take many
> seconds. Experiments show that it is the presence of omake in
> compilation-error-regexp-alist that causes most of the trouble; removing
> it mostly cures the problem.
[...]
> one doesn't make sense - shouldn't the ^ (following the \|) be escaped?
Yes, I think so.
Does making that change remove the slowdown that you see?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-07 1:24 ` Glenn Morris
@ 2013-01-07 1:41 ` Mattias Engdegård
2013-01-07 8:14 ` Glenn Morris
0 siblings, 1 reply; 16+ messages in thread
From: Mattias Engdegård @ 2013-01-07 1:41 UTC (permalink / raw)
To: Glenn Morris; +Cc: 13369
7 jan 2013 kl. 02.24 skrev Glenn Morris:
> Does making that change remove the slowdown that you see?
Substantially, but not entirely. (I can try measuring it exactly if
you want it quantified, but it goes from being unusable to merely
annoyingly sluggish.)
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-07 1:41 ` Mattias Engdegård
@ 2013-01-07 8:14 ` Glenn Morris
2013-01-07 21:50 ` Mattias Engdegård
0 siblings, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2013-01-07 8:14 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13369
Mattias Engdegård wrote:
> Substantially, but not entirely. (I can try measuring it exactly if
> you want it quantified, but it goes from being unusable to merely
> annoyingly sluggish.)
It might be useful to have some numbers, yes.
Could you compare the time with the \\^ change to the time with the
omake part of compilation-parse-errors commented out entirely?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-07 8:14 ` Glenn Morris
@ 2013-01-07 21:50 ` Mattias Engdegård
2013-01-08 20:14 ` Glenn Morris
0 siblings, 1 reply; 16+ messages in thread
From: Mattias Engdegård @ 2013-01-07 21:50 UTC (permalink / raw)
To: Glenn Morris; +Cc: 13369
7 jan 2013 kl. 09.14 skrev Glenn Morris:
> Could you compare the time with the \\^ change to the time with the
> omake part of compilation-parse-errors commented out entirely?
Here are the times, in seconds, for executing compilation-parse-errors
far down a large compile buffer (5000 lines, or about 440 KiB),
with and without omake present in compilation-error-regexp-alist:
omake
present absent
30.3 3.2 Standard code
6.5 3.2 repaired regexp (escaped ^)
3.2 3.2 COND expression removed
In the last case, the entire COND surrounding the faulty regexp was
edited out.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-07 21:50 ` Mattias Engdegård
@ 2013-01-08 20:14 ` Glenn Morris
2013-01-08 21:09 ` Mattias Engdegård
0 siblings, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2013-01-08 20:14 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13369
Mattias Engdegård wrote:
> Here are the times, in seconds, for executing compilation-parse-errors
> far down a large compile buffer (5000 lines, or about 440 KiB),
> with and without omake present in compilation-error-regexp-alist:
>
> omake
> present absent
> 30.3 3.2 Standard code
> 6.5 3.2 repaired regexp (escaped ^)
> 3.2 3.2 COND expression removed
Thanks. Could you also give the numbers for
compilation-error-regexp-alist containing only `gnu' (assuming that is
the one that is relevant for your test case)?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-08 20:14 ` Glenn Morris
@ 2013-01-08 21:09 ` Mattias Engdegård
2013-01-08 22:40 ` Glenn Morris
0 siblings, 1 reply; 16+ messages in thread
From: Mattias Engdegård @ 2013-01-08 21:09 UTC (permalink / raw)
To: Glenn Morris; +Cc: 13369
8 jan 2013 kl. 21.14 skrev Glenn Morris:
> Thanks. Could you also give the numbers for
> compilation-error-regexp-alist containing only `gnu' (assuming that is
> the one that is relevant for your test case)?
These times are with a slightly different compilation buffer:
all no omake gnu only
32.7 3.4 0.3 standard code
6.8 3.4 0.3 repaired regexp (escaped ^)
3.4 3.4 0.3 COND expression removed
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-08 21:09 ` Mattias Engdegård
@ 2013-01-08 22:40 ` Glenn Morris
2013-01-09 1:47 ` Stefan Monnier
0 siblings, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2013-01-08 22:40 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13369
Mattias Engdegård wrote:
> 8 jan 2013 kl. 21.14 skrev Glenn Morris:
>
>> Thanks. Could you also give the numbers for
>> compilation-error-regexp-alist containing only `gnu' (assuming that is
>> the one that is relevant for your test case)?
>
> These times are with a slightly different compilation buffer:
>
> all no omake gnu only
> 32.7 3.4 0.3 standard code
> 6.8 3.4 0.3 repaired regexp (escaped ^)
> 3.4 3.4 0.3 COND expression removed
OK, thank you. So having fixed the omake ^ issue, basically to me it
just seems to be the case that the more entries are in
compilation-error-regexp-alist, the slower things get.
Maybe we should encourage people to prune it to only the entries they
use, or maybe some less common elements should not be there by default.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-08 22:40 ` Glenn Morris
@ 2013-01-09 1:47 ` Stefan Monnier
2013-01-09 11:11 ` Mattias Engdegård
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2013-01-09 1:47 UTC (permalink / raw)
To: Glenn Morris; +Cc: Mattias Engdegård, 13369
>>> Thanks. Could you also give the numbers for
>>> compilation-error-regexp-alist containing only `gnu' (assuming that is
>>> the one that is relevant for your test case)?
>> These times are with a slightly different compilation buffer:
>> all no omake gnu only
>> 32.7 3.4 0.3 standard code
>> 6.8 3.4 0.3 repaired regexp (escaped ^)
>> 3.4 3.4 0.3 COND expression removed
> OK, thank you. So having fixed the omake ^ issue, basically to me it
> just seems to be the case that the more entries are in
> compilation-error-regexp-alist, the slower things get.
> Maybe we should encourage people to prune it to only the entries they
> use, or maybe some less common elements should not be there by default.
Yes, every entry costs time, which is why I've been resisting adding
more entries and would rather push the problem upstream to convince the
tools's authors to stick to the standard GNU message format.
I think compile.el would benefit from a different regex engine where we
could do a lex-style union of all regexp into a single automaton.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-09 1:47 ` Stefan Monnier
@ 2013-01-09 11:11 ` Mattias Engdegård
2013-01-09 13:42 ` Jambunathan K
2013-01-09 20:20 ` Stefan Monnier
0 siblings, 2 replies; 16+ messages in thread
From: Mattias Engdegård @ 2013-01-09 11:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 13369
9 jan 2013 kl. 02.47 skrev Stefan Monnier:
>>> all no omake gnu only
>>> 32.7 3.4 0.3 standard code
>>> 6.8 3.4 0.3 repaired regexp (escaped ^)
>>> 3.4 3.4 0.3 COND expression removed
>> OK, thank you. So having fixed the omake ^ issue, basically to me it
>> just seems to be the case that the more entries are in
>> compilation-error-regexp-alist, the slower things get.
>> Maybe we should encourage people to prune it to only the entries they
>> use, or maybe some less common elements should not be there by
>> default.
>
> Yes, every entry costs time, which is why I've been resisting adding
> more entries and would rather push the problem upstream to convince
> the
> tools's authors to stick to the standard GNU message format.
Note however that the omake is still special - while its own regexp is
fast and simple, its mere presence in the list causes the remaining
parsing to become twice as slow (as seen from the measurements above).
I'm also still somewhat suspicious of how the hack mutilates other
regexps in ways that may change their meaning.
In addition to fixing the regexp, I suggest omake be disabled by
default because of its impact and since it's somewhat of a special need.
> I think compile.el would benefit from a different regex engine where
> we
> could do a lex-style union of all regexp into a single automaton.
That would be nice, especially if the result could be a DFA.
I would also suggest switching to rx notation for the regexps.
(The ^ quoting bug is one that would never have occurred with rx,
and that is a very small regexp.)
I actually wrote a simple regexp-to-rx translator, like rx in reverse,
just to be able to make sense of the ones in compile.el. I'd be happy
to share.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-09 11:11 ` Mattias Engdegård
@ 2013-01-09 13:42 ` Jambunathan K
2013-01-09 14:31 ` Mattias Engdegård
2013-01-09 20:20 ` Stefan Monnier
1 sibling, 1 reply; 16+ messages in thread
From: Jambunathan K @ 2013-01-09 13:42 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13369
Mattias Engdegård <mattiase@bredband.net> writes:
> I actually wrote a simple regexp-to-rx translator, like rx in reverse,
> just to be able to make sense of the ones in compile.el. I'd be happy
> to share.
Why not just share, instead of saying that you will be happy to do so.
I personally find rx easy to edit and use. I am also drifting away from
Emacs lisp regexp to rx.
ps: Someone shared a perl(?)-to-Emacs regexes a couple of months ago and
wanted to include it as part of GNU ELPA.
--
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-09 13:42 ` Jambunathan K
@ 2013-01-09 14:31 ` Mattias Engdegård
2013-01-09 15:17 ` Jambunathan K
0 siblings, 1 reply; 16+ messages in thread
From: Mattias Engdegård @ 2013-01-09 14:31 UTC (permalink / raw)
To: Jambunathan K; +Cc: 13369
[-- Attachment #1: Type: text/plain, Size: 211 bytes --]
> Why not just share, instead of saying that you will be happy to do so.
Sorry, I just assumed that someone already wrote such a thing and that
it would be more polished than my amateurish attempt. Here it is.
[-- Attachment #2: xr.el --]
[-- Type: application/octet-stream, Size: 12212 bytes --]
;; xr - convert string regexp to rx notation
(require 'rx)
(defun xr-parse-char-alt ()
(let ((set nil))
(when (looking-at "]")
(forward-char 1)
(setq set (list "]")))
(while (not (looking-at "]"))
(cond
;; character class
((looking-at (rx "[:" (group (one-or-more letter)) ":]"))
(let* ((sym (intern (match-string 1)))
(rx-sym (cond ((eq sym 'unibyte) 'ascii)
((eq sym 'multibyte) 'nonascii)
(t sym))))
(setq set (cons sym set))
(goto-char (match-end 0))))
;; character range
((looking-at (rx (not (any "]")) "-" (not (any "]"))))
(let ((range (match-string 0)))
;; We render [0-9] as (any "0-9") instead of (any (?0 . ?9))
;; for readability and brevity, and because the latter would
;; become (48 . 57) when printed.
(setq set (cons range set))
(goto-char (match-end 0))))
((looking-at (rx eos))
(error "unterminated character alternative"))
;; plain character (including ^ or -)
(t
(setq set (cons (char-to-string (following-char)) set))
(forward-char 1))))
;; FIXME: combine several characters into one string (if there is no "-"),
;; like (any "a" "b") -> (any "ab")
set))
;; Reverse a sequence and concatenate adjacent strings.
(defun xr-rev-join-seq (rev-seq)
(let ((seq nil))
(while rev-seq
(if (and (stringp (car rev-seq)) (stringp (car seq)))
(setq seq (cons (concat (car rev-seq) (car seq)) (cdr seq)))
(setq seq (cons (car rev-seq) seq)))
(setq rev-seq (cdr rev-seq)))
seq))
(defun xr-parse-seq ()
(let ((sequence nil)) ; reversed
(while (not (looking-at (rx (or "\\|" "\\)" eos))))
(cond
;; nonspecial character
((looking-at (rx (not (any "\\*+?.^$["))))
(forward-char 1)
(setq sequence (cons (match-string 0) sequence)))
;; escaped special
((looking-at (rx "\\" (group (any "\\*+?.^$["))))
(forward-char 2)
(setq sequence (cons (match-string 1) sequence)))
;; group
((looking-at (rx "\\("
(opt (group "?" (group (zero-or-more digit)) ":"))))
(let ((question (match-string 1))
(number (match-string 2))
(end (match-end 0)))
(goto-char end)
(let* ((group (xr-parse-alt))
;; optimise - group has an implicit seq
(operand (if (and (listp group) (eq (car group) 'seq))
(cdr group)
(list group))))
(when (not (looking-at (rx "\\)")))
(error "missing \\)"))
(forward-char 2)
(let ((item (cond ((not question) ; plain subgroup
(cons 'group operand))
((zerop (length number)) ; shy group
group)
(t
(append (list 'group-n (string-to-number number))
operand)))))
(setq sequence (cons item sequence))))))
;; * ? + (and non-greedy variants)
((looking-at (rx (group (any "*?+")) (opt (group "?"))))
(let ((op (match-string 1))
(non-greedy (match-string 2)))
(goto-char (match-end 0))
(when (null sequence)
(error "postfix operator without operand"))
;; While we could use the same symbols as the operator in the regexp,
;; ? needs to be escaped in symbols and isn't very neat, so we
;; assume that rx-greedy-flag is set.
(let* ((sym (cdr (assoc op '(("*" . zero-or-more)
("+" . one-or-more)
("?" . opt)))))
(operand (car sequence))
;; Optimise when the operand is (seq ...)
(item
(if (and (listp operand) (eq (car operand) 'seq))
(cons sym (cdr operand))
(list sym operand))))
;; BUG: minimal-match affects everything inside, which is not
;; what we want. Either keep track of the stuff inside and insert
;; maximal-match as appropriate (messy!) or just use the
;; *?, ?? and +? symbols.
(setq sequence (cons (if non-greedy (list 'minimal-match item) item)
(cdr sequence))))))
;; \{..\}
((looking-at (rx "\\{" (or (group (one-or-more digit))
(seq
(opt (group (one-or-more digit)))
","
(opt (group (one-or-more digit)))))
"\\}"))
(when (null sequence)
(error "repetition without operand"))
(let ((exactly (match-string 1))
(lower (match-string 2))
(upper (match-string 3)))
(goto-char (match-end 0))
(let ((op (cond (exactly
(list '= (string-to-number exactly)))
((and lower upper)
(list 'repeat
(string-to-number lower)
(string-to-number upper)))
(lower
(list '>= (string-to-number lower)))
(upper
(list 'repeat 0 (string-to-number upper)))
(t
(list 'zero-or-more)))))
(setq sequence (cons (append op (list (car sequence)))
(cdr sequence))))))
;; character alternative
((looking-at (rx "[" (opt (group "^"))))
(goto-char (match-end 0))
;; FIXME: optimise (any digit) -> digit etc
(let* ((negated (match-string 1))
(set (cons 'any (xr-parse-char-alt))))
(forward-char 1)
(setq sequence (cons (if negated (list 'not set) set) sequence))))
;; backref
((looking-at (rx "\\" (group digit)))
(forward-char 2)
(setq sequence
(cons (list 'backref (string-to-number (match-string 1)))
sequence)))
;; various simple substitutions
((looking-at (rx (or "." "$" "^" "\\w" "\\W" "\\`" "\\'" "\\="
"\\b" "\\B" "\\<" "\\>" "\\_<" "\\_>")))
(goto-char (match-end 0))
(let ((sym (cdr (assoc
(match-string 0)
'(("." . nonl)
("^" . bol) ("$" . eol)
("\\w" . wordchar) ("\\W" . not-wordchar)
("\\`" . bos) ("\\'" . eos)
("\\=" . point)
("\\b" . word-boundary) ("\\B" . not-word-boundary)
("\\<" . bow) ("\\>" . eow)
("\\_<" . symbol-start) ("\\_>" . symbol-end))))))
(setq sequence (cons sym sequence))))
;; character syntax
((looking-at (rx "\\" (group (any "sS")) (group anything)))
(let ((negated (string-equal (match-string 1) "S"))
(syntax-code (match-string 2)))
(goto-char (match-end 0))
(let ((sym (assoc syntax-code
'(("-" . whitespace)
("." . punctuation)
("w" . word)
("_" . symbol)
("(" . open-parenthesis)
(")" . close-parenthesis)
("'" . expression-prefix)
("\"" . string-quote)
("$" . paired-delimiter)
("\\" . escape)
("/" . character-quote)
("<" . comment-start)
(">" . comment-end)
("|" . string-delimiter)
("!" . comment-delimiter)))))
(when (not sym)
(error "unknown syntax code: %s" syntax-code))
(let ((item (list 'syntax (cdr sym))))
(setq sequence (cons (if negated (list 'not item) item)
sequence))))))
;; character categories
((looking-at (rx "\\" (group (any "cC")) (group anything)))
(let ((negated (string-equal (match-string 1) "C"))
(category-code (match-string 2)))
(goto-char (match-end 0))
(let ((sym (assoc category-code
'(("0" . consonant)
("1" . base-vowel)
("2" . upper-diacritical-mark)
("3" . lower-diacritical-mark)
("4" . tone-mark)
("5" . symbol)
("6" . digit)
("7" . vowel-modifying-diacritical-mark)
("8" . vowel-sign)
("9" . semivowel-lower)
("<" . not-at-end-of-line)
(">" . not-at-beginning-of-line)
("A" . alpha-numeric-two-byte)
("C" . chinse-two-byte)
("G" . greek-two-byte)
("H" . japanese-hiragana-two-byte)
("I" . indian-tow-byte)
("K" . japanese-katakana-two-byte)
("N" . korean-hangul-two-byte)
("Y" . cyrillic-two-byte)
("^" . combining-diacritic)
("a" . ascii)
("b" . arabic)
("c" . chinese)
("e" . ethiopic)
("g" . greek)
("h" . korean)
("i" . indian)
("j" . japanese)
("k" . japanese-katakana)
("l" . latin)
("o" . lao)
("q" . tibetan)
("r" . japanese-roman)
("t" . thai)
("v" . vietnamese)
("w" . hebrew)
("y" . cyrillic)
("|" . can-break)))))
(when (not sym)
(error "unknown category code: %s" category-code))
(let ((item (list 'category (cdr sym))))
(setq sequence (cons (if negated (list 'not item) item)
sequence))))))
;; error
(t
(let* ((start (point))
(end (min (+ start 3) (point-max))))
(error "syntax error: %s" (buffer-substring start end))))))
(let ((item-seq (xr-rev-join-seq sequence)))
(if (> (length item-seq) 1)
(cons 'seq item-seq)
(car item-seq)))))
(defun xr-parse-alt ()
(let ((alternatives nil)) ; reversed
(while (not (looking-at (rx (or "\\)" eos))))
(setq alternatives (cons (xr-parse-seq) alternatives))
(when (looking-at (rx "\\|"))
(forward-char 2)))
(if (> (length alternatives) 1)
(cons 'or (reverse alternatives))
(car alternatives))))
(defun xr (re-string)
"Convert a regexp string to rx notation."
(with-temp-buffer
(insert re-string)
(goto-char (point-min))
(let ((rx (xr-parse-alt)))
(when (looking-at (rx "\\)"))
(error "unbalanced \\)"))
rx)))
[-- Attachment #3: Type: text/plain, Size: 1 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-09 14:31 ` Mattias Engdegård
@ 2013-01-09 15:17 ` Jambunathan K
2013-01-10 18:55 ` Mattias Engdegård
0 siblings, 1 reply; 16+ messages in thread
From: Jambunathan K @ 2013-01-09 15:17 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13369
Mattias Engdegård <mattiase@bredband.net> writes:
Thanks, that was quick. May be you want to indicate whether you want to
assign the copyright to that code FSF so that it could be improved upon
by others and distributed with Emacs or GNU ELPA.
>> Why not just share, instead of saying that you will be happy to do so.
>
> Sorry, I just assumed that someone already wrote such a thing
[OT, The following comment concerns re-builder]
In re-builder, there is a way to convert between various regexp styles.
It is bound to C-c TAB by default. It is not clear to me, whether
re-builder supports rx-to-regexp conversions.
When I try converting the following regexp (C-h v org-heading-regexp) in
read format to rx format
"^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
I am seeing that the re-builder translates that to
,----
| '()
`----
with the following message
,----
| rx-form: Unknown rx form `nil'
`----
I am not sure whether that counts as bug. It is possible that
re-builder doesn't support such translation or that I am using the
interface wrongly.
While,
(xr "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"))
gives me
(seq bol
(group
(one-or-more "*"))
(opt
(one-or-more " ")
(group
(minimal-match
(zero-or-more nonl))))
(zero-or-more
(any " " " "))
eol)
> and that it would be more polished than my amateurish attempt. Here it
> is.
I will let others review the changes.
Some libraries like org.el use complex regexps. For someone who wants
to dig deep in to what the regexps amount to, without resorting to
pen-and-paper, one can imagine a utility which overlays or tooltips a
regexp like string with it's rx counterpart. It could be quite useful.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-09 15:17 ` Jambunathan K
@ 2013-01-10 18:55 ` Mattias Engdegård
2013-01-10 19:34 ` Stefan Monnier
0 siblings, 1 reply; 16+ messages in thread
From: Mattias Engdegård @ 2013-01-10 18:55 UTC (permalink / raw)
To: Jambunathan K; +Cc: 13369
9 jan 2013 kl. 16.17 skrev Jambunathan K:
> Thanks, that was quick. May be you want to indicate whether you
> want to
> assign the copyright to that code FSF so that it could be improved
> upon
> by others and distributed with Emacs or GNU ELPA.
Thank you, but I doubt I could get my employer to sign any copyright
papers, which to the best of my understanding is required for
distribution with Emacs. Please correct me if I'm wrong.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-10 18:55 ` Mattias Engdegård
@ 2013-01-10 19:34 ` Stefan Monnier
0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2013-01-10 19:34 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13369, Jambunathan K
>> Thanks, that was quick. May be you want to indicate whether you want to
>> assign the copyright to that code FSF so that it could be improved upon
>> by others and distributed with Emacs or GNU ELPA.
> Thank you, but I doubt I could get my employer to sign any copyright
> papers, which to the best of my understanding is required for
> distribution with Emacs. Please correct me if I'm wrong.
Indeed, it's needed, but only very few employers really refuse to sign
the relevant paperwork (which is a disclaimer that they have no
copyright interest in your work on Emacs).
Many employers will need some convincing (and reminding), but if I were
you I wouldn't give up just on the assumption that it can't be done,
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#13369: 24.1; compile message parsing slow because of omake hack
2013-01-09 11:11 ` Mattias Engdegård
2013-01-09 13:42 ` Jambunathan K
@ 2013-01-09 20:20 ` Stefan Monnier
1 sibling, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2013-01-09 20:20 UTC (permalink / raw)
To: Mattias Engdegård; +Cc: 13369
> I actually wrote a simple regexp-to-rx translator, like rx in reverse,
> just to be able to make sense of the ones in compile.el. I'd be happy
> to share.
Reminds me of my old lex.el, so I've just added it to GNU ELPA.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-01-10 19:34 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-06 20:03 bug#13369: 24.1; compile message parsing slow because of omake hack Mattias Engdegård
2013-01-07 1:24 ` Glenn Morris
2013-01-07 1:41 ` Mattias Engdegård
2013-01-07 8:14 ` Glenn Morris
2013-01-07 21:50 ` Mattias Engdegård
2013-01-08 20:14 ` Glenn Morris
2013-01-08 21:09 ` Mattias Engdegård
2013-01-08 22:40 ` Glenn Morris
2013-01-09 1:47 ` Stefan Monnier
2013-01-09 11:11 ` Mattias Engdegård
2013-01-09 13:42 ` Jambunathan K
2013-01-09 14:31 ` Mattias Engdegård
2013-01-09 15:17 ` Jambunathan K
2013-01-10 18:55 ` Mattias Engdegård
2013-01-10 19:34 ` Stefan Monnier
2013-01-09 20:20 ` Stefan Monnier
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.