warpdotdev / warp Goto Github PK

Is your feature request related to a problem? Please describe.
Provisioning a project with the right environment variables is often very difficult. It's unclear which tools or scripts need to be run and what dependencies I need.

Describe the solution you'd like
I'd like for Warp to automatically embed shared env vars and secrets when I cd into the appropriate directory.

Additional context
Technically, two possible ways we could implement this are by integrating with tools like Nix or Docker. We could also investigate building our own format for representing shared environment variables on a per directory/repo basis. Using our precmd/preexec hooks, we could source these environment variables as necessary.

Right now hitting tab with the completions menu open, selects the completion and enters it in the input box.

In typical shells, hitting tab will cycle the options instead.

Curious if the community has a strong preference on:

1. The default behavior
2. Whether this should be a setting

Is your feature request related to a problem? Please describe.
If I resize the Warp window, close the app, and re-launch, it defaults to its preset size.

Describe the solution you'd like
An option to set the default size for newly created windows. For example, setting it to 80x24 would create a new Warp terminal window with 80 columns and 24 lines. The default size is a bit large in my opinion, so I'd love to be able to change it to something a bit smaller.

Describe the bug
You can not close the command palette with escape if a new tab is created while the command palette is open.

To Reproduce
Steps to reproduce the behavior:

1. Open the command palette
2. Create a new tab (cmd + t or by clicking the + button)
3. Try to close command palette with escape key.

Expected behavior
The command palette should close when the escape key is pressed, as it does before creating a new tab.

Desktop (please complete the following information):

• OS Version: macOS 12.0 Beta 3

Additional context
The command palette can still be closed by clicking on one of the commands, just not with escape.

There are several potential parts to this:

1. A richer set of built in themes (right now we just support light and dark mode).
2. A way of building and sharing custom themes.

Please upvote if this is something you're interested in!

Title pretty much says at all.

Right now Warp doesn't support custom fonts. Would be great if it did.

Right now we only support bash over ssh, but we could also support other shells like zsh.

Posting so people can upvote.

Thank you!

Describe the bug
npm tab complete is implemented, but isn't mentioned in the docs. https://docs.warp.dev/features/tab-completions#supported-completions

One feature we are considering is building is a persistent, searchable cloud history.

The idea is that your history would follow you across sessions and computers and be accessible and searchable anywhere, not just by command, but also by other metadata like output, time, user, machine, and more.

Use cases are finding and rerunning old commands, finding old output, sharing them with your team, auditing sessions.

We'd need to be super careful on the privacy side here, and would make this feature opt-in and possibly self-hosted.

Curious though what the community's reaction is. Please upvote / downvote.

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

Describe the bug
There appear to be visual artifacts in a handful of places when moving the terminal from the build-in retina display to an external non-retina display. This was

To Reproduce
Open warp on a non-retina display, inspect edges closely.

Expected behavior
Crispness.

Screenshots
On the Retina display, things look generally fine:

On the external display, the edges look crunchy.

Desktop (please complete the following information):
MacOS 11.2
External display: 3440 x 1440 display

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

Some clis, like htop support recieving mouse input.

Describe the solution you'd like

warp should suport this

Additional context

• https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking
• https://linux.die.net/man/3/getmouse
• https://man7.org/linux/man-pages/man4/console_codes.4.html

Looks like the /System/Library/Frameworks/UserNotifications.framework/Versions/A/UserNotifications dylib isn't there.

Here is the report:

Path:                  /Applications/Warp.app/Contents/MacOS/stable
Identifier:            dev.warp.Warp-Stable
Version:               0.1.0 (20210714.005705)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           stable [89506]
User ID:               501

Date/Time:             2021-07-16 14:40:36.372 -0500
OS Version:            Mac OS X 10.13.6 (17G14042)
Report Version:        12
Anonymous UUID:        EFF49F03-6ED0-347A-6DF5-560AB4793A35

Sleep/Wake UUID:       2A0FC56C-3277-4CD2-B852-474976BF7AE7

Time Awake Since Boot: 300000 seconds
Time Since Wake:       28000 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x1] Library missing

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: /System/Library/Frameworks/UserNotifications.framework/Versions/A/UserNotifications
  Referenced from: /Applications/Warp.app/Contents/MacOS/stable
  Reason: image not found

