CLI tweaks resolving #250

[T3sT3ro]

Partially implemented #250

• [x] ~~ferium info should show information about the current profile and modpack~~
  • [x] ferium profile info added instead to be more scoped
  • [x] ferium modpack info info should be added in a similar manner
• [x] ferium profile list - tweaked the active profile indicator to be bold green (active) suffix next to profile name.
• [x] When ferium add fails, ~~link to documentation about overrides (https://github.com/gorilla-devs/ferium#check-overrides)~~ hint about --dont-check-* flags as part of the error message.
• [x] ~~ferium profile should print the current profile, then Run ferium profile -h for more info about this command (likewise for ferium modpack too)~~ instead use ferium profile info to align with current usage patterns
• [x] ferium list should print a header with information about the profile about to be listed (i.e. profile name, loader, and mc version) as well
  • [x] added support for --markdown flag in the ferium list -vm variant
• [x] ferium profile switch should print more info about the profiles, not just the names
  • [x] ~~likewise for ferium modpack switch~~ no need for that
• [x] ferium profiles should be an alias to ferium profile list (likewise for ferium modpacks too)
• [x] ferium mods should be an alias to ferium list
• [x] ferium remove should print the project id of the removed mods too

[theRookieCoder]

Hmm I don't think a separate info subcommand is needed, I was thinking something like that would be added to the list command instead.

[T3sT3ro]

In the original proposal I mentioned ferium info. I noticed, that ferium profile info is less confusing to get basic info. ferium info poses those questions:

• Should it print both active profile and active modpack info? Why would I need those two things at the same time? If not, then would I want ferium info for profile info and ferium modpack info for modpack info?
• How would ferium info be different than ferium list? Is list just a superset of info with an extra mod list?
• If new project types come into ferium in the future, how would someone get a quick info about each type of projects - modpack, resourcepack, shaderpack, profile? I think the ferium <projectType> info is the most universal and memorable way than having an exception just for mods.

I also noticed, that I often switch profiles and need to know the most crucial info about my active one without the whole long list of mods:

• MC version
• loader
• name

If I were to implement the original proposal of including profile info in the ferium list without the separate ferium profile info, then I would always get more output than I wanted, and couldn't access above information alone:

• ferium list would print info and (possibly long) mod list to, so I would have to scroll to the top
• ferium profile list is the only other way to display short profile info, but it also includes other profiles which I again have to look through and possibly scroll.

I noticed that I started using ferium profile info right away - it gives crucial info in a simplest way and I recommend trying it as well.

[T3sT3ro]

I don't know how to add an alias ferium profiles to ferium profile list. and ferium modpacks to ferium modpack list.

I think I finished my job in this PR.

[T3sT3ro]

I've noticed, that the download log after ferium update still has the issue of aligning texts using unicode emojis:

I noticed it's a problem with padded rust macros e.g. format!({:40}, "<unicode emoji>") where emoji's width is not properly calculated. This is related to https://github.com/rust-lang/rust/issues/30646

[T3sT3ro]

I think this can be merged for now as-is after you review @theRookieCoder. If you have some idea how to deal properly with emoji character widths in padded fmt! (and similar) macros, you can adjust them accordingly.

I am a bit hesitant to add profiles alias to profile list, as I imagine it can get later a bit confusing for players, if they for example often use ferium profiles. I imagine they may mistakenly type ferium profiles create ... and it will be prompting them with errors.

[T3sT3ro]

@theRookieCoder, will you merge?

[cla-bot[bot]]

We require contributors to sign our Contributor License Agreement, and we don't have yours on file. In order for us to review and merge your code, please send a signing request to [email protected] and add your github handle to contributors list.

[T3sT3ro]

@blarfoon it would be good if you changed cla-bot so it doesn't require sending the email but simply clicking a button/commenting (or use cla-assistant instead).

[blarfoon]

Yeah eventually you'll just need to click a link and sign the document, this email thing is temporary. Sorry for the inconvenience

[theRookieCoder]

I'm really sorry @T3sT3ro but I genuinely forgot about this PR when implementing these features. I've implemented most of these features in 52cd45558e13dc26fc5d3dc9047c3f54a51ea00a

[T3sT3ro]

Damn, too bad :P Is there something missing from you commit that was present in the PR?