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

ESlint is blocking UI #12

Open
koenpunt opened this issue Feb 22, 2017 · 15 comments
Open

ESlint is blocking UI #12

koenpunt opened this issue Feb 22, 2017 · 15 comments

Comments

@koenpunt
Copy link

Currently when eslint is running, the editor stops responding. Would it be possible to run it asynchronous/in the background to prevent this lag?

@natesilva
Copy link
Owner

Not sure how to do this. I’ll keep this open in case I ever get a chance to try making it async.

One thing that may be happening is that, on large files, it can call the mate --set-mark command many times. If a common setting like quote marks or semicolons is different than the file you are looking at, it may need to set hundreds of marks. Currently we set them 10 at a time, so it can get called many times. Maybe this could be increased, I’d need to test that it’s not exceeding some maximum command-line length limit.

@koenpunt
Copy link
Author

koenpunt commented Jun 7, 2017

It actually doesn't matter if it is 1 or more markers, the linting itself is just slow, and while running I can't type anything. Maybe @sorbits can point us in the right direction on how to fix this/make it async?

@noniq
Copy link
Contributor

noniq commented Jun 12, 2017

Same here.

In my RuboCop bundle I’m using TextMate::Executor.run from TextMate’s “Ruby API”. This internally uses TextMate::Process.run, which does all the work of starting a subprocess so that it can run asynchronously while still being able to communicate with it: https://github.com/textmate/bundle-support.tmbundle/blob/master/Support/shared/lib/tm/process.rb

So this is exactly what would be needed here, but unfortunately it’s in Ruby and this bundles code is written in Python. I don’t think TextMate’s (rather limited) Python API has a similar function, but I’m not really familiar with this.

@meyer
Copy link

meyer commented Jun 12, 2017

@noniq very cool, thanks for sharing. I had no idea the TextMate Ruby API was a thing.

@natesilva
Copy link
Owner

So right now it doesn’t use any API, it shells out to the mate command to set the gutter marks, and that’s slow. Can the Ruby API do that? I’m not a Ruby programmer, but if anyone knows a better way to set the gutter marks, or maybe write a wrapper script to the Ruby API, that would help a lot.

@noniq
Copy link
Contributor

noniq commented Jun 12, 2017

To be clear: What I called “Ruby API” is nothing more than a set of Ruby classes and functions, bundled with TextMate (see the “Bundle Support” bundle). 😉 So in principle it would be totally possible to reimplement TextMate::Process.run in a language like Python – no special magic here. I’m not proficient enough in Python to do this, though. But maybe someone else is?

@sorbits
Copy link

sorbits commented Jun 12, 2017

Maybe @sorbits can point us in the right direction on how to fix this/make it async?

I see there are two ESLint commands in this bundle, which of them is the one that is slow?

@sorbits
Copy link

sorbits commented Jun 12, 2017

Currently we set them 10 at a time, so it can get called many times. Maybe this could be increased, I’d need to test that it’s not exceeding some maximum command-line length limit.

I think the maximum command line length is 64KB, so this is probably not something to worry about.

For the SCM Diff bundle we set all the +/- gutter marks with only a single call to mate.

@koenpunt
Copy link
Author

koenpunt commented Jun 12, 2017

I see there are two ESLint commands in this bundle, which of them is the one that is slow?

"Save & Validate" blocks any interaction after save, sometimes even for multiple seconds. This means no cursor movement, or anything. The other might not be too quick either, but that one doesn't block anything so that's acceptable.

@sorbits
Copy link

sorbits commented Jun 12, 2017 via email

@koenpunt
Copy link
Author

For that command, try change output to HTML / New Window.

When I do that, the cursor moves its focus to the new window when the command completes.

@natesilva
Copy link
Owner

@koenpunt Another quick fix to try is to change main.py at line 176 -- change the number 10 to a much larger number. Based on what @sorbits said, I’m not sure it will solve the problem, but it’s worth a try.

@sorbits
Copy link

sorbits commented Jun 12, 2017 via email

@koenpunt
Copy link
Author

try is to change main.py at line 176 -- change the number 10 to a much larger number

I don't think that will make a difference, because even in a file where only a single marker is shown the ui is being blocked.

My python knowledge is minimal, but I do believe it's made for concurrency/multi threading, not sure if that's something we can make use of?

@koenpunt
Copy link
Author

koenpunt commented Jun 12, 2017

The new window is a HTML window, correct?

The new window is indeed a HTML window, but with of course plaintext being rendered.

And before changing, did it also open a HTML window, but without moving
focus? Because behavior should be the same.

You mean before the change of output? Than no, before it was just a tooltip with the summary.

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

No branches or pull requests

5 participants