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

Add error messages for kramdown #459

Closed
flaviut opened this Issue Jul 13, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@flaviut

flaviut commented Jul 13, 2014

The kramdown filter does not do anything with the messages that kramdown outputs, which makes debugging invalid markdown more difficult.

I'm not sure about the best way to output them, just print them out once the document has been processed?

@gpakosz

This comment has been minimized.

Show comment
Hide comment
@gpakosz

gpakosz Jul 25, 2014

Member

Well I just made the following test:

$ irb
irb(main):001:0> require 'kramdown'
=> true
irb(main):002:0> Kramdown::Document.new('{:foo}this is bogus').warnings
=> ["Found span IAL after text - ignoring it"]

But

irb(main):002:0> require 'kramdown'
=> true
irb(main):003:0> Kramdown::Document.new('this is a [link]
irb(main):004:1'
irb(main):005:1' [link]: foo
irb(main):006:1' [link]: bar').warnings
=> ["Duplicate link ID 'link' on line 5 - overwriting"]

After having discussed with @gettalong it happens not all warnings have line number information so it's not always possible to trace back to the offending Markdown fragment.

While discussing with @gettalong, I wondered whether the warnings array could become an array of hash so that kramdown gives does the job of tracking the line number, the offending content fragment (line excerpt etc).

Then, how would move on from the point kramdown gets more detailed warnings reporting? @ddfreyne, should the kramdown filter format a message to $stderr or is there facility in nanoc we should use to report errors/warnings (something that would understand the verbose flag).

Member

gpakosz commented Jul 25, 2014

Well I just made the following test:

$ irb
irb(main):001:0> require 'kramdown'
=> true
irb(main):002:0> Kramdown::Document.new('{:foo}this is bogus').warnings
=> ["Found span IAL after text - ignoring it"]

But

irb(main):002:0> require 'kramdown'
=> true
irb(main):003:0> Kramdown::Document.new('this is a [link]
irb(main):004:1'
irb(main):005:1' [link]: foo
irb(main):006:1' [link]: bar').warnings
=> ["Duplicate link ID 'link' on line 5 - overwriting"]

After having discussed with @gettalong it happens not all warnings have line number information so it's not always possible to trace back to the offending Markdown fragment.

While discussing with @gettalong, I wondered whether the warnings array could become an array of hash so that kramdown gives does the job of tracking the line number, the offending content fragment (line excerpt etc).

Then, how would move on from the point kramdown gets more detailed warnings reporting? @ddfreyne, should the kramdown filter format a message to $stderr or is there facility in nanoc we should use to report errors/warnings (something that would understand the verbose flag).

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Aug 9, 2014

Member

There's no warning reporting system other that writing to $stderr. Errors are generally exceptions.

I could adjust the kramdown filter to print warnings, if any, but I fear that it’d cause spam on the screen that people will ignore. Seem like a good idea to do it anyway though.

Member

ddfreyne commented Aug 9, 2014

There's no warning reporting system other that writing to $stderr. Errors are generally exceptions.

I could adjust the kramdown filter to print warnings, if any, but I fear that it’d cause spam on the screen that people will ignore. Seem like a good idea to do it anyway though.

@ddfreyne ddfreyne added the enhancement label Aug 9, 2014

@ddfreyne ddfreyne added the clear fix label Sep 6, 2014

@ddfreyne ddfreyne modified the milestones: 3.8, 3.7.5 Nov 29, 2014

@ddfreyne ddfreyne removed the fix is known label Dec 6, 2014

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 11, 2015

Member

Potential fix in #519.

Member

ddfreyne commented Jan 11, 2015

Potential fix in #519.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Jan 11, 2015

Member

Fixed by #519. Fix will be in 3.7.5!

Member

ddfreyne commented Jan 11, 2015

Fixed by #519. Fix will be in 3.7.5!

@ddfreyne ddfreyne closed this Jan 11, 2015

ddfreyne added a commit that referenced this issue Jan 11, 2015

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