Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pretty print the buffer when opening long single line JSON file #48

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

taku0
Copy link
Contributor

@taku0 taku0 commented Jun 12, 2023

When opening long single line JSON file, ask the user if they want to pretty print the buffer. This makes opening and editing the file faster since, as you know, Emacs cannot handle long line well.

Opening 30 MiB file (made with jq -c . test-assets/large-json-file.json) took 4 seconds with pretty printing rather than 13 seconds without pretty printing. Our implementation is faster than json-pretty-print-buffer, which took 10 seconds.

Why we are faster than json-pretty-print-buffer:

json-pretty-print-buffer is generic while our jsonian--pretty-print-long-line assumes the buffer is single line. json-pretty-print-buffer parse the buffer, pretty print it in a temporary buffer, and replace the buffer content with replace-region-contents. It keeps existing markers and properties intact but slow. We alternatively scan the buffer and insert line breaks and indentations. We also utilize jsonian--huge-edit to optimizes the undo list; Emacs normally records one undo entry for each basic modifications such as inserting a line break or indenting a line. When applying json-pretty-print-buffer to a large file, this floods the undo list and it will be truncated by Emacs. Even without truncation, it makes undo slower. jsonian--huge-edit creates a few undo entries that delete whole region and replace it with a new content. It also takes care of existing markers.

This is ported from my JSON Par mode.

@iwahbe iwahbe self-requested a review June 13, 2023 11:50
@iwahbe
Copy link
Owner

iwahbe commented Jun 15, 2023

Hey @taku0, I appreciate the PR. My plan is to review this PR after #47. Moving away from long lines makes sense given how badly emacs handles them.

@taku0
Copy link
Contributor Author

taku0 commented Jun 17, 2023

Tweaked a bit.

@iwahbe iwahbe mentioned this pull request Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants