FR: Add Rules from markdownlint about obsidian-linter HOT 31 OPEN

I like the idea of using something like remark to supply most of the rules or even get the linting framework setup to allow extensions as well. It looks like there is an example of it for remark-lint here. I will have to test it locally and see what happens. But it would help to not have to reinvent the wheel.

from obsidian-linter.

I got a simple example working, but I am not entirely sure how well it will work out since it may require dynamically building a couple of objects. I will try replacing an existing rule with the remark-lint plugin and see how well it works out. Hopefully it will not be too cumbersome, but if we did go this route we would probably need to go all in to make sure we had a consistent rule setup.

from obsidian-linter.

It may be easier to break this into several feature requests to make it seem less daunting and not have it sit in the swim lanes for the roadmap for the Linter for so long. I will think about whether to do that.

from obsidian-linter.

Looks like the following are the rules tat would be able to be fixable:

MD004 ul-style - Unordered list style
MD005 list-indent - Inconsistent indentation for list items at the same level
MD007 ul-indent - Unordered list indentation
MD009 no-trailing-spaces - Trailing spaces
MD010 no-hard-tabs - Hard tabs
MD011 no-reversed-links - Reversed link syntax
MD012 no-multiple-blanks - Multiple consecutive blank lines
MD014 commands-show-output - Dollar signs used before commands without showing output
MD018 no-missing-space-atx - No space after hash on atx style heading
MD019 no-multiple-space-atx - Multiple spaces after hash on atx style heading
MD020 no-missing-space-closed-atx - No space inside hashes on closed atx style heading
MD021 no-multiple-space-closed-atx - Multiple spaces inside hashes on closed atx style heading
MD022 blanks-around-headings/blanks-around-headers - Headings should be surrounded by blank lines
MD023 heading-start-left/header-start-left - Headings must start at the beginning of the line
MD026 no-trailing-punctuation - Trailing punctuation in heading
MD027 no-multiple-space-blockquote - Multiple spaces after blockquote symbol
MD030 list-marker-space - Spaces after list markers
MD031 blanks-around-fences - Fenced code blocks should be surrounded by blank lines
MD032 blanks-around-lists - Lists should be surrounded by blank lines
MD034 no-bare-urls - Bare URL used
MD037 no-space-in-emphasis - Spaces inside emphasis markers
MD038 no-space-in-code - Spaces inside code span elements
MD039 no-space-in-links - Spaces inside link text
MD044 proper-names - Proper names should have the correct capitalization
MD047 single-trailing-newline - Files should end with a single newline character
MD049 emphasis-style - Emphasis style should be consistent
MD050 strong-style - Strong style should be consistent

from obsidian-linter.

Thanks for compiling this. It would be great if we could leverage rules from existing linters instead of rewriting them. Would you be interested in looking into that?

from obsidian-linter.

Thanks for compiling this. It would be great if we could leverage rules from existing linters instead of rewriting them. Would you be interested in looking into that?

I can definitely take a look, but I am not sure to what extent the linters would be used the same way as this plugin works.

For example, markdownlint is not necessarily going to fix the issues for you. I can look into how the extension to VS Code works and get the rules implemented which is what I was hoping to do initially before I stumbled across this plugin.

from obsidian-linter.

Yeah, a while ago I was looking into remark which seemed promising. I believe its already installed in this project, but I never got around to using its plugins.

from obsidian-linter.

Here seems to be the current mapping:

from obsidian-linter.

Looks like to convert over to remark would leave us with only a few existing rules and a conversion or setup for the others.

from obsidian-linter.

I'd like to have a mixture of remark rules and custom rules. It should still be easy to add a new rule by writing a little regex. We can use remark when we can.

from obsidian-linter.

I'd like to have a mixture of remark rules and custom rules. It should still be easy to add a new rule by writing a little regex. We can use remark when we can.

Good to know. That should be allow for an interesting way of setting things up. Are we also allowing markdownlint rules assuming they can be used to fix issues rather than just warn about them?

from obsidian-linter.

Sure, I'm open to most things as custom rules.

from obsidian-linter.

If we wanted to implement the fixable aliases here is what that looks like when using remark rules:

@platers , do we want to implement MD018? Also, are there any of these we would not like to include? And would you like them added one at a time or all at once (I am guessing the former, but want to make sure since it is more testable)?

from obsidian-linter.

Lets skip MD018. Yeah lets add them one at a time, in order of convenience/utility.
If we add too many more rules we'll have to update the settings page to be easier to find rules.

from obsidian-linter.

Sounds good. It might be a good idea to add the aliases as well (i.e. MD###). Doing so would address point 2 of #107 .

Here are the 2 I think make the most sense to add first:

MD049 emphasis-style - Emphasis style should be consistent
MD050 strong-style - Strong style should be consistent

from obsidian-linter.

Sounds good, feel free to send PRs for new rules, no need to create issues for these.

from obsidian-linter.

Looks like we will not be able to use remark-lint as it seems to run things all at once. I am still checking, but it seems to run more than 1 rule at a time.

from obsidian-linter.

These are the rules that would try to run by default if my understanding is correct:
remark-lint-blockquote-indentation — warn when block quotes are either indented too much or too little
remark-lint-checkbox-character-style — warn when list item checkboxes violate a given style
remark-lint-checkbox-content-indent — warn when list item checkboxes are followed by too much whitespace
remark-lint-code-block-style — warn when code blocks do not adhere to a given style
remark-lint-definition-case — warn when definition labels are not lowercase
remark-lint-definition-spacing — warn when consecutive whitespace is used in a definition
remark-lint-emphasis-marker — warn when emphasis markers violate the given style
remark-lint-fenced-code-flag — warn when fenced code blocks occur without language flag
remark-lint-fenced-code-marker — warn when fenced code markers violate the given style
remark-lint-file-extension — warn when the file’s extension violates the given style
remark-lint-final-definition — warn when definitions are not placed at the end of the file
remark-lint-final-newline — warn when a newline at the end of a file is missing
remark-lint-first-heading-level — warn when the first heading has a level other than a specified value
remark-lint-hard-break-spaces — warn when too many spaces are used to create a hard break
remark-lint-heading-increment — warn when headings increment with more than 1 level at a time
remark-lint-heading-style — warn when heading style violates the given style
remark-lint-linebreak-style — warn when linebreaks violate a given or detected style
remark-lint-link-title-style — warn when link and definition titles occur with incorrect quotes
remark-lint-list-item-bullet-indent — warn when list item bullets are indented
remark-lint-list-item-content-indent — warn when the content of a list item has mixed indentation
remark-lint-list-item-indent — warn when the spacing between a list item’s bullet and its content violates a given style
remark-lint-list-item-spacing — warn when list looseness is incorrect
remark-lint-maximum-heading-length — warn when headings are too long
remark-lint-maximum-line-length — warn when lines are too long
remark-lint-no-blockquote-without-marker — warn when blank lines without markers (>) are found in a block quote
remark-lint-no-consecutive-blank-lines — warn for too many consecutive blank lines
remark-lint-no-duplicate-defined-urls — warn on definitions that define the same urls
remark-lint-no-duplicate-definitions — warn on duplicate definitions
remark-lint-no-duplicate-headings — warn on duplicate headings
remark-lint-no-duplicate-headings-in-section — warn on duplicate headings in a section
remark-lint-no-emphasis-as-heading — warn when emphasis or importance is used instead of a heading
remark-lint-no-empty-url — warn on empty URLs in links and images
remark-lint-no-file-name-articles — warn when file name start with an article
remark-lint-no-file-name-consecutive-dashes — warn when file names contain consecutive dashes
remark-lint-no-file-name-irregular-characters — warn when file names contain irregular characters
remark-lint-no-file-name-mixed-case — warn when file names use mixed case
remark-lint-no-file-name-outer-dashes — warn when file names contain initial or final dashes
remark-lint-no-heading-content-indent — warn when heading content is indented
remark-lint-no-heading-indent — warn when headings are indented
remark-lint-no-heading-like-paragraph — for too many hashes (h7+ “headings”)
remark-lint-no-heading-punctuation — warn when headings end in illegal characters
remark-lint-no-html — warn when HTML nodes are used
remark-lint-no-inline-padding — warn when inline nodes are padded with spaces
remark-lint-no-literal-urls — warn when URLs without angle brackets are used
remark-lint-no-missing-blank-lines — warn when missing blank lines
remark-lint-no-multiple-toplevel-headings — warn when multiple top level headings are used
remark-lint-no-paragraph-content-indent — warn when the content in paragraphs are indented
remark-lint-no-reference-like-url — warn when URLs are also defined identifiers
remark-lint-no-shell-dollars — warn when shell code is prefixed by dollars
remark-lint-no-shortcut-reference-image — warn when shortcut reference images are used
remark-lint-no-shortcut-reference-link — warn when shortcut reference links are used
remark-lint-no-table-indentation — warn when tables are indented
remark-lint-no-tabs — warn when hard tabs are used instead of spaces
remark-lint-no-undefined-references — warn when references to undefined definitions are found
remark-lint-no-unneeded-full-reference-image — warn when full reference images are used if they can be collapsed
remark-lint-no-unneeded-full-reference-link — warn when full reference links are used if they can be collapsed
remark-lint-no-unused-definitions — warn when unused definitions are found
remark-lint-ordered-list-marker-style — warn when the markers of ordered lists violate a given style
remark-lint-ordered-list-marker-value — warn when the marker value of ordered lists violates a given style
remark-lint-rule-style — warn when horizontal rules violate a given style
remark-lint-strikethrough-marker — warn when strikethrough markers violate the given style
remark-lint-strong-marker — warn when importance (strong) markers violate the given style
remark-lint-table-cell-padding — warn when table cells are incorrectly padded
remark-lint-table-pipe-alignment — warn when table pipes are not aligned
remark-lint-table-pipes — warn when table rows are not fenced with pipes
remark-lint-unordered-list-marker-style — warn when markers of unordered lists violate a given style

from obsidian-linter.

Oh does remark only give warnings? I thought it could fix errors too :(

from obsidian-linter.

It can fix errors, but it does so using presets which include more than 1 rule at a time. We would need to build the whole set of remark rules at once from what I am gathering unless there is a good way to get the rule sets in use.

from obsidian-linter.

If I am understanding correctly how remark-lint does things, it uses remark-stringify to update the markdown. remark-stringify seems to be an all or nothing thing where you configure how you want all the rules run, then you run the update for all the rules.

It does not seem that it is feasible to use remark-lint with how we currently run the rules. They only allow disabling certain plugins, but you have to specify how you want certain things done or else the default will be used (default is NOT to do nothing).

from obsidian-linter.

For this issue, it is my understanding that the following rules would need to be added to obsidian-linter or rule modifications may be needed:

• MD004 ul-style - Unordered list style
• MD005 list-indent - Inconsistent indentation for list items at the same level
• MD007 ul-indent - Unordered list indentation
• MD009 no-trailing-spaces - Trailing spaces
• MD010 no-hard-tabs - Hard tabs
• MD011 no-reversed-links - Reversed link syntax
• MD012 no-multiple-blanks - Multiple consecutive blank lines
• MD014 commands-show-output - Dollar signs used before commands without showing output
• MD018 no-missing-space-atx - No space after hash on atx style heading
  • This may erroneously affects tags, so it will not be included
• MD019 no-multiple-space-atx - Multiple spaces after hash on atx style heading
• This may erroneously affects tags, so it will not be
• MD020 no-missing-space-closed-atx - No space inside hashes on closed atx style heading
  included
• MD021 no-multiple-space-closed-atx - Multiple spaces inside hashes on closed atx style heading
• MD022 blanks-around-headings/blanks-around-headers - Headings should be surrounded by blank lines
  • We have something for this, but we should add a little more customization to make it comparable and maybe even allow a specification of empty lines per heading level (#140 )
• MD023 heading-start-left/header-start-left - Headings must start at the beginning of the line
• MD026 no-trailing-punctuation - Trailing punctuation in heading
• MD027 no-multiple-space-blockquote - Multiple spaces after blockquote symbol
• MD030 list-marker-space - Spaces after list markers
• MD031 blanks-around-fences - Fenced code blocks should be surrounded by blank lines
• MD032 blanks-around-lists - Lists should be surrounded by blank lines
• MD034 no-bare-urls - Bare URL used
• MD037 no-space-in-emphasis - Spaces inside emphasis markers
  • This will be something that will only affect simple cases and ignore any level of special nesting
• MD038 no-space-in-code - Spaces inside code span elements
• MD039 no-space-in-links - Spaces inside link text
• MD044 proper-names - Proper names should have the correct capitalization
• MD047 single-trailing-newline - Files should end with a single newline character
• MD049 emphasis-style - Emphasis style should be consistent
• MD050 strong-style - Strong style should be consistent

It looks like we have a good bit of work cut out for us if we want to get this completed, but it should be feasible to do so.

from obsidian-linter.

I may have been wrong about my initial assessment of whether or not we could use remark plugins that already exist to do some of the work for us. I am testing out whether they can actually be used. I think that if we dynamically add and remove plugins to use, we can probably use the plugins. I initially thought this was not allowed, but realized that it may very well be possible.

from obsidian-linter.

Well, it seems my initial assessment was correct. It is not possible to use remark rules to just update some of these values without accepting that some styling that may be disabled in the settings might have its equivalent run in remark-lint/remark-stringify. I thought it might be able to not auto format the other formats, but I was wrong.

from obsidian-linter.

Just wanted to chime in and say that I'm very glad to see markdownlint having played a role in this linter's design. I have markdownlint configured to my liking in VS Code and hope to translate it 1:1, if possible, over to Obsidian.

I'm using these markdownlint rules:

Implemented:

• MD034 (no-bare-urls): false.

Partially implemented:

• MD031 (blanks-around-fences): "list_items": false. Here false should ensure blank lines around fences everywhere but when within a list.

Unimplemented:

• MD007 (ul-indent): "indent": 4.
• MD013 (line-length): false.
• MD024 (no-duplicate-heading).
• MD028 (no-blanks-blockquote): false.
• MD033 (no-inline-html): "allowed_elements": [ "kbd" ].

Some rules may not be relevant to obsidian-linter, or may controlled via Obsidian itself. The categories above are just based off your list above, I haven't tested them.

As a side note, Obsidian looks very broken in editing view when trying to handle somewhat complex lists, but renders them fine in reading view. Strange and unexpected. Maybe it's not ready for me to switch to yet...

from obsidian-linter.

MD027 is taken care of by the new rule that was merged for setting a blockquote style (#718). It is not an exact match, but setting the value to be the style of space will make sure there is only 1 space after a blockquote indicator.

from obsidian-linter.

Hi! First: thanks a lot for this great plugin!

regarding MD007 ul-indent, I wanted to ask if there are any chances to get it done anytime soon 😅

I just now converted some text to markdown and was left with a lot of unordered lists having two spaces instead of 4. not a problem for the reading-mode, but in live-preview and source-mode it didn't look too well :D. I tried to use search-and-replace as possible, but a quick lint would have been much quicker 👍

from obsidian-linter.

Hi! First: thanks a lot for this great plugin!

regarding MD007 ul-indent, I wanted to ask if there are any chances to get it done anytime soon 😅

I just now converted some text to markdown and was left with a lot of unordered lists having two spaces instead of 4. not a problem for the reading-mode, but in live-preview and source-mode it didn't look too well :D. I tried to use search-and-replace as possible, but a quick lint would have been much quicker 👍

I am not sure where this falls on things. I am all over the place with when things get merged. I am currently working more on documenting things and some bug fixes, but I plan to shift focus a little once the documentation gets updated.

from obsidian-linter.

I would like to take another stab at remark lint and see if it is viable, but that will have to wait for now.

from obsidian-linter.

Any chance we could get a new push for MD007 ul-indent? I just discovered a "bug" in Obsidian that doesn't consider indents at 2 or 3 spaces to actually be indents in editor mode. I don't want to manually edit every note to work around this issue to get indent guides back and was hoping the Linter would just have an option to automatically convert all my 2 space lists into 4 spaces.

• Support Indentation Guides for all tab sizes (2 and 3 spaces)
• Support delimiter-based indentation guides in editor / live preview

Ideally this would be fixed at Obsidian's level but until then I'm fine using 4 spaces iff I can do it automatically without extra effort

from obsidian-linter.

I am not sure when ul-indent will get implemented. I have thought about it several times, but I do not believe I have figured out a good way to handle the spacing before the unordered lists.

from obsidian-linter.