3 ms·

The problem with a lot of these tools is that they fight with the shell to provide the UX enhancements (the comments in this thread are littered with people com

The problem with a lot of these tools is that they fight with the shell to provide the UX enhancements (the comments in this thread are littered with people commenting that this new terminal breaks basic feature X, Y or Z. Really what they should be doing is working with the existing command line primitives as a hook for their UX enhancements. I know those existing primitives are 50 years old and suck in a great many ways. But the alternative is having a terminal that only works some of the time. This is field I'm actively experimenting in too. And have already had some degree of success despite the project being only a couple of months old: https://github.com/lmorg/mxtty https://github.com/lmorg/mxtty My point is this: any refinements to the terminal interface shouldn't break support for terminal applications. But all to often (this term included) form is now prioritised over function.

noergl 3y ago
100%. What ppl often mixup is shell responsibility and the terminal itself. They are not really to blame for that, because their interactive terminal usage is mostly at a shell prompt. Idk how they implemented things here, prolly by sidechanneling information to/from the terminal widget. Which is bad, they'd better use in-band terminal sequences for that, so the ecosystem of TEs and cmdline apps can eval the sequences and incorparate them, where they are useful (like the prompt marking OSC sequences...)
cassianoleal 3y ago
I'll keep an eye on your project. Are you planning to support tmux control mode like iTerm2 does?
- hnlmorg 3y ago
  I'm not planning on supporting split panes (though I'm sure that feature will eventually be written), instead relying on multiplexers like tmux to fill that gap for the time being. I don't really know enough about tmux's control mode to understand how I might integrate it but I, personally, didn't like iTerm2's integration much so if I did interface with tmux at a lower level then it might look somewhat different to iTerm2. That all said, at this point in time I'm not discounting any ideas.
  - cassianoleal 3y ago
    Huh, ok. Split panes are one of the killer features of iTerm2 IMO, and also one of the reasons why tmux control mode is so great on it. :) To each their own though, so if it doesn't work for you, then it doesn't!

noergl 3y ago

100%. What ppl often mixup is shell responsibility and the terminal itself. They are not really to blame for that, because their interactive terminal usage is mostly at a shell prompt. Idk how they implemented things here, prolly by sidechanneling information to/from the terminal widget. Which is bad, they'd better use in-band terminal sequences for that, so the ecosystem of TEs and cmdline apps can eval the sequences and incorparate them, where they are useful (like the prompt marking OSC sequences...)

cassianoleal 3y ago

I'll keep an eye on your project. Are you planning to support tmux control mode like iTerm2 does?

hnlmorg 3y ago
I'm not planning on supporting split panes (though I'm sure that feature will eventually be written), instead relying on multiplexers like tmux to fill that gap for the time being. I don't really know enough about tmux's control mode to understand how I might integrate it but I, personally, didn't like iTerm2's integration much so if I did interface with tmux at a lower level then it might look somewhat different to iTerm2. That all said, at this point in time I'm not discounting any ideas.
- cassianoleal 3y ago
  Huh, ok. Split panes are one of the killer features of iTerm2 IMO, and also one of the reasons why tmux control mode is so great on it. :) To each their own though, so if it doesn't work for you, then it doesn't!