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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace "flycheck-compile" with a "flycheck-debug-checker" command #854

Open
5 tasks
swsnr opened this issue Jan 13, 2016 · 10 comments
Open
5 tasks

Replace "flycheck-compile" with a "flycheck-debug-checker" command #854

swsnr opened this issue Jan 13, 2016 · 10 comments
Labels

Comments

@swsnr
Copy link
Contributor

swsnr commented Jan 13, 2016

flycheck-compile is intended as a debugging tool, but it does a poor job at this:

  • The name is absolutely misleading 馃槑
  • It runs syntax checkers differently from Flycheck, causing escaping issues (see Obtain the complete command line and error message聽#852)
  • It doesn't help with interpreting the output. Specifically it doesn't show what errors Flycheck would parse from these errors.

I would like to remove flycheck-compile, and introduce a new command flycheck-debug-checker instead which is really targeted at inspecting and debugging a syntax checker output. The command should

  • have a nice name (we can find something better than flycheck-debug-checker hopefully)
  • run the checker like Flycheck does, but keep the raw output
  • pop up a buffer that includes the raw output and show the errors parsed from that output
  • be documented in our contributing guide as general debugging tool
  • be documented in the manual chapter about defining syntax checkers

Suggested layout:

Run checker `foo' on buffer bar.foo, parsed errors:

<stdin>: line 1: column 2: level warning: A bad error (id: xxxx)
鈥

From output:
鈥

Command: foo --lint --standard-input

This layout ensures that in case Flycheck fails to parse errors the output comes right at the beginning of the buffer, to minimise scrolling.

@cpitclaudel
Copy link
Member

Yes, I think that would be nice :) Sorry for pointing users to that command a bit too quickly!

@swsnr
Copy link
Contributor Author

swsnr commented Jan 13, 2016

@cpitclaudel That's totally fine. It's there for debugging, and we should tell users to user it for this purpose.

The confusion in #852 was a very unfortunate coincidence. We'd believe that shell-quote-argument has its flaws?! 馃槼

@cpitclaudel
Copy link
Member

:)

If we can minimize that quoting example, I'll be happy to file a bug. It's surprising to say the least.

@cmarqu
Copy link
Contributor

cmarqu commented Jan 23, 2016

What I also can imagine speeding up the debugging process for a new checker setup is to have a (multiline) string with a copied example output of the checking tool (info, warning, error one after the other) and a command to run this string through the matcher function.
This add implicit documentation and could even become part of a regression test.
When e.g. a checker stops working or doesn't find a specific error output, then that makes it easier to compare the working example with your specific failing example.

@swsnr
Copy link
Contributor Author

swsnr commented Jan 23, 2016

@cmarqu I'm not sure whether I understand you. Are you suggesting that we add an example output to every defined syntax checker, e.g. via an :example keyword?

@cmarqu
Copy link
Contributor

cmarqu commented Jan 23, 2016

No, rather an example for the input of a checker, i.e. one error line of the output of the tool (say, pylint).

@swsnr
Copy link
Contributor Author

swsnr commented Jan 23, 2016

@cmarqu Yep, that's what I meant鈥擨 was referring to the output of the underlying tool. Just to clarify, you'd like to see a syntax checker definition such as:

(flycheck-define-checker pylint
  :command (pylint 鈥)
  :example "3:10: warning: Undefined function foo"
  鈥)

@cmarqu
Copy link
Contributor

cmarqu commented Jan 23, 2016

Ah, yes, sorry for the misunderstanding, our example is what I had in mind.
You'd maybe want to separate that :example-info, :example-warning, :example-error and have them accept lists of strings (sometimes tools produce output both with and without line numbers etc.), but I'll leave the details to you.

@swsnr
Copy link
Contributor Author

swsnr commented Jan 23, 2016

@cmarqu Honestly, I don't think that this is a good idea. What purpose would these examples serve? What problems would they solve that'd balance the enormous effort of adding and maintaining them?

@swsnr
Copy link
Contributor Author

swsnr commented Jan 27, 2016

What follows is a summary of a discussion @cmarqu and me had about the shape of this feature on Gitter. Specifically, @cmarqu raised concerns about the need for excessive scrolling in a debugging buffer, which we would address by ordering the buffer appropriately to minimise the amount of scrolling necessary. For this purpose we'd need to ensure to prominently place the output particularly if the command fails to parse any checkers.

I've updated the original post with a suggested layout.

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

No branches or pull requests

3 participants