Markdown is ignored if it doesn't contain code blocks

[spenserblack]

Duplicates

• I have searched the existing issues

Current behavior 😯

Running onefetch -T prose on a repo that contains Markdown results in

Error: Could not find any source code in this repository

Expected behavior 🤔

Markdown should be detected if prose is enabled, even if the Markdown doesn't contain code blocks.

Steps to reproduce 🕹

TMPDIR=$(mktemp -d)
cd $TMPDIR
git init
git commit --allow-empty -m "init"  # just adding a commit for some stats
cat <<EOF > file.md
# hello, world

This is a file without code blocks
EOF
onefetch -T prose  # error

cat << "EOF" > file.md
```bash
chmod +x install.sh
./install.sh
```
EOF
onefetch -T prose  # renders Markdown ASCII

Additional context/Screenshots 🔦

This looks similar to #627, but -T prose alone doesn't resolve this.

Possible Solution 💡

The issue seems to be that tokei marks lines of Markdown as comments (then what is <!-- -->? 😆) except for code blocks and blank lines. IMO all lines of Markdown should be counted (even blank lines, since they can have significance in the rendered output).

Unfortunately, this is a bit hard to do since all languages are defined in a data file. Perhaps an optional field called something like tokei-fields can be used, which would allow one to list what types of lines should be used ([Code, Comments, Blanks]).

[spenserblack]

We could change this

onefetch/src/info/langs/mod.rs

Line 34 in 4452b71

let mut code = language.code;

into something like

let code = language::compile_loc(language)

And the terra code can loop through tokei-fields || [code], and do lines += language.{{ field }}.

Or perhaps a CLI arg that allows what "type" of line is allowed?

We can always hard-code Markdown to be a special case, but that won't be pretty (but is there a pretty solution to this?) 😆

[o2sh]

We can always hard-code Markdown to be a special case

It's indeed very tempting 😅
To a lesser extent, we may also encounter a similar problem with jupyter notebooks.

The solution using tera with a CLI flag is great and would be a nice feature by itself, but it would impact the LOC for all languages detected inside the repo and not just Markdown.

[spenserblack]

I guess if we're giving the user control, it wouldn't just be "LOC types", but "LOC types" per language. Which is way to complex for CLI, and would probably belong in a config file. But that's if we give users controls. We probably want to keep some consistency in results.

The CLI arg suggestion was basically just me being lazy and moving the responsibility to the user 😆

So I'm thinking

Jupyter:
  # ...
  tokei-lang-fields: [code, comments]

Luckily I don't think we have too many languages to apply this too, so the biggest challenge is working with the tera template.

[o2sh]

Very nice solution. This means that only markdown and Jupyter - for now - would have this additional parameter leaving the other language entries unchanged (that would default to just [code]).