> Terminal emulators display grids of characters using all sorts of horrifying protocols.
What sort of "horrifying protocols"? The entire VT220 state machine diagram can be printed on a single letter- or A4-sized sheet of paper. That's the complete "protocol" of that particular terminal (and of any emulator of it). Implementing the VT220 with a few small extensions (e.g., 256 colors or 24-bit colors) wouldn't be too onerous. I implemented such a parser myself in probably a few hundred lines of code, plus a bit more to do all of the rendering (drawing glyphs directly to a bitmapped display, with no libraries) and handling user input from a keyboard. You'd have a difficult time properly parsing and rendering a significant subset of HTML in less than a few _thousand_ lines of code.
Edit to add: terminal emulators often implement other terminals like VT420, but the VT220 is enough for the vast majority of terminal needs.
> I guess that copying from the output of cat file on a terminal is one of those unfortunate cases.
It depends on the terminal. Some will actually preserve the line breaks vs soft wraps. Those terminals will reflow the text when you resize the window.
But if you already have the file you might as well run something like `xclip <file` to copy its contents directly to the clipboard.
You can do the same with text. If your messaging client is lame and forces wrapping, copy and paste the text to a real text editor with left/right scroll and your font and color scheme and other preferences of choice.
> still has syntax highlighting (using the sizes/colors/styles that I'm accustomed to)
Where I work I find it's usually the youngins using a ridiculous light on dark color scheme that post screenshots of code. Are we still stuck in the '80s? And are they pining for a time they never experienced themselves? Computer hardware has been capable of displaying the more civilized and easier-on-the-eyes dark on light color schemes since then.
But at least text can be copy-pasted by the receiving user into a real text editor of their choice if there's an actual need to preserve tabular/indented/wide text.
One really nice thing about a distributed version control system is that it lets me as a developer make commits to track my work without having to push them to a central location and pollute the global commit history of the repository. I can modify my commit history (to clean it up and remove all of my failed experiments, for example) before I publish it, so to speak. Or I can completely remove my commits without publishing at all if what I was trying didn't pan out.
tmux is MIT-licensed, right? The MIT license is very similar to the (3-clause) BSD license which makes it upward-compatible with the GPL (you can incorporate MIT- or BSD-licensed code with GPL-licensed code).
Edit: and to your point of a distributor withholding the source: yeah, so? If there ever came a point where the current maintainer closed its source (unlikely), somebody with a copy of it can step in with a fork. Or the project can die a deserved death for closing its source. At this point the benefits of open source are pretty much obvious to anyone with a brain, and closing the source of an open-source project is practically suicide.
> Though conversely, when someone buys the trademark for an existing piece of software, and replaces it with something entirely different, like what happened with Audacity, that's also bad. So there's no good solution.
I've followed the Audacity situation over the last few years. Before the Muse Group bought the rights to the trademarks and took over development, Audacity development had pretty much stagnated.
The new developers did not replace it with something entirely different. What they did was fix longstanding bugs and add new features/enhancements (and changing the way some things work, for better or worse). Sure, they introduced new bugs here and there with the new features/enhancements, but last I checked they fixed those. And yes, they could have done a better job at marking new versions as "beta" rather than pushing them out as stable releases (old hands know to avoid a new version until a couple minor versions later). That's really my biggest gripe with their development/release process.
What sort of "horrifying protocols"? The entire VT220 state machine diagram can be printed on a single letter- or A4-sized sheet of paper. That's the complete "protocol" of that particular terminal (and of any emulator of it). Implementing the VT220 with a few small extensions (e.g., 256 colors or 24-bit colors) wouldn't be too onerous. I implemented such a parser myself in probably a few hundred lines of code, plus a bit more to do all of the rendering (drawing glyphs directly to a bitmapped display, with no libraries) and handling user input from a keyboard. You'd have a difficult time properly parsing and rendering a significant subset of HTML in less than a few _thousand_ lines of code.
Edit to add: terminal emulators often implement other terminals like VT420, but the VT220 is enough for the vast majority of terminal needs.