Hacker News Reader

Comment by Florin_Andrei | Hacker News Reader

> and scrollback are unnecessary

Um... that's kind of a deal breaker to me. Really no scrollback at all?

Just to present an alternate opinion here: I haven't used my terminal's scrollback on purpose in 5+ years now, and it's fine. To me, Alacritty's trade off is perfectly acceptable, and even desirable.

As far as I can tell, using Tmux's scrollback instead has no downsides of note, but some _very_ significant upsides. For example, (1) shared buffer between terminal windows, and (2) copy/paste modes that are usable with Vim shortcuts.

Hm. So, for that to work, I'd basically have to forever hardcode the terminal to launch tmux every single time. Basically, this new terminal + tmux = the old terminal behavior.

I'm not saying this is necessarily a bad thing (haven't tried it), I'm just saying this is the way to get my scrollback... uh... back.

Might as well ship the terminal with tmux as a hard dependency and launch a tmux child process by default.

> Hm. So, for that to work, I'd basically have to forever hardcode the terminal to launch tmux every single time.

Yeah, but it's not as bad as it sounds once you "move down a layer" and treat Tmux like your terminal manager rather than your terminal. When I need to a new shell, I don't open a new terminal window; instead I open a new Tmux "window" (the spiritual equivalent to a tab) and do the work there. I keep the same two terminal windows open with nested Tmux sessions for months at a time. By extension, opening new Tmux sessions is also an extremely rare event because the ones I already have are persistent.

> Might as well ship the terminal with tmux as a hard dependency and launch a tmux child process by default.

I think it's still nice to leave some room for customization here. Screen is still a pretty good Tmux alternative for example (in fact, five years ago you would have said that Tmux was a screen alternative rather than vice versa), and some people might prefer to use that instead.

In a tmux workflow, you're generally not spawning that many new terminal windows, instead you ^a+c to spawn a new tty within tmux.

Sorry, but I want to keep multiple open sessions to different servers separate, even in tmux.

You can also set tmux as your default shell with chsh. I've been doing this for a while on macOS and have enjoyed it (other than user namespace issues that still drive me crazy)

I actually didn't even notice Alacritty didn't have scrollback until now because I habitually open tmux when launching a terminal.

This definitely is a polarizing design decision, but one I support.

I may be reconsidering this position[0]. If scrolling support can be added in a non-intrusive way behind a feature flag (so it could be completely compiled out), it could potentially have a place in Alacritty.

[0]: https://news.ycombinator.com/item?id=13340369

Sounds great! I totally understand the motivations behind the decision to leave it out, but it's a great candidate for a compile time flag. I would love to throw out gnome-terminal for this!

the use case seems to be using tmux inside the terminal emulator, with tmux you'd use its own scrollback buffer

(edit) from the project's github page in fact

The simplicity goal means that it doesn't have many features like tabs or scroll back as in other terminals. Instead, it is expected that users of Alacritty make use of a terminal multiplexer such as tmux.

Interesting - maybe this (or someone else) could skip the middle-man and just be a cross-platform tmux gui, instead of a terminal emulator.

Not really. After all, the applications inside tmux are ordinary terminal programs that need terminal emulation.

That makes so much sense that I now feel really silly about my suggestion :) Thanks for setting me straight!

The problem with this is using tmux screws with using mouse for selection (since tmux takes over the mouse and does its own selection thing, which usually doesn't do what I want).

This approach also means you can't do anything interesting like what Terminal.app does with detecting prompts, marking them, and letting you jump back to them (or clear history back to them).

This approach could be excused if the terminal actually natively integrated with tmux, thus providing its own gui splits/tabs that represent tmux's panes/windows, but it doesn't sound like it does that.

I just disable tmux's mouse usage by putting "bind m set -g mouse off" into my tmux.conf: tmux is useful enough just with key shortcuts, and I generally dislike terminal programs that use the mouse anyways.

Also, some terminal emulators (iTerm2 on Mac) let you disable mouse grabbing by holding a special key while clicking, maybe Alacritty could implement something like this?

Terminal.app disables mouse mode if you hold the Fn key down (plus it has a ⌘R shortcut to toggle mouse mode on/off).

`mode-mouse off` helps tmux forget about mice.

It's also a deal breaker for me. I use a tiling WM instead of tmux.

That said, I really wanted to build this exact same project at some point, so maybe seems like a feature that could be added in a fork :)

I guess the idea of no scrollback is taken from st [0].

[0] http://st.suckless.org/

There's a patch for that.

http://st.suckless.org/patches/scrollback

Aw damn this is the deal breaker right here. As someone using a tiling window manager, this is pretty useless to me.

They suggest passing that duty off to tmux. Kinda makes sense I guess... though I'd love to have it.

Does tmux interpret mouse scroll events, or is it only keyboard-based?

I know that screen can be configured to do that. I would be surprised if tmux cannot.

It does, but it's not completely reliable for me. Also, you have to configure it to make it actually work.

For example, here's my mouse-related tmux config:

  set -g mouse on
  # enter copy-mode by scrolling, but don't select the pane
  # The usage of #{mouse_any_flag} just forwards mouse events when in a fullscreen app that wants them
  bind -n WheelUpPane if -F -t = "#{mouse_any_flag}" "send-keys -M -t =" "if -F -t = '#{alternate_on}' 'send-keys -t = Up' \"if -F -t = '#{pane_in_mode}' '' 'copy-mode -e -t ='; send-keys -M -t =\""
  bind -n WheelDownPane if -F -t = "#{alternate_on}" "send-keys -t = Down" "send-keys -M -t ="
  
  # Start copy-mode with PageUp
  # For PageDown, if we're not in copy-mode, discard it
  bind -n PageUp if -F "#{alternate_on}" "send-keys PageUp" "copy-mode -eu"
  bind -n PageDown if -F "#{alternate_on}" "send-keys PageDown" "if -F '#{pane_in_mode}' 'send-keys PageDown'"

tmux handles mouse events very well. Scrolling, pane resizing (in tmux and vim), selection work once you add one line in config. For me it works so perfectly that it successfully goes in nested tmux sessions over ssh.

However, some people complain about mouse issues. I would suspect that some terminal emulators are trying way too hard to properly handle mouse events.

Reply on news.ycombinator.com