Binary Images:
       0x1062bb000 -        0x107f82fcf +dev.warp.Warp-Stable (0.1.0 - 20210714.005705) <4A6EA122-961B-3EB9-BEDF-4E509C11AD8A> /Applications/Warp.app/Contents/MacOS/stable
       0x10910a000 -        0x109169ff7 +io.sentry.Sentry (7.0.3 - 7.0.3) <77709E89-C368-3369-9CD7-6408F63CC857> /Applications/Warp.app/Contents/Frameworks/Sentry.framework/Versions/A/Sentry
       0x1123e7000 -        0x112431adf  dyld (551.5) <CB9BFB56-4511-36F1-A546-891FF770C01C> /usr/lib/dyld
    0x7fff4d51c000 -     0x7fff4d9b8fff  com.apple.CoreFoundation (6.9 - 1455.300) <D9D5D50D-5DA3-34B6-8077-DD24315A4B1E> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff51da0000 -     0x7fff51dbaffb  com.apple.MetalKit (1.0 - 98.3) <46B0ECC2-0C3F-3E74-A4E7-0B5D6DF4BEAA> /System/Library/Frameworks/MetalKit.framework/Versions/A/MetalKit
    0x7fff593be000 -     0x7fff596e9fff  com.apple.security (7.0 - 58286.70.19) <E118FC23-2E20-3999-826B-58488049A277> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff73f20000 -     0x7fff74011ff7  libiconv.2.dylib (51.50.1) <7965B866-C75A-3450-9891-0500349F7090> /usr/lib/libiconv.2.dylib
    0x7fff75382000 -     0x7fff75394ffb  libz.1.dylib (70) <47278BDC-596E-3037-B8DA-05FE9D5DBEF6> /usr/lib/libz.1.dylib

Model: MacBookPro6,2, BootROM 99.0.0.0.0, 2 processors, Intel Core i7, 2.66 GHz, 8 GB, SMC 1.58f17
Graphics: Intel HD Graphics, Intel HD Graphics, Built-In
Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1067 MHz, 0x0198, 0x393930353432382D3030352E4130324C4620
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1067 MHz, 0x0198, 0x393930353432382D3030352E4130324C4620
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.106.98.102.30)
Bluetooth: Version 6.0.7f22, 3 services, 27 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: CT500BX100SSD1, 500.11 GB
Serial ATA Device: MATSHITADVD-R   UJ-898
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: Internal Memory Card Reader
USB Device: Apple Internal Keyboard / Trackpad
USB Device: BRCM2070 Hub
USB Device: Bluetooth USB Host Controller
USB Device: USB 2.0 Bus
USB Device: Hub
USB Device: IR Receiver
USB Device: Built-in iSight
Thunderbolt Bus: 

Describe the bug
When using visual mode in vim (v or ctrl-v) in other terminals the selected text is highlighted. In Warp, the selection is not visible.

To Reproduce
Steps to reproduce the behavior:

1. vim
2. i to enter insert mode, then type in a test sentence (eg: The quick brown fox jumps over the lazy dog)
3. [ESC] to exist insert mode and then v to enter visual mode -- 3b to go back three words

Expected behavior
Expected the lazy dog to be visually highlighted, but there is no visual evidence of the selection in visual mode. To confirm that the text was actually selected, d to delete the selection.

Screenshots

Desktop (please complete the following information):

• OS Version: MacOS Catalina 10.15.6

Describe the bug
The bug is basically about the settings menu not minimizing when clicked on the settings icon.

To Reproduce
Steps to reproduce the behavior:

1. Click on the settings icon i.e. three dots.
2. Click on the icon again.
3. The popup menu does not close.

Expected behavior
The popup menu should close when clicked on the icon.

Screenshots

Desktop (please complete the following information):

• OS Version: MacOS Mojave

Additional context
Add any other context about the problem here.

If warp supports windows splitting and terminal multiplexing, it would be nice to have a keymapping a-la tmux. In tmux it is ctrl-b by default, but most people switch it to ctrl-s or ctrl-a.

Problem: Ergonomics

I quite like warp's innovation of splitting/stickying the input / current prompt separate from the scrollback buffer – allowing thus a command to be assembled from info one may need to be scrolled back to without losing sight of it

The current implementation has a nice analogy to the interface of e.g. slack, and is probably (though not definitely) the correct default. ( It also is correct almost certainly for use cases of Warp on the ~Jupyter model, though then editable cells will I guess end up wherever as one scrolls)

