Re:JetBrains IDE new Terminal Interface
by cassianoleal on Thursday February 22, 2024 @12:37PM
(#39470378)
I'll keep an eye on your project. Are you planning to support tmux control mode like iTerm2 does?
Re:JetBrains IDE new Terminal Interface
by hnlmorg on Thursday February 22, 2024 @01:51PM
(#39471361)
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.
Re:JetBrains IDE new Terminal Interface
by cassianoleal on Friday February 23, 2024 @03:55PM
(#39485979)
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!
Re:JetBrains IDE new Terminal Interface
by noergl on Thursday February 22, 2024 @09:33AM
(#39467627)
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...)
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
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.