GNU bug report logs -
#58979
treesitter-regression with json-mode
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58979 in the body.
You can then email your comments to 58979 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58979
; Package
emacs
.
(Thu, 03 Nov 2022 06:48:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Johann Höchtl <johann.hoechtl <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 03 Nov 2022 06:48:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
When I open a large json file (about 3_000_000 lines, about 72Mb,
pretty-printed) Emacs 29.0.50 opens the file just fine in `js-json-mode`
and when using regexp-based font locking, it works well.
When I force this buffer into javascript-mode, Emacs hangs. Memory
consumption as reported by Windows task manager "dances" around 2Gb, yet
even after waiting for three minutes, Emacs doesn't get responsive any more.
I consider this an unfortunately regression as recent commits to Emacs 29
(long lines patches) actually makes working with such large files with long
lines absolutely pleasant, yet as it seems the interaction with tree-sitter
destroys this gains.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58979
; Package
emacs
.
(Sat, 12 Nov 2022 20:35:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 58979 <at> debbugs.gnu.org (full text, mbox):
Johann Höchtl <johann.hoechtl <at> gmail.com> writes:
> When I open a large json file (about 3_000_000 lines, about 72Mb,
> pretty-printed) Emacs 29.0.50 opens the file just fine in
> `js-json-mode` and when using regexp-based font locking, it works
> well.
>
> When I force this buffer into javascript-mode, Emacs hangs. Memory
> consumption as reported by Windows task manager "dances" around 2Gb,
> yet even after waiting for three minutes, Emacs doesn't get responsive
> any more.
>
> I consider this an unfortunately regression as recent commits to Emacs
> 29 (long lines patches) actually makes working with such large files
> with long lines absolutely pleasant, yet as it seems the interaction
> with tree-sitter destroys this gains.
Copying in Yuan Fu.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#58979
; Package
emacs
.
(Tue, 22 Nov 2022 07:45:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 58979 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Johann Höchtl <johann.hoechtl <at> gmail.com> writes:
>
>> When I open a large json file (about 3_000_000 lines, about 72Mb,
>> pretty-printed) Emacs 29.0.50 opens the file just fine in
>> `js-json-mode` and when using regexp-based font locking, it works
>> well.
>>
>> When I force this buffer into javascript-mode, Emacs hangs. Memory
>> consumption as reported by Windows task manager "dances" around 2Gb,
>> yet even after waiting for three minutes, Emacs doesn't get responsive
>> any more.
>>
>> I consider this an unfortunately regression as recent commits to Emacs
>> 29 (long lines patches) actually makes working with such large files
>> with long lines absolutely pleasant, yet as it seems the interaction
>> with tree-sitter destroys this gains.
>
> Copying in Yuan Fu.
Again, sorry for the delay, I just saw this report :-)
Since your previous report is actually about emacs-tree-sitter, I think
this one is too?
Anyway, since tree-sitter is merged into master now, if you rebuild
master and turn on json-ts-mode, you should be in tree-sitter backed
JSON mode. I’d give that a try and see if works fine.
Thanks,
Yuan
Added tag(s) moreinfo.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Thu, 24 Nov 2022 19:42:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Yuan Fu <casouri <at> gmail.com>
:
You have taken responsibility.
(Sat, 07 Jan 2023 23:11:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Johann Höchtl <johann.hoechtl <at> gmail.com>
:
bug acknowledged by developer.
(Sat, 07 Jan 2023 23:11:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 58979-done <at> debbugs.gnu.org (full text, mbox):
Yuan Fu <casouri <at> gmail.com> writes:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Johann Höchtl <johann.hoechtl <at> gmail.com> writes:
>>
>>> When I open a large json file (about 3_000_000 lines, about 72Mb,
>>> pretty-printed) Emacs 29.0.50 opens the file just fine in
>>> `js-json-mode` and when using regexp-based font locking, it works
>>> well.
>>>
>>> When I force this buffer into javascript-mode, Emacs hangs. Memory
>>> consumption as reported by Windows task manager "dances" around 2Gb,
>>> yet even after waiting for three minutes, Emacs doesn't get responsive
>>> any more.
>>>
>>> I consider this an unfortunately regression as recent commits to Emacs
>>> 29 (long lines patches) actually makes working with such large files
>>> with long lines absolutely pleasant, yet as it seems the interaction
>>> with tree-sitter destroys this gains.
>>
>> Copying in Yuan Fu.
>
> Again, sorry for the delay, I just saw this report :-)
>
> Since your previous report is actually about emacs-tree-sitter, I think
> this one is too?
>
> Anyway, since tree-sitter is merged into master now, if you rebuild
> master and turn on json-ts-mode, you should be in tree-sitter backed
> JSON mode. I’d give that a try and see if works fine.
>
> Thanks,
> Yuan
Closing this report since I think there’s nothing to do. Feel free to
reopen.
Yuan
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 05 Feb 2023 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.