It is, however, worse ergonomically, at least for a full screen-height terminal. As is stands I am often turning my neck down, and it would be preferable to keep my eye line toward the top of the screeen when writing commands

borrowing/modifying diagram from https://www.gvsu.edu/officeergonomics/computer-monitor-8.htm to somewhat belabor/exaggerate the point:

(this bothers me enough that using other terminals I somewhat compulsively run clear (or ^L) even when it would likely be useful to keep output on the screen for other reasons)

Solution: Be more like a modern browser omnibar

Continue the logic (I presume you followed) in assigning ⌘L to Focus terminal Input, and (offer the toggleable UX option of) treat(ing) the input buffer as more akin to the URL bar in a browser:

➕ Advantages

In addition to the ergonomics, this offers the advantages of:

• you can grow down instead of growing up; when adding multi-line inputs or showing options for history & completions, you cover longest-ago rather than most-recent output, which – absent scrolling – seems preferable.

  The history pop-up is thus more familiar UX resembling, again, like a web browser– though it will follow that you need to swap the recency semantics of ↓ and ↑ compared to shell defaults.

• warp generally presenting more familiarly like other terminals when freshly opened / empty:
  
  but of course if you include keyboard shortcuts et al as currently it will still be easily differentiable / distinct

• this pinning possibly lends itself more naturally to splits – as going by the existing tab design (as well as traditional window chroming), metadata / title is gonna be at the top, and is useful to keep that in close proximity to the command line if people are switching back and forth

  For a horizontal split you could also conceivably pin top split's input to top and bottom split's input to bottom – which might create a better visual separation (?, it might just be confusing though)

➖ The New Problem / Opportunity

Obviously, if you do this, you lose the nice current natural transition to a yellow-border-cell for a long-running command and scroll-up to next prompt when command is done.

Unless you went all-in on reversing the history direction (on the block level; which honestly wouldn't be crazy - imo, but would certainly take some getting use do), you also have lost a natural way to hide the prompt while the last command is running

My answer to this problem is: don't hide it.

Either:

1. leave it in place at the top as a frozen (set of) commands akin to the current input portion of an I/O cell

   this offers the advantage of leaving it visible even if/after the command has output more than a single screen of text

   (and indeed you can leave it in place over a curses/TUI style app, conveniently offering thus a what was the invoking command line - and/or the current one you can refetch it if the program is allowed to change it (like /proc/n/cmdline), or you could tree-it-down like the iterm status bar:

   

   ) AND/OR (or being do 1, but 2 on explicit focus - again kinda like how browsers do current vs being-type URL)

2. leave an interactive buffer in place there, allowing people to potentially formulate their next command while their previous potentially-long-running command is still going. There is really no harm, nor likely much additional work (other than being prepared to update prompt when its ready?), in doing this until such as time as the command is actually submitted for exec. At that point I see at least three options for how to treat it:

   1. Just refuse with a warning bell, symbol, or other indication that you can draft-but-not-submit while another command is running (the first time a user does this its probably worth an alert modal explaining in more detail)
   2. (offer to) run it in a new tab (or split / pane once those are implemented). If you wanted to go extra on this, you could try to (or secretly have already, for every command? - one always left over ) clone(d/ forked) the underlying shell and thus bring along all the relevant environment variables, working directory, etc. But in most cases, I think spawning a new shell off dotfiles would likely be good enough
   3. Leaning harder on the browser behavior analog, doing this could SIGINT (escalating to SIGKILL, or not) the running process and start the new one soon as the prompt is seen

Either of these things could, of course, also be done (and I think would be useful) with the current bottom-stuck input pane, but again - I think they make more UX sense with the outside context people have from using a web browser (other than, you know, qutebrowser, etc users where the bottom one makes equal sense).

There is still gonna be some awkwardness to output scrolling up from the bottom for a command run at the top, but

1. I think the yellow-border for running, red-border for failures is clean enough to make it make sense—though it may behoove one to add also a (transient) green (or warp-cyan) type for (only last) successfully run command
2. or you could switch up behavior so that a command on start gets a clear full-height buffer below with output beginning at the top and grows down til scroll, potentially compacting (re-introducing most recent previous scrollback) when done if it never fills the screen
3. or as I parenthetically said above, I don't think it would be unreasonable (though ~bold) to fully swap up the history direction (on a block/execution level, presumably leave it as is in output of commands) so that new commands' blocks are inserted on top (initially as a single line, growing down until scroll) with older commands falling off the bottom and being scrolled down to to (also with a swap of ⌘↑ and ⌘↓ vs the present)

With this design (with menus unfurling down rather than up as a rule) it might also make sense to unify the terminal input and command palate (possibly, like vscode having, an initial > indirect into pallete commands, since it hardly makes since imo to redirect stdin before a command) but ¯\(ツ)/¯

(Partially) Extracted from (previous draft) of #16 (comment) :

Currently the tab completion algorithm takes a fairly conservative approach to offering completions for file names. While some commands' (cd, ls, file, stat, somewhat surprisingly tar, … ) completions are configured to assume a file may come at an initial (or any post-flag) position and offer suggestions accordingly, others (mkdir, vi - at least with my shell config, …) play it safe and wait to see an explicit -- before any file completions are offered.

This is the case even when Tab is proceeded by ./, ../ or /

I suggest there are at least 3 heuristic approaches that might be reasonable:

Assuming paths should follow on:

1. ^\.{0,2}/ or indeed ^[./] – this would catch all explicitly rooted paths (at the cost of ignoring or requiring special handling for the rarely-used DOS-style /? flag; and having some false positives)
2. ^[^-+] except where there is an explicit expectation of sub-commands for e.g. git, or stuff like dd's k=v style, etc. This is likely how many commands currently behave
3. the latter but as part of a state machine that gets more eager when/if someone typed (or accepted suggestion(s) for) {-, -- or +} style flag(s) followed by a space and not then another - or +

The logic of 3 would aim so that:

• flags/subcommands are always offered on first bare (space-)tab and possibly each subsequent til no suggestion is selected from offered completions

  [currently they are not. Generally, for both e.g. ls and mkdir flag completions are offered only after a -Tab, and (for those like mkdir) nothing is offered on bare Tab]

• once the flag suggestions have been dismissed (and/or space is pressed, as accepting a suggestion with either tab or enter does not currently add a trailing space*) assume a subsequent tab should offer completions from current working directory

*That accepting doesn't add a trailing space is perhaps a bug as it stands, because additional Tab seems to be ignored rather than offering additional flags to add to an ~option clump (as does, for example, /usr/share/zsh/5.8/functions/_ls /usr/share/zsh/5.8/functions/_mkdir ). As such one is gonna have to type Space-Tab even if one does want more flag suggestions (unless there is some way to multi-select?)

If it were the default behavior, however, one would likely still want to suppress for Java/Go-std-lib -key=val and POSIX(?) --key=val style flags

Would love the ability to delete a block via the menu-bar here:

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

Describe the solution you'd like
The Control + click should trigger a right-click, especially in a block based on macOS standards.

Additional context
https://support.apple.com/en-ca/guide/mac-help/mh35853/mac

Right now we only support hard-coded bindings. We'd like to change this to support custom key maps. Posting here as a tracking issue to get a sense of importance from the community.

Please upvote if you'd like this.

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

Describe the solution you'd like
It would be nice if the path for each open tab (and the positions of each tab) were preserved on an update or when closing Warp altogether.

Additional context
What currently happens: All your tabs are closed and if you were working in multiple different paths, you have to open them all up again

Describe the bug
Hovering over URLs should make the cursor a pointer.

To Reproduce
Steps to reproduce the behavior:

1. Hover over a URL

Expected behavior
Hovering over URLs should make the cursor a pointer.

Desktop (please complete the following information):

• OS Version: macOS 10.15.7

Additional context

Maybe expand the scope of this ticket to change to cursor according to the context.

• clickable -> pointer
• command is running -> loading cursor when hovered over block maybe?
• any other context you can think of :)

Is your feature request related to a problem? Please describe.
Sometimes you want to view shell sessions simultaneously. Two ways I typically go about this are via iTerm's split-pane feature or via tmux. Unfortunately, I lose some of the benefits baked into Warp when using tmux.

Describe the solution you'd like
Any sort of solution that addresses this use case! A several come to mind: some sort of tmux integration, tmux alternative, or native support for split screen functionality

Describe the bug
I was able to issue a few commands, then cmd + up before the first command was issued. It seems to allow for two blocks before the top-most command (I had to issue two cmd + down to get the selected block back on-screen).

To Reproduce

1. Open new tab
2. Send a few commands (I issued a couple clear commands).
3. cmd + up repeatedly.

Expected behavior
It stops at the top-most block.

Desktop (please complete the following information):
MacOS 11.2.3

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

Describe the solution you'd like
I would like to have the ability to delete the block, the reason is mostly declutering.

Is your feature request related to a problem? Please describe.
Keep the context of the current working directory + other info while sharing & copying.

Describe the solution you'd like

1. Allow selecting the prompt text like the rest of the text
2. Additional option in menu (i.e. Copy Command, Output and Prompt) to copy everything.
3. A checkbox to share the prompt when sharing a block.

Additional context
Requested by @bznana from Discord.

Right now, you have to click the input line itself to focus the input. Ideally, the entire lower area would be clickable (including the path, and padding around the input).

Ideally, it'd also present the macos text selection cursor as well, so that it's clear that clicking will focus the input.

Are there any plans to open source any of the layers of the GUI framework described in this article any time soon?

Describe the bug

If a command starts with /, autocomplete doesn't work

To Reproduce
Steps to reproduce the behavior:

Type /usr/bi

Press Tab

Expected behavior

Autocompletes to /usr/bin/

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• MacOS 10.15.7

Additional context
Add any other context about the problem here.

Describe the bug
In PostgreSQL CLI, was trying to navigate in a long query I had written but was not able to achieve it. it was misbehaving.

To Reproduce
Steps to reproduce the behaviour:
https://www.loom.com/share/651c57af28e841a0bf16a9259e65e592

Expected behaviour

• Was expecting to move to the left one wor on pressing the 'option+left' arrow, but navigation went in the opposite direction.
• Was expecting to move to the beginning of the query when pressing 'Command+left arrow' but something else happens

Desktop (please complete the following information):

• OS Version: [e.g. MacOS 11.3.1]

Describe the bug
Closing any tab with a process that's still controlling the terminal causes the entire Warp app to quit.

To Reproduce
Steps to reproduce the behavior:

1. Open a new tab
2. Run a program that keeps control of the terminal (ex: man ls / vi / etc)
3. Close the tab through either the X button or Cmd+W
4. The entire Warp app quits

Expected behavior
Expect all the tab's children to be terminated, but Warp to stay running.

Bonus: might be worth considering an "undo close" grace period like iTerm (https://gitlab.com/gnachman/iterm2/-/issues/2877#note_335567160), though that'd be a separate FR.

Screenshots
N/A

Desktop (please complete the following information):

• OS Version: macOS 10.15.7

Additional context
N/A

Describe the bug

Function keys are not passed through.

To Reproduce

1. Open htop
2. Press f6 (or fn + f6)

Expected behavior

htop recieves key press, and open "SortBy" view

Actual Behavior

Nothing happens.

The proposed feature would allow for special rendering of structured block types (e.g. json, csv, markdown).

Exact implementation tbd. but I'm interested in whether something like this is appealing to the community.

Here's a sense of what it might look like:

Please upvote if you'd like this.

Is your feature request related to a problem? Please describe.
Most shells currently only support searching through your history by the command. This is frustrating because I can't search by the output, the directory, timestamp, the box, or any other metadata. Additionally, the default history file is too small, I often try to search for commands that I ran a few months ago only to find they were flushed from my history.

Describe the solution you'd like
I would like to be able to be able to have a UI to infinitely search my terminal history. To start, I'd like to be able to search by:

• Command
• Output
• Timestamp
• Exit code
• Directory
• Box (e.g a specific remote box or a set of remote boxes)

Additional context
Once I find a command that matches my search result, I'd like to be able to find commands that I ran before and after in that specific session where the command was executed. Technically, we could do this by indexing Blocks in a local sqllite database or send them to our server and index them in the cloud.

Describe the solution you'd like
I most terminals I am used to using ctrl + L to clear the terminal window. Hyper supports the clear command, but not the keyboard shortcut. I would be cool if ctrl + L was supported.

Additional context
N/A

Describe the bug
When I open multiple tabs, typing exit on the terminal prompt crashes Warp.

To Reproduce
Steps to reproduce the behavior:

1. Open Warp.
2. Open a new tab.
3. In either tab, type exit at the prompt.

Expected behavior
When I type exit, I expect only the current tab to close.

System info:

• OS: MacOS 11.4
• Shell: zsh
• Warp version: 0.1.0

Additional information
I'm happy to send over the full stack trace if needed.

There are various font rendering artifacts that make the text look suboptimal.

E.g. the tops of letters are sometimes cropped:

Sometimes characters are misaligned from the baseline at different zoom levels.

Would really love the ability to set custom background color and text fonts...I'm kind of in-love with the green background I've grown used to on my terminal + custom fonts:

Describe the bug
Does not respect setopt histignorespace in zsh.

To Reproduce

1. Set setopt histignorespace in your zsh config and reload the shell
2. Execute a command preceded by a space
3. Execute a command not preceded by a space

If you arrow up or search with ctrl-r, the command that was preceded by a space is visible (but shouldn't be).

Expected behavior
The command preceded by a space should not show up when hitting the up arrow or when doing ctrl-r to search the history.

Describe the bug
In neovim, the status bar at the bottom (as seen in the screenshot) is not at the bottom of the terminal window.

To Reproduce
Steps to reproduce the behavior:

1. So far, simply running Neovim seems to trigger it nearly every time.

Expected behavior
The status bar should be at the very bottom of the window, as seen in the second screenshot (how it looks in kitty).

Screenshots
The first screenshot is warp, the second is what is expected.

Desktop (please complete the following information):

• OS Version: MacOS 12.0 Beta 2

Is your feature request related to a problem? Please describe.
The terminal is inherently a single-player experience, which is frustrating if you want to pair with someone in a live session. This can be useful for cases like dev-ops where multiple people could be debugging something in a single session at the same time.

Describe the solution you'd like
I would like to be able to join a session via a link and richly interact with it like it was a session running in my native terminal. I'd also like the session to be optionally persisted after it ends so there can be an audit history of what happened in the session that is easily sharable.

Additional context
Technically we would start by implementing Warp in the browser by compiling Warp to WASM. We'd also need to build the correct architecture (likely through websockets) so that we can broadcast changes from the native app to the browser and vice-versa.

Is your feature request related to a problem? Please describe.
I love the idea but it was confusing to have as the default new tab behaviour, personally I'd probably want to put it behind a custom hotkey instead and keep Cmd+T as it is.

Describe the solution you'd like
Would be cool if this were configurable / could be disabled eventually.

Is your feature request related to a problem? Please describe.
I normally set my terminal to have a semi-transparent background, to be able to see windows beneath it. This allows me to see a website with an article or a tutorial in the background while still being able to work in a terminal. It's much easier than switching between windows.

Describe the solution you'd like
Add the ability to set background transparency.

Additional context
I usually work just on my laptop, no external monitors.

Describe the bug
The window offset for the top of the window covers the first line of text. This isn't usually an issue using the Warp as normal, but attaching to a tmux session in a remote terminal this creates a bit of a UX issue. See attached screenshot.

To Reproduce
Steps to reproduce the behavior:

1. Create a tmux session in another terminal window
2. In warp, type tmux attach -d
3. See screenshot below

Expected behavior
I would expect the viewport for terminal window not be obstructed by the tab bar.

Screenshots

• See top tmux pane. It is covered by the tab bar.
  Desktop (please complete the following information):

• MacOS 11.4

Additional context
This seems like it may only be an issue when you are not using the native Warp experience and are using a remote session

To use any terminal app as a daily-driver, it has to be readable for each user. Along with the issue already filed for custom fonts (and, presumably, custom font sizes), being able to set the background color is necessary to make the terminal feel like home.

Describe the bug
When the command palette is open and you create a new tab with the keyboard shortcut it remains stuck on the screen.

To Reproduce
Steps to reproduce the behavior:

1. Start warp
2. Type CMD+P to open the command palette
3. Type CMD+T to open a new tab
4. Command palette is now stuck on the screen. Pressing CMD+P again does not put you back in the command palette.

Expected behavior
The command palette should close when opening a new tab.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• MacOS 11.4

Additional context
I have been able to close the palette by switching back and forth between tabs randomly. It hasn't required me to close the app to fix, but is a bit more than a minor annoyance to get rid of.

Right now blocks and input don't work within tmux sessions.

The most likely way we would support this is through tmux's control mode feature, like iTerm, where it would integrate with split panes.

https://github.com/tmux/tmux/wiki/Control-Mode

Posting here to get a sense of how useful this would be. Please give it a thumbs up if you'd like it.

https://sw.kovidgoyal.net/kitty/graphics-protocol/

Is your feature request related to a problem? Please describe.
When I clear my terminal, I want it to be visually free from clutter. I completely understand why the current visualization of clear is the way that it is, it just feels a little wrong.

Describe the solution you'd like
I'm not completely sure, but the snackbar at the top feels odd.