fix: homogenize markdown across files using markdownlint rules

[davorpa]

What does this PR do?

Improve repo

For resources

Description

Why is this valuable (or not)?

Homogenizes using markdownlint rules (see also #6829 to check which are applied)

See each commit title/description to understand better what we are doing

Checklist:

• Read our contributing guidelines.
• Search for duplicates.
• Include author(s) and platform where appropriate.
• Put lists in alphabetical order, correct spacing.
• Add needed indications (PDF, access notes, under construction).
• Used an informative name for this pull request.

Follow-up

• Check the status of GitHub Actions and resolve any reported warnings!

[davorpa]

Conflicts are with merges of

• chore: merge and homogenize HTML & CSS sections across files #6963

[davorpa]

Conflicts remains with

• Update free-programming-books-fa_IR.md #6983

merges due to final blank lines

[LuigiImVector]

Wasn't it enough to change the value of "indent" to 2? Even if that meant disabling MD005.

[davorpa]

Wasn't it enough to change the value of "indent" to 2? Even if that meant disabling MD005.

According to .editorconfig file, indentation is using 4 spaces

free-programming-books/.editorconfig

Lines 11 to 14 in 04cf8c8

	end_of_line = lf
	indent_size = 4
	indent_style = space
	insert_final_newline = true

Is this why enable MD005/MD007 to use that number of spaces.

free-programming-books/.markdownlint.jsonc

Lines 50 to 80 in 048c02d

	// MD005/list-indent - Inconsistent indentation for list items at the same level
	"MD005": true,
	// MD006/ul-start-left - Consider starting bulleted lists at the beginning of the line
	"MD006": true,
	// MD007/ul-indent - Unordered list indentation
	"MD007": {
	// Spaces for indent (sync with .editorconfig)
	"indent": 4,
	// Whether to indent the first level of the list
	"start_indented": false
	},
	// MD009/no-trailing-spaces - Trailing spaces
	"MD009": {
	// Spaces for line break (sync with .editorconfig)
	"br_spaces": 4,
	// Allow spaces for empty lines in list items
	"list_item_empty_lines": false,
	// Include unnecessary breaks
	"strict": false
	},
	// MD010/no-hard-tabs - Hard tabs
	"MD010": {
	// Include code blocks
	"code_blocks": true,
	// Number of spaces for each hard tab
	"spaces_per_tab": 4
	},

Let's discuss about it if is wrong

[LuigiImVector]

On the official kramdown website it says:

kramdown assumes that tab stops are set at multiples of four. This is especially important when using tabs for indentation in lists. Also, tabs may only be used at the beginning of a line when indenting text and must not be preceded by spaces. Otherwise the results may be unexpected.

So I think 4 indent_size it's okay.

[davorpa]

Conflicts again due to #6989 merge which modifies TOC entries adding DL, ML, NLP...

[davorpa]

More conflicts after merge #6986 which modify TOC entries removing impress.js and has other indent problems

[eshellman]

What's the motivation behind replacing translated words with Englishe words?

[davorpa]

What's the motivation behind replacing translated words with Englishe words?

I suppose you're referring to 4d6a74e commit which normalizes TOC section header to Index word, it doesn't?

I don't know yet how it works but thinking in the fpb-parser, I hope it helps to filter this section from processing. It'll be easy to do using same word and heading level (3 #) or even more... develop a fpb-lint rule expecting this Index branch as markdown listing element

https://github.com/EbookFoundation/free-programming-books-parser/blob/5eaf00bfd861856a85b2ba6f2d2aa282fab55a69/index.js#L178-L192

As we can see... Index is expected according to current sourcecode. I open EbookFoundation/free-programming-books-parser#1 to address it

Of course, make a git revert is always a good option here if it isn't relevant or already contemplated

[eshellman]

What's the motivation behind replacing translated words with Englishe words?

I suppose you're referring to 4d6a74e commit which normalizes TOC section header to Index word, it doesn't?

I don't know yet how it works but thinking in the fpb-parser, I hope it helps to filter this section from processing. It'll be easy to do using same word and heading level (3 #) or even more... develop a fpb-lint rule expecting this Index branch as markdown listing element

https://github.com/EbookFoundation/free-programming-books-parser/blob/5eaf00bfd861856a85b2ba6f2d2aa282fab55a69/index.js#L178-L192

As we can see... Index is expected according to current sourcecode. I open EbookFoundation/free-programming-books-parser#1 to address it

Of course, make a git revert is always a good option here if it isn't relevant or already contemplated

best not to fix something unless its broken

[davorpa]

best not to fix something unless its broken

Then reverting 4d6a74e 😄

[eshellman]

LGTM. Ready to merge?

[davorpa]

LGTM. Ready to merge?

Yes, sure! No more work on my own.

Can I merge it to get some GitHub profile achievement badges?

[eshellman]

go ahead

…

On Aug 12, 2022, at 2:05 PM, David Ordás ***@***.***> wrote: LGTM. Ready to merge? Yes, sure! No more work on my own. Can I merge it to get some GitHub profile achievement badges? — Reply to this email directly, view it on GitHub <#6988 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHCGMIEAAWMFL3463DAZ5LVYY4W3ANCNFSM55YCIC4Q>. You are receiving this because you commented.