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

Instead of Linting... show which linter is actually slow and still running #1810

Open
kaste opened this issue May 25, 2021 · 5 comments
Open

Comments

@kaste
Copy link
Contributor

kaste commented May 25, 2021

We have the simple Linting... indicator via busy_indicator_view.py. Make this more useful by showing which linter is still running, for example mypy.... Maybe flake8, mypy... for multiple linters.

I don't know the exact optics here. ... stands for the animated . thing we have. Typically only one linter is still running and we could just print mypy.... If really multiple linters are slow, either switch back to the simplified Linting... or spell all slow linters out like flake8, mypy....

@kaste kaste changed the title Instead of Linting... show which linter is actually slow ans still running Instead of Linting... show which linter is actually slow and still running May 25, 2021
@braver
Copy link
Member

braver commented May 25, 2021

I feel like we maybe discussed this before? Dejavu.

Anyway, I think the idea is good. "This thing is slow" is much better of course than "something is slow". We don't want to have multiple "animations" going on in the status bar, but I doubt that happens a lot (or rather, I hope so).

Ideally our view in the status bar is stable, like linterA(w:1) linterB(e:1) switching seamlessly to linterA... linterB(e:1) and switching seamlessly to linterA linterB(e:1). Maybe we should just drop the animation and go for a simple horizontal ellipsis if we're waiting for a linter.

@kaste
Copy link
Contributor Author

kaste commented May 25, 2021

Yeah, for now I just wanted to reuse what we have, and we have active_linter_view and busy_indicator_view. Ideally we would have just one. If we have it in one, we face the problem that mypy might be slow but we're actually only showing ok, no names at all. etc. So it seems the one thing shows the results ok, flake(w:1), or eslint?. And the other thing is "hold on, the left thing is probably lying; the result is not up to date".

@braver
Copy link
Member

braver commented May 25, 2021

Well, we always accept that the status bar lags behind what happens in the editor. In my mind it's a question of how much lag to accept before we update that view to say "our mypy result here is out of date, we're waiting for news", and show mypy... flake(w:1)

@kaste
Copy link
Contributor Author

kaste commented May 25, 2021

In the expanded state mypy flake(w:1) we can attach something to the name and make it mypy... flake8(w:1), but in the short ok state I don't see that we should expand to flake mypy... just to go back to ok but rather do ok mypy....

We use the animation to tell it is a transient, momentary state we're in, a static ellipsis is like our ? something that lasts until the user does something, we lint again; it doesn't go away in just another second.

@braver
Copy link
Member

braver commented May 25, 2021

Yes, totally agree with everything there 👍🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants