ttyphoon

nor is it `defer/panic`, these are all just ugly syntax that doesn't actually slow you down. My biggest complaint is the lack of creator and destructor methods for structs. the `NewClass`-style way of initialising types is an ugly workaround and it constantly requires checking if libraries require manual initilisation before use. Not a massive time sink but it's not something the IDE can easily hint to you so you do get pulled from your flow to then either Google that library or check what `New...` functions are defined in the IDEs syntax completion. Either way, it's a distraction. The lack of a destructor, though, does really show up all the other weaknesses in Go. It then makes `defer` so much more important than it otherwise should be. It means the language then needs runtime hacks for you to add your own dereference hooks[0][1] (this is a problem I run into often with CGO where I do need to deallocate, for example, texture data from the GPU). And it means you need to check each struct to see if it includes a `Close()` method. I've heard the argument against destructors is that they don't catch errors. But the counterargument to that is the `defer x.Close()` idiom, where errors are ignored anyway. I think that change, and tuples too so `err` doesn't always have to be its own variable, would transform Go significantly into something that feels just as ergonomic as it is simple to learn, and without harming the readability of Go code. [0] https://medium.com/@ksandeeptech07/improved-finalizers-in-go... [1] eg https://github.com/lmorg/ttyphoon/blob/main/window/backend/r...

don't think Murex supports job control (due to processes being marked non-traditionally). You can see higher up in that file above where I need to force Murex to take ownership of the TTY again as part of the process clean up. (line 28 onwards) Processes invoked from a shell should also be part of a process group: https://github.com/lmorg/murex/blob/master/lang/exec_unix.go... You also need to set the shell to be a process session leader: https://github.com/lmorg/murex/blob/master/shell/session/ses... All of this is UNIX (inc Linux) specific so you can see compiler directives at the top of those files to exclude WASM, Windows, and Plan 9 builds. I don't even try to emulate job control on those platforms because it's too much effort to write, test, and maintain. > i have been wondering if it is not possible to get rid of that emulation layer and provide for a more rich way for programs to interact with the user. Funny enough, this is something I'm experimenting with my terminal emulator, though it's very alpha at the moment https://github.com/lmorg/Ttyphoon > to get that emulation layer we only need to port something like tmux onto that new api My terminal emulator does exactly this. It uses tmux control mode so that tmux manages the TTY sessions and the terminal emulator handles the rendering. > https://github.com/yshui/job-security so this can be done without having to reimplement the emulation yet again The problem with a 3rd party tool for job control is that it doesn't work with shell builtins. And the massive value add for shells like Murex and Elvish is their builtins. This is another reason why I didn't want POSIX job control in Murex: I wanted to keep my shell builtins powerful but also allow them to support job control in a way that feels native and transparent to the casual user.

lator. If just to demonstrate the terminal's capabilities. It's still pretty alpha but I'd definitely welcome any feedback on the project's mission. > I’m not sure about that. Two separate channels results in synchronization problems (which is why the parallel port went away and why USB and all modern protocols are serial). Synchronizing electrical signals is a very different problem to synchronizing data streams. There's plenty of protocols out there that solve the second problem already: TCP/IP (order of packets), video codecs (audio / video synchronization), and so on. They key isn't to have the zero control sequences in the content stream. It's to reduce those control sequences to just being tags or markers, and shifting the meta data out to the data stream. An example of this is HTML vs CSS. HTML is the content, CSS is the formatting. Granted they're not streamed, but it's a visual demonstration for how separate concerns can be divided but still connected. This type of approach would also solve the existing synchronization issues with stdout and stderr. Though if we're already redesigning the terminal in backwards incompatible ways, I'd do away with stderr entirely and replace it dedicated control sequences and first class error handling. None of this would ever happen but a guy can dream.... (though this is why I started the mxtty project: to see just how far I could push terminal capabilities in a backwards compatible way)

at's used to detect if a fd is a pipe or TTY, basically just performs a terminal-specific I/O control operation to see if the file descriptor can handle terminal-specific controls, and if it can't, then assumes the fd is not a TTY. Its a complete hack in my opinion. A hack that works and has worked for a great many years. But a hack non-the-less. Also having a separate data and control channel allows you to incorporate more meta data about the data channel. I actually use this trick in my $SHELL, Murex [0]. It's a typed shell (like Powershell but far less verbose and far more ergonomic to use) however it works perfectly fine with standard POSIX pipes because the type annotations are sent over a different channel. So you have the best of both worlds: raw byte streams for anything classical, but also rich type metadata for anything that understands Murex pipes. While introducing zero boilerplate code for anyone who uses the shell. > > there’s a reverse carriage return ASCII character Which one? And if it works, why does ”tput cuu1” not output it, instead of ^[M or ^[[A? You're right. I was thinking of ^[M [1] (C1 control sequence) and getting confused with C0 sequences (ie ASCII characters). Wasn't helped by me misremembering that modern terminal emulators tend to treat multiple different ASCII characters as LF, such as VT (vertical tab) and FF (form feed) [2] [0] https://murex.rocks [1] https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1... [2] https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c0...

to read any docs. - $FORCE_COLOR This is an often used standard. Christ only knows why this one exists when we already have 3 other env vars being used this way. Another example of nobody bothering to read any docs - $NO_COLOR This is intended to do the opposite of the others and tell applications not to use colour. However even this is often ignored. ---- That's 6 different ways to check whether to colour output or not. Only one actual standard method and everything is only partially supported (if at all) in applications. Hence why applications then need a `--color` flag, which even that differs in support and syntax across different command line tools. And the "default" method you described, $TERM, actually breaks applications on alternative terminal emulators and hardware terminals -- that is unless they decide to announce themselves as `xterm` and in that case that environmental variable becomes entirely pointless because it has naff all to do with terminal listening. ---- > Not sure what terminals do without color support with color escape codes. They ignore them. ANSI escape codes are a pain in the arse to parse but there is at least a documented standard way to parse them. Anything that is a CSI (Control Sequence Introducer) sequence, and that includes SGR (Select Graphic Rendition) parameters like colour codes, start with `{ESC}[` and terminate with a character in the range of 0x40 to 0x7E. It's actually a little more complicated than that[1] but that's the gist of it. So you know what to print and what to ignore. There are other escape sequences too, the other big one being OSC (Operating System Command) and they're terminated `{ESC}\`, which is usually referred to as ST (String Terminator). That is unless you're xterm, and then you terminate OSC sequences with either ST or BELL (char 0x07). A lot of this makes more sense if you look at code rather than documentation. So I've made an effort to ensure my own terminal emulator's source code is as self-documenting as possible, eg[2] [1] https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_... [2] https://github.com/lmorg/mxtty/blob/main/virtualterm/ansi_c1...

sed over function.