help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: BUG 20703 further evidence


From: Sam Halliday
Subject: Re: BUG 20703 further evidence
Date: Wed, 13 Jan 2016 13:36:21 -0800 (PST)
User-agent: G2/1.0

Thanks Dmitry,

For Emacs 25 we have the option to be smarter, but since I'm on Emacs 24 I am 
currently in the market for an evil hack :-) (although, copying the emacs-25 
faster implementation might not be a bad idea as well, this is a particularly 
slow part of using Emacs).

The approach that sounds most sensible for my use case sounds like just 
excluding that one file from indexing, because I can do that from my .ctags. I 
actually hadn't thought of it until you mentioned it! I was thinking along the 
lines of a function that deletes all the long lines from a TAGS file, part of a 
validation / cleanup phase. If you have a recipe in mind for that, it would be 
pretty useful.

Could you please copy out your proposed changes in full? I won't be applying 
them against their sources, I'll just put them in my scratch and execute in the 
running instance.

Best regards,
Sam


On Wednesday, 13 January 2016 21:25:43 UTC, Dmitry Gutov  wrote:
> 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
> >
> >    https://debbugs.gnu.org/db/20/20703.html
> >
> > 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 limits.
> 
> 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
>         str
>       (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
>       (progress-reporter
>        (make-progress-reporter
> @@ -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))))
>       table))
> 
>   (defun etags-snarf-tag (&optional use-explicit) ; Doc string?



reply via email to

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