Alternative output format for cheat -l

[zeitchef]

Is your feature request related to a problem? Please describe.
I prefer to keep my shell/text editor rather narrow and to the side. The problem is when listing all my available cheatsheets, the shell output is rather cramped and hard to read. In addition, I've created sub-folders inside my personal directory to scope cheatsheets further, it would be much more readable to be able to list cheatsheets by scope.

Describe the solution you'd like
I'd like to propose an alternative format for the cheat -l command.

css
  bem               css, webdevelopment
  selectors         css, webdevelopment
  transition        animation, css, webdevelopment

js
  array             array, datasctructure, javascript
  fetch             api, http, javascript, webdevelopment

This way, output is much more readable and friendlier to the narrower shell users.

Describe alternatives you've considered
An alternative to this approach would be to remove the file: output from cheat -l. It's rare that I'm interested in the exact filepath of the cheatsheet (since I've scoped them, I know basically where they are). In the case that I would like to find the filepath, a cheat <cheatsheet> --info command could be useful.

Additional context
This is my current output:

Rails 6 recently added something similar for its rails routes command. This was notoriously messy output. The addition of an --expanded flag outputs much more streamlined.

Rails 6 shows routes in expanded format - BigBinary

[exploide]

Concerning your tree-like proposal, please not that this has certain drawbacks. Entries in the title column can be copied to cheat <sheet> to display the actual content. This is no longer true when transforming the output as shown above. This is especially important for autocomplete scripts (see https://github.com/cheat/cheat/tree/master/scripts) which parse this output.

But I second your other approach. The file path does not look really useful to me, too.

[chrisallenlane]

Hi, @zeitchef. Thanks for the thoughtful and thorough feature-request.

Regarding the cheat -l output: I agree it's a bit gross right now. Having used cheat@v3 for a little while now, I'm almost wondering if this functionality should just be broken out into two commands, something along the lines of:

1. cheat -l : list cheatsheets in human-readable format
2. cheat -f: list the names and filenames/paths of all cheatsheets

I'm reluctant to add clutter to the interface, but I'm starting to think that these should be treated as two fundamentally different operations, rather than one, as they are now.

Regarding your proposed "expanded" or "tree" view of the cheatsheets:

Let me think about that for a bit. I see where you're coming from, and I see how that could be useful.

Personally, I'm always going to want to view this information per-line, and like @exploide astutely observed, that format is necessary for scripting. That said, I'm not opposed to adding an additional display format. I just need to think a bit about how to best structure the interfaces.

Unfortunately, I probably won't get around to making this change for a little while. I have a few higher-priority items in the queue, and there's a chance I'm going to want to make some backwards-incompatible changes when I make this change. (And I want to think long and hard before releasing a backwards-incompatible cheat@v4, because backwards-incompatible changes are always a headache for everyone.)

Regarding your immediate problem, though - here's a gross workaround that might ease the pain a little bit in the short-term:

Define this function somewhere, and source it:

function cheat-l () {
  cheat -l $* | awk '{ print $1 " " $3 }' | column -t
}

That won't change the behavior of cheat -l, but it will create a cheat-l function that truncates the file path data that you don't want. This function will also work as expected with other flags, like: cheat-l -p personal -t ruby

That doesn't give you the expanded/tree view you proposed, but it will at least resolve the obnoxious line-wrapping we see in your screenshot there.

Feel free to share feedback on any of the above. Thanks.