Bug 451978 - Kate Build plugin does not recognize pylint command output
Summary: Kate Build plugin does not recognize pylint command output
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: application (other bugs)
Version First Reported In: 20.12.2
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-28 00:27 UTC by Forest
Modified: 2025-01-31 09:46 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Forest 2022-03-28 00:27:54 UTC
SUMMARY

Python programmers often run pylint to quickly find code defects. When pylint is used as a build command in Kate, the output is excluded from Kate's parsed output window. It is visible only by manually selecting the Full Output filter every time the command is run, which is not very useful, because warnings and errors are not flagged, and clicking on them does not navigate to the line where the problem was found, and the next/previous error shortcuts do not work.

Pylint's output looks like this:

    ************* Module myfile
    /path/to/myfile:12:0: R0903: Too few public methods (1/2) (too-few-public-methods)
    /path/to/myfile:345:0: R0903: Too few public methods (1/2) (too-few-public-methods)
    
    ------------------------------------------------------------------
    Your code has been rated at 9.88/10 (previous run: 9.88/10, +0.00)

The first space-delimited field of each warning/error line follows the format used by many C compilers: a colon-separated file path, line number, and column number. This makes it fairly easy for code editors to support. (Geany handles it nicely, for example.)

The second field is a pylint message ID: A single capital letter followed by four numeric digits, then a colon. In regex: "^[CRWEF]\\d\\d\\d\\d:" Those letters indicate the message type: Convention, Refactor, Warning, Error, Fatal

After that field is a human-readable message description.

Subtleties:
Pylint uses zero-based column numbers, while Kate seems to assume one-based column numbers.
Pylint's output is on stdout, while Kate seems to assume errors and warnings will appear on stderr.

STEPS TO REPRODUCE
1. Make "pylint %f" a build command in a Kate project.
2. Open a python file with some defects that pylint will detect.
3. Run the build command .

OBSERVED RESULT

No pylint output appears in Kate's output tab. Changing to tab's filter to "Full Output" reveals the pylint output, but it is just raw text. No distinction is made between errors, warnings, and misc. messages. Clicking the messages does not navigate to the relevant line of the python file.

EXPECTED RESULT

Pylint output should be parsed and clickable to navigate to the referenced line, and should respond to the Next Error / Previous Error shortcuts, just like any other compiler-style output. Ideally, it should also work with Kate's Errors/Warnings/Parsed Output filter.

SOFTWARE/OS VERSIONS
Linux Version: 5.16.0
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Comment 1 Kåre Särs 2022-03-29 14:56:02 UTC
Thanks for the report. I think the reason is that pylint outputs everything to stdout in stead of putting errors and warnings to stderr like gcc and clang. 

We have added a  workaround for similar issues when using Ninja for building...
Comment 2 Christoph Cullmann 2024-12-10 22:28:10 UTC
We have now support for Flake8 and Co. in the project plugin under 'Code Analysis'.

I think that should cover this use-case.
Comment 3 Kåre Särs 2024-12-11 10:14:27 UTC
We have moved to merge stdout and stderr parsing so this should work now...
Comment 4 Bug Janitor Service 2024-12-26 03:47:30 UTC
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Forest 2025-01-05 21:54:44 UTC
I haven't had a chance to test this. Please don't auto-close it.

(FWIW, I strongly dislike auto-close bots in issue trackers.)
Comment 6 Forest 2025-01-16 22:07:16 UTC
In what release can this stdout/stderr merge be found and tested?

Has the column numbering issue (0-based vs. 1-based) been addressed?
Comment 7 Waqar Ahmed 2025-01-31 09:46:58 UTC
> I haven't had a chance to test this. Please don't auto-close it.
> In what release can this stdout/stderr merge be found and tested?

kate 24.12

You can find nightly appImages on kate's website for testing.

Feel free to reopen the bug if you can still reproduce the issue.