Giter VIP home page Giter VIP logo

Comments (3)

elarivie avatar elarivie commented on August 19, 2024

@ShadowLNC

Could you provide more info about "Additionally, the messages are shown when linting another file that is not even in the same project "

TLDR: The behavior that you have is not a bug but works like that by design.

You have pretty good questions, but To answer your questions I have to describe the architecture a little.

Here is a very high-level and simplified view of the architecture of linter-mypy, showing the different components interaction (This is pretty much the same architecture for all linter-* within atom).

Mypylinter-mypylinteratom

Let's take a scenario where you save a file:
0- User open a text editor tab
1- User save the text editor tab
2- Atom send an event about this user action
3- Linter is listening to atom save event
4- Linter ask registered linters (like linter-mypy and many other) to lint the atom text editor (a tab within atom) (from this point I will refer to that process as a Lint-Run)
5- Linter-mypy receive the request from Linter (it wakes-up)
6- Linter-mypy base on its own settings and the provided text editor data(filepath+text buffer) creates a command line command and append arguments and set environment variable etc...
7- Linter-mypy calls Mypy through its CLI (it creates a short lived Mypy process)
8- linter-mypy parse the stdout/stderr/exitcode that Mypy outputs.
9- linter-mypy creates lint messages and answer to the linter request of step 4.
10-From this point linter-mypy has done its job and does not keep track of previously provided lint messages.
11- Linter receives the lint messages from linter-mypy and keep a global list of lint message from all the registered linter... those lint messages are all associated with a TextEditor (a text file tab in atom see step 4)
12- Linter-ui-default interacts with atom and display lint message list for the user+add colored underline, etc.

13- User uses the same textEditor tab and Save again
14- Linter re-trigger this whole process again and a new lint-Run is launched, linter replace all old lint message with the newly lint message of the latest lint-Run.

The internal memory of Linter can be described as a 3 columns database table:

  • PK TextEditorInstance (a text file tab within atom)
  • PK Linter_name (linter-* like linter-mypy)
  • lint_messages : A list of lint messages (from the latest lint-Run)

With all of those info you should now understand:

  • why when a TextFile tab is closed that its associated lint message disappear.

Note: linter-mypy (with the mypy settings follow imports) cheat a little bit this process and when requested to lint a textEditor of
file A, it may also answer with lint message for file B but those lint messages are nevertheless associated with a textEditor tab of FileA

Now you can understand why if you open a text editor tab for FileB that it will create from a user point of view duplicated lint message... but internally they are associated with different TextEditor tab instance.

Hopefully you will read up to here :)

from linter-mypy.

ShadowLNC avatar ShadowLNC commented on August 19, 2024

Thanks for the detailed response! 😄

Just to confirm, if I have the following files:
a.py

var = {}  # Will cause a mypy issue.
print(var)

b.py

from a import var
print(var)
  1. Am I correct that if I lint b.py, linter-mypy will respond also with messages related to a.py in the textEditor b.py? I'm happy for this to occur (as long as it's for the follow imports setting).
  2. Is it also supposed to send messages to textEditor a.py (the messages related to a.py)? It seems to do so.
  3. If I lint/re-lint a.py after b.py has already been linted, should b.py's messages be updated? I guess it would not since you say that linter-mypy does not track messages, and I guess it does not remember the import tree (and this is ok with me).

It seems that if I repeatedly switch tabs between a.py and b.py, it duplicates all of the messages issued by linter-mypy (I'm not running the linter, just clicking between the two file tabs). I can end up with 10+ instances of the same message in these cases. Specifically, when I switch tabs to a.py a second or subsequent time after both a.py and b.py have both been previously linted (and a.py already has one set of duplicates by design per (2) above), then the duplication occurs (adding one set of extra messages each time).

Once duplicated, these messages appear in all linter dialogues. (Previously linted files, newly linted files, any files in Atom that have linter messages open - including files in other projects.) I am not sure if this is a linter-mypy bug, since it seems like the main linter plugin might be replicating these messages globally or something.

The linter warning count (titled "Linter Infos") on the bottom "taskbar" does not include the count of duplicated messages on any file, except the one set of duplicates from (2) when viewing a.py (again by design).

(For a file with no messages, I cannot open the linter messages, and cannot view the duplicates.)

(Edit: Current Follow Imports setting is on Normal.)

from linter-mypy.

elarivie avatar elarivie commented on August 19, 2024

1- Effectively
2- Yes and no, it does not 'send' lint message to the other text editor they are still internally linked to the text editor of b.py which triggered the lint-run, but yes they will show up in a text editor of a.py ... (see point 3 below)

3-
To refresh a lint message you have to trigger a lint-run within the text editor which originally reported a given lint message (which may be another text editor than the one in which you see it)

In your scenario described above about a.py and b.py:
1- You trigger a lint-run for b.py
1a- it reports lint msg for b.py and a.py (due to follow imports setting)

2- You trigger a lint-run for a.py
2a- it reports new lint msg for a.py (from a user point of view it creates duplicate entry)
3- You fix the issues in a.py
3a- Half of the reported lint msg of a.py are removed (from a user point of view there are no more duplicates, but the lint warning for a.py are still present (since the remaining ones are associated with the text editor of b.py))
4- You trigger a lint-run for b.py
4a- The remaining reported msg of a.py are removed (actually at this step no more warning message are present for a.py)

from linter-mypy.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.