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
lunaryorn opened this Issue Jan 13, 2016 · 10 comments

Comments

Projects
None yet
3 participants
@lunaryorn
Contributor

lunaryorn 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 #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

This comment has been minimized.

Member

cpitclaudel commented Jan 13, 2016

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

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn 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

This comment has been minimized.

Member

cpitclaudel commented Jan 13, 2016

:)

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

@cmarqu

This comment has been minimized.

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.

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn 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

This comment has been minimized.

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).

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn 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

This comment has been minimized.

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.

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn 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?

@lunaryorn

This comment has been minimized.

Contributor

lunaryorn 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