Add the ability to use more types of manuals/cheatsheets

[Sawbez]

Is your feature request related to a problem? Please describe.

Sort of, in general it's just annoying to have to exit halp and type in the next command(s) manually.

There are more manual pages and cheat sheets that are not directly covered by halp and it would be useful for halp to use more types. In #2 tldr is requested and there are similar things you can do with other commands, such as cheat, navi, command line interface pages, kb (kb would require extra work, so the config option wouldn't help much), and eg.

Describe the solution you'd like

halp should have the option to integrate at least some of these options. A simple configuration option would work for most of these, but kb in particular would require more work.

Describe alternatives you've considered

I could replace "man_command" in the config, but that removes the man functionality. Also, you can of course type it by hand but that defeats the purpose.

If you want, I can create a PR myself integrating some of these.

[orhun]

This sounds good, PR is welcome!

[0x61nas]

It would be a great feature, and I think that I can work on this

[orhun]

@anas-elgarhy assigned to you!

[0x61nas]

thx @orhun. I took a look at the "commands suggestions" and I have a few things to say.

• we have to take the nature of the project into consideration. we just take the command from the user and display the results based on that, we don't want to let the user search in the commands or do anything else. so 'cause of that, I think we don't need to have kb and navi as an option.
• I think that we really don't want to depend on other tools (especially if those tools are written with Python). so we have to find a way to get "help information" without the need to use the original tool. fortunately, the cheat and command line interface pages and eg databases are just regular markdown files hosted on GitHub so we can use roughly the same cheat.sh implementation and just make an HTTP request with the file name to the raw.githubusercontent.com
  • For example if we want to get the ls help page from command line interface pages database we just have to make an HTTP request for https://raw.githubusercontent.com/command-line-interface-pages/cli-pages/main/common/ls.clip
  • and the same for cheat, https://raw.githubusercontent.com/cheat/cheatsheets/master/ls
  • and eg, https://raw.githubusercontent.com/srsudar/eg/master/eg/examples/ls.md

In command line interface pages case they categorized the commands into different directories like commons, linux at so on, so not all commands in the same path, but I think that we can handle this when we start in the implementation

[0x61nas]

Or we can give the user an option to clone the pages repositories and use them offline if he prefers that (I prefer this personally)

[orhun]

• we have to take the nature of the project into consideration. we just take the command from the user and display the results based on that, we don't want to let the user search in the commands or do anything else. so 'cause of that, I think we don't need to have kb and navi as an option.

Fair point I would say. That would over complicate the usage of halp.

• I think that we really don't want to depend on other tools (especially if those tools are written with Python). so we have to find a way to get "help information" without the need to use the original tool. fortunately, the cheat and command line interface pages and eg databases are just regular markdown files hosted on GitHub so we can use roughly the same cheat.sh implementation and just make an HTTP request with the file name to the raw.githubusercontent.com

• For example if we want to get the ls help page from command line interface pages database we just have to make an HTTP request for https://raw.githubusercontent.com/command-line-interface-pages/cli-pages/main/common/ls.clip

• and the same for cheat, https://raw.githubusercontent.com/cheat/cheatsheets/master/ls

• and eg, https://raw.githubusercontent.com/srsudar/eg/master/eg/examples/ls.md

In command line interface pages case they categorized the commands into different directories like commons, linux at so on, so not all commands in the same path, but I think that we can handle this when we start in the implementation

Hmm, I'm not sure that would improve the tool. Is there any extra useful information on those pages that is not already provided by the man page or the cheatsheet?

Or we can give the user an option to clone the pages repositories and use them offline if he prefers that (I prefer this personally)

I think that approach is also going to complicate the usage. However, we can gate it behind a feature flag and use the HTTP request if that feature is not enabled. It can be called "offline-mode" or something similar I reckon. My preference is to avoid using the filesystem so I would disable this feature as default.

[0x61nas]

Hmm, I'm not sure that would improve the tool. Is there any extra useful information on those pages that is not already provided by the man page or the cheatsheet?

Not really, I think the only difference between them is the present way and the information order, at the end of the day the command is the same, but in eg case it's focusing on the examples of command usage

I think that approach is also going to complicate the usage.

I actually agree with that

we can gate it behind a feature flag and use the HTTP request if that feature is not enabled. It can be called "offline-mode" or something similar I reckon. My preference is to avoid using the filesystem so I would disable this feature as default.

Fair point, but that'll add an overhead to the release process 'cause we'll need to ship another package with this feature enabled