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

Slow performance when editing initial git commit message #1836

Closed
slinlee opened this issue Mar 18, 2022 · 1 comment · Fixed by #1838
Closed

Slow performance when editing initial git commit message #1836

slinlee opened this issue Mar 18, 2022 · 1 comment · Fixed by #1838
Assignees
Labels
A-tree-sitter Area: Tree-sitter C-bug Category: This is a bug

Comments

@slinlee
Copy link
Contributor

slinlee commented Mar 18, 2022

Summary

I have noticed that when I create a new git project, editing the message for the first commit in helix is extremely slow. It locks for seconds at a time between keystrokes before anything appears on screen.

Reproduction Steps

I tried this:

Create a project

  1. mkdir hardhat
  2. cd hardhat
  3. npm init --yes
  4. npm install --save=dev hardhat
  5. `echo "node_modules" > .gitignore
  6. git init
  7. git add *
  8. git commit -av <- assumes hx is set as the default git editor

I expected this to happen:

  • When editing the commit message for the first commit, I expect helix to be fast and responsive, as usual.

Instead, this happened:

  • Editing the message is extremely laggy. It takes seconds for characters to appear in insert mode.

Helix log

No response

Platform

Linux

Terminal Emulator

'Terminal' on ChromeOS

Helix Version

v0.5.0-887-gc0dbd6dc

@slinlee slinlee added the C-bug Category: This is a bug label Mar 18, 2022
@the-mikedavis the-mikedavis added the A-tree-sitter Area: Tree-sitter label Mar 18, 2022
@the-mikedavis the-mikedavis self-assigned this Mar 18, 2022
@the-mikedavis
Copy link
Member

I suspect the package-lock.json is pretty large for this first commit, right? Highlighting for verbose commits (git commit -v) can be horribly laggy when there are many lines changed. I updated tree-sitter-git-commit with a fix that is very snappy even on commits with thousands of lines changed. It should make its way into the next release. In the meantime, you can avoid the slow performance by not using the -v flag when you know a commit will be very large.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tree-sitter Area: Tree-sitter C-bug Category: This is a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants