Allow fold / excerpting of blocks and previous individual commands

[donaldguy]

EDIT 7/29, 7pm Eastern:

A separate open issue describing hide/delete, and potentially collapse, is (more) active as #50. If desired (lmk, warp folx; or just use your edit powers directly), I am happy to reduce scope of this feature request / Issue to just the excerpting bits.

on Discord, @s278gupt, shared some mock-ups of

Collapsing:

And

Deleting:

---

This seems like an obvious enough extension of the current model so as to likely already be on the roadmap, but better safe than sorry:

The separation and scroll of individual commands on a per-block basis is great for being able to quickly get back-past an excessive length output of a command to useful output further back – but moreso when that long output is at the end of a session's recent-history than if its in the middle

sometimes, e.g. when debugging an operational command, there can be some chatty commands you ran that were either largely or, it turns out, entirely irrelevant - but there is info further back in the history you still want to get/refer to. Currently (in Warp and other shells) your best bet is to either just copy and paste those commands output to a text file or to run them again so they are further down in history.

Warp's copy and paste functionality make the former easier than before, and share offers another maybe quicker option (open the command in a browser tab, paste link into slack, etc)

Nevertheless, I think it would be neat if one could more pro-actively curate the scrollback down to useful info:

1. In the simplest case, this would be allowing (permanent) removal of a block for an irrelevant command.
2. In the nearly as simple case, this would be collapsing the output leaving only a line or two (either just the input or input,output-truncated… ) when the block is seen with a button to toggle back to full output (either leaving it in memory-just-out-of-view so that's instant, or quickly async loading it from an indexed cache)
3. Something neater and potentially more useful, would be to let users highlight (an/) excerpt(s) of the output (presumably the information expected to be most useful later) - and then trim down to just that (and some level of surrounding context) – again either irrevocably-like-(1.) (replacing the previous full output in the scrollback buffer), or as primarily a display/focus-like-(2.) showing the excerpt but offering the option to unfurl back to full output (presumably with the excerpts still highlighted in some way)

I can imagine option (3.) being useful both actively as one is doing some work (here I imagine too some ability to bookmark-or-pin-to-float), and retroactively (along with other annotation facilities) to turn a shell session into (part of) ~a postmortem report

[donaldguy]

This functionality would compliment / be complimented by #1

With both there might be some utility of offering the option to re-insert a previous command at the end of the history (without actually re-running and promenantly linking back to the original — or possibly even actually rerunning but still linking, offering a diff of output?)

if one did that, it would be potentially useful to be able to (re)excerpt the same command different ways: e.g. highlighting (simultaneous) detection of problems (or say, a problem requiring intervention on several hosts/instances of a service) that were dealt with in serial

[elviskahoro]

from #291 @JosephTLyons

I suppose that does bring up the question of "what happens when text being searched for shows up within a collapsed cell?" Does the cell expand while Warp is in the "search" state, and collapse again when the "search" state is exited? I'm not sure.

Alternatively, maybe the user doesn't care about output from the collapsed cells being included within the search, so maybe when a collapsed cell has a match in it, the collapsed cell is just highlighted, and it is up to the user to manually open the ones they care about and re-collapse them, if they want.

[elviskahoro]

from #291 @zheng

Find is a good point! I imagine it visually indicating that the option is in the collapsed block, and leaving it up to the user to un-collapse. I think expanding and re-collapsing may be jarring UI-wise

[elviskahoro]

from #291 @elviskahoro What are some of the options for the visual indicator?

In terms of passive indicators, I'm only able to come up with changing the divider color and maybe the collapse caret color to yellow (in the case of dark theme) / whatever the highlight hex code is.

For the find dialog, I'm wondering if there could be a checkbox or icons (like in this picture from sublime) where the developer could select whether they wanted the blocks to expand when navigating to the next highlight (if the highlight is in a collapsed block) via find next and find prev.

[elviskahoro]

from #291 @elviskahoro

A second thing that just came to mind is including the number of occurrences for that particular block as an icon next to the caret. My initial instinct is to the right of the caret, but that wouldn't scale well for large numbers like 3462 vs 3. No numeric would imply there's just one occurrence. So the first highlighted block would have 3 occurrences of whatever was searched, and the block after would only have 1.

Excuse my horrendous drawing skills.

[elviskahoro]

from #291 @elviskahoro

Can also experiment with a solid line, dotted line, dashed line, gradient line? I wonder if using a dashed line would open up some possibilities in term of communicating more information. See picture and explanation below:

In the first block we have three dashed lines but the middle one is colored blue. In the second block we have three dashed lines but they're all yellow. Maybe this type of variation could be leveraged to signal an extra piece of information to the developer? Maybe the blue on is the currently selected block? We can brainstorm other things as well that are good to communicate in a first glance.

Flashing / fading in and out can also be another kind of indicator.

[elviskahoro]

from #291 @zheng

I imagined it as highlights in the scrollbar - but its not always visible!

Thanks for the ideas! Shikhiu will be able to draw something great! :D

[elviskahoro]

from #291 @elviskahoro

Support (collapse all except current, specific ones, etc)

[alexander-koshuta]

this was filed in July 2021, how difficult it is to make blocks at least collapsable, you already received a bunch of similar requests.

[maebert]

I spent half an hour digging through docs and expected this to be a built-in feature, the same way that ie. Jupyter notebooks allow you to toggle a block's output. +1 on this request!

[dannyneira]

Thanks, Folks who have 👍 and commented on this request. I believe we've begun to investigate the possibility of hiding/collapsing blocks as it's been a common request. No official ETA on any launch, but we'll post any additional updates on this thread.

We appreciate your patience and interest in Warp!

[c00kiemon5ter]

This is super useful to cleanup the screen from intermediate commands with noisy output.

I use it regularly with the Apple Terminal (cmd+L).

[adaboese]

Came looking for the same feature

[repsejnworb]

Shameless new comment 👍 to this. Only gripe I've run into. Great software!

[wdanilo]

This might not be directly related, but I did not find any issue about it – would it also be possible to support folding of some output, like console.group from node.js programs?

[skaven81]

I too was assuming this would be available right from the start. A workaround can be to use the filter feature and search for something that doesn't exist (just type some gibberish) and the block will collapse. You can reset the filter to "expand" the block again. But it would be way better to have native support for this.

It would also be great to have an option so that blocks automatically collapse if they exceed some defined line count that can be adjusted in the settings. And/or to have blocks auto-collapse once they are a certain number of items back in the history, so it's easier to scroll back in your history.

[ADTC]

Wish for older blocks to auto-collapse (to their sticky header) as they move out of the current viewport when I create new blocks. So that when I scroll up, I see a bunch of collapsed blocks, and I only need to open the block that I'm interested in (which would stay open permanently even when I scroll back down).

[jckw]

I just contributed to the crowdfunded bounty on this issue.

Each contribution to this bounty has an expiry time and will be auto-refunded to the contributor if the issue is not solved before then.

This is an 80% PR author bounty, with 80% of the reward going to the merged PR author.