fastlane/docs

`no-highlight` language superseded

Opened this issue · 3 comments

WARN: Could not find the language 'no-highlight', did you forget to load/include a language module?
WARN: Falling back to no-highlight mode for this block.
      <code class="language-no-highlight">fastlane release </code>

(yes I also find the console wording like this hilarious…)

Screen Shot 2024-03-17 at 15 41 22

no-highlight is an old class, today I think it's nohighlight for hljs, not sure if it changes anything regarding md output or css styling…
(but has to be passed as class=nohighlight not class=language-nohighlight anyways…)

There are a lot of occurrences: [search]

Screen Shot 2024-03-17 at 15 44 31

most of which would use a sh grammar and be rid of it, while some could use a plaintext maybe, so the block is still styled the same as any hljs code fence.

I can proceed and fix this, selecting the best grammar one by one for what's in the repo here, and then peek around fastlane/fastlane about the autogenerated content… if there's any interest in this.

But I'd need more context from @rogerluan behind fastlane/fastlane#12735 (as there's no rationale in the PR description) — why not sh there?

Q: if that changes upstream to sh incl. tests et al. … is there a any avenue appropriate where to post this style change so folks used to the old class name will be notified before having their tests failed for the non-functional no-highlight keyword being used?

This proposal LGTM @janbrasna 💪

I think the rationale behind fastlane/fastlane#12735 was that CLI commands are different than sh syntax highlighting. CLI commands (plain text commands) technically don't have a syntax highlighting AFAIK, while Shell scripts (the programming language) do. There's an argument that can be made about CLI commands being sh commands though 😅

I personally don't feel strongly about going either way. Personally I use sh syntax highlighting even for CLI, in my repos/projects 😅 so that would be ok by me.

Perhaps @revolter could chime in here too, regarding that PR 🤗

But yeah the only thing I'd keep in mind there is that all of those …/generated/… file paths shouldn't be edited in this repo, but in the fastlane/fastlane repo instead 🙏

Thanks for taking a stab at this, @janbrasna ! 🙌

Yeah, really sorry for not providing a rationale back then.

Unfortunately, I can't recall my thinking behind those changes, and I can only assume that I made that decision due to a lack of experience.

As such, I would definitely go with sh as well for CLI commands!

Let me know if you need any help with this.