"G. Branden Robinson" <g.branden.robin...@gmail.com> writes:
> Okay...by this time groff had for about 10 years been producing > device-independent _terminal_ output from troff(1). On the other, that > is its own peculiar little language. Maybe the author just didn't want > to deal with *roff, or didn't want to count on GNU troff being > available. Oh, yeah, to be clear, the context of this was viewing Perl documentation without nroff, so it's fairly off-topic for this list other than the specific example of someone who found overstrike output useful in a related context. There has been a lot of back and forth in the Perl world about whether to use a formatting pipeline that involves nroff by default. perldoc defaulted to Pod::Man plus nroff for a long time, but it's defaulted to Pod::Text for a while. I think the main reason was better UTF-8 support (which is partly my fault for being very conservative about not wanting to produce UTF-8 roff for a long time until I could do some comprehensive testing that took me embarrassingly long to do, and people understandably got sick of their names showing up as sequences of X characters), but portability to Windows and some other platforms was I think part of the reasoning. I have to be honest that I've not kept track of that debate because I didn't want to own the problem and I wasn't seeing the user feedback. It's all the same to me; both Pod::Man and Pod::Text are supported and will continue to be. But now Pod::Man supports UTF-8 by default because I managed to convince myself that this worked on every significant platform that wasn't a museum piece. I think my brain works a little oddly in that I sort of randomly use perldoc or man to read Perl documentation so sometimes it's formatted with nroff and sometimes it's not and I don't really notice the difference. I also write all my code in Emacs but use vi to write all my commit messages and randomly switch between them for editing text files. I am probably not the average user. :) >> I know that to a first approximation all the world is now some >> variation of an imaginary VT100 terminal emulator, and thus one can >> usually blindly use SGR escape sequences and expect them to work in >> much the way that one can assume all programs only run on VMS. > I think that's a little unfair. We can trace the history of these > escape sequences back to ANSI X3.64, which was later succeeded by > ECMA-48 and (equivalently, as far as I know) ISO 6429 and JIS X 0211. > These standards have been around approximately as long as Unix has been > something you were likely to run into at your university or workplace. I'm sorry, I really hope that didn't sound critical of anyone here. It was meant to be wryly funny, but I probably shouldn't be attempting that on a mailing list I'm fairly new to. I am one of those people who blindly assumes SGR escape sequences in a lot of things (I also maintain Term::ANSIColor in Perl core), so I was mostly poking fun at myself, but I didn't explain any of that. I know that you of all people wouldn't blindly do anything. :) I just see a ton of code out there these days that assumes everything is ECMA-48 compatible, which to be fair really is a reasonable assumption in most places these days. We still have all of the infrastructure to support terminals that behave very differently, like VT-52s, and a lot of code still calls into it, but I think the details of terminal portability are a bit of a lost art and I bet a lot of things would not actually work on a real VT-52. I remember the days when you could enter your username in ALL CAPS at the Linux console login prompt and it would automatically switch to the mode that supported compatibility with terminals that didn't have lowercase letters. But there is no compelling reason to support this type of portability any more unless one is running a museum. > But that's not the fault of ECMA-48, which has even had the virtue of > being freely available on the Web for many years. We cannot say as much > for many ANSI or ISO/IEC standards. Yes, indeed, although as I've learned from maintaining Term::ANSIColor, there's all sorts of new-fangled stuff now, such as "true color" support which Wikipedia thinks comes from ITU T.416. I never bothered to track it down. > I'm no MS-DOS/Windows expert, but my understanding is that you couldn't > count on support for ECMA-48 at the DOS prompt (or equivalently in > CMD.EXE on NT-descended Windows) because the console driver didn't > recognize them. Correct, although I believe this may have changed with newer versions of Windows. > I have gathered, by reading bug fora and similar while trawling the > Internet for accounts of trouble with groff that people are too lazy to > actually report to us, that Windows 10 or 11 has a console > driver/terminal emulator that does "better" with ECMA-48 support. I > haven't heard even a rumor of anything usefully quantitative, like a > table of its support for standardized escape sequences in comparison > with, say, xterm, or even the Linux kernel's somewhat wobbly virtual > console device. But, supposedly, things are "better". You may find the NOTES section of the Term::ANSIColor man page interesting, although it's probably out of date since I rely on other people to send me updates. Term::ANSIColor also comes with test files and a test file generator that one can cat on a display to see what works. -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
