[Top][All Lists]

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

Re: BUG 20703 further evidence

From: Dmitry Gutov
Subject: Re: BUG 20703 further evidence
Date: Thu, 14 Jan 2016 00:25:32 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0

Hi Sam,

On 01/13/2016 08:54 PM, Sam Halliday wrote:

I have been seeing a problem that is described in this bug report

I have applied the suggested patch to etags-tags-completion-table (copied below 
in completeness for your convenience) and trapped an error case.

You should try the current version in emacs-25, it's smaller and faster than previously, although it also probably fails at long-enough lines.

I'm triggering the error in an extremely long line of code (46,000 characters!). I 
presume somebody programmatically generated the line and pasted it into the source. A 
workaround could be to simply filter such lines at the ctag building or loading stage, 
just something that deletes "long" lines, whatever that may mean. Probably 500 
characters is long enough!

I could also look at adding maximum sizes to my regexes in ctags, but that 
really isn't a general solution because many ctags patterns do not have such 

I can think of some other possible solutions:

- External pre-processor that removes lines that are too long.

- Extra step, together with a custom variable, in visit-tags-table, that goes through the opened files and does the same.

- re-search-forward with limit, as implemented in the patch below (against emacs-25), that might work against problematic files like that (I haven't tested it).

I don't really know if we should install it, though, because it adds a performance overhead of ~10%. And I don't know if this problem is common enough.

Because another way to combat it is at the source: through judicious application of --exclude argument. As a bonus, the generation phase will become faster as well (sometimes dramatically).

Should we add a validation phase to visit-tags-table instead? Like, one that would say "your TAGS files contains obviously malformed entries from file XXX.min.js, go back and ignore it"?

diff --git a/lisp/progmodes/etags.el b/lisp/progmodes/etags.el
index 2db7220..9a663d4 100644
--- a/lisp/progmodes/etags.el
+++ b/lisp/progmodes/etags.el
@@ -1252,8 +1252,9 @@ etags-file-of-tag
        (expand-file-name str (file-truename default-directory))))))

+(defvar etags--table-line-limit 500)

-(defun etags-tags-completion-table () ; Doc string?
+(defun etags-tags-completion-table ()   ; Doc string?
   (let (table
@@ -1263,10 +1264,13 @@ etags-tags-completion-table
       (goto-char (point-min))
       ;; This regexp matches an explicit tag name or the place where
       ;; it would start.
-      (while (re-search-forward
-              "[\f\t\n\r()=,; ]?\177\\\(?:\\([^\n\001]+\\)\001\\)?"
-             nil t)
-       (push   (prog1 (if (match-beginning 1)
+      (while (not (eobp))
+        (if (not (re-search-forward
+                  "[\f\t\n\r()=,; ]?\177\\\(?:\\([^\n\001]+\\)\001\\)?"
+                  ;; Avoid lines that are too long (bug#20703).
+                  (+ (point) etags--table-line-limit) t))
+            (forward-line 1)
+          (push (prog1 (if (match-beginning 1)
                           ;; There is an explicit tag name.
                           (buffer-substring (match-beginning 1) (match-end 1))
                         ;; No explicit tag name.  Backtrack a little,
@@ -1277,7 +1281,7 @@ etags-tags-completion-table
(buffer-substring (point) (match-beginning 0))
                            (goto-char (match-end 0))))
                  (progress-reporter-update progress-reporter (point)))
-               table)))
+               table))))

 (defun etags-snarf-tag (&optional use-explicit) ; Doc string?

reply via email to

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