[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#20703: BUG 20703 further evidence
From: |
Lars Ingebrigtsen |
Subject: |
Re: bug#20703: BUG 20703 further evidence |
Date: |
Tue, 25 Aug 2020 11:13:08 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Dmitry Gutov <dgutov@yandex.ru> writes:
>> I'm triggering the error in an extremely long line of code (46,000
>> characters!).
[...]
> - 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.
I think this is a use case (46K long lines) that's really obscure, and a
10% performance it wouldn't be appropriate.
> 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"?
If that can be done efficiently, then that sounds like a good idea.
Otherwise, perhaps we should just say that etags just doesn't support
46K long line source files and close this report as a wontfix?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: bug#20703: BUG 20703 further evidence,
Lars Ingebrigtsen <=