recoil
Joined 19 years ago
Joined 19 years ago
I don't know whether it counts as "serious" to you, but literally billions of SIM cards and credit cards are running JavaCard:
https://software.ac.uk/blog/2018-07-13-javacard-execution-en...
That's a good point. My whole reply is a bit GNU-centric: the "col -bx" solution should work with everything except groff in ANSI mode (looks like the flag to go back to the standard troff behaviour is GROFF_NO_SGR [1][2], in case anybody is interested).
[1] See: https://linux.die.net/man/1/grotty [2] SGR is "Select Graphics Rendition", apparently: https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_G...
It isn't because the terminal is mis-configured and/or mis-interpreting those characters, it's because these characters have historically been used in a special way by troff's ascii output driver, as used by the man command.
Bold characters are "emulated" by outputting the character itself, followed by ^H, then by repeating the character, and underline is emulated by outputting _ (the underscore character) followed by ^H, followed by the character to be underlined. This is the same way that bold/underline was achieved on a manual typewriter or by old teletype terminals with paper output.
Pagers like "more" & "less" have in-built behaviour that knows how to interpret these sequences and render bold or underline appropriately, and if you "cat" the file your terminal would probably ignore them, but if you open a file with those sequences in a text editor, you're going to see a bunch of unnecessary ^H characters. The OP's script uses the "col" command to remove the unnecessary ^Bs (and the preceding character) that troff has output.
By default, GNU groff doesn't actually output those sequences anymore and uses ANSI escape codes instead. AFAIK many (most?) distributions actually compile out the ANSI behaviour in favour of the old way though (because "more" and "less" don't actually behave correctly with the ANSI characters by default), but some don't, which breaks the script (it's broken in Cygwin, for instance).
FWIW, if you need a fool-proof way to convert a man page to plain old ASCII with no escapes at all, it's easiest just to redirect the output of "man" to a file:
man ls > ls.txt
The long-winded way (with groff) is something like: zcat /usr/share/man/man1/ls.1.gz | groff -man -Tascii -P -cbdu > ls.txtWe were interviewed by a reporter from one of the red tops and they had to re-take our photo several times because we didn't look miserable enough.
I don't know where you got this bizarre notion. The populations of Russia (~144m), Germany (~83m), Turkey (~80m), France (~67m), The United Kingdom (~65m), Italy (~61m), Spain (~46m), Ukraine (~43m), and Poland (~38m) are all quite a lot larger than Texas (~27m).
Emacs has functioned as an "advanced text editor" for at least 20 years and probably longer. There's a very common misconception that Emacs is a "console editor", but the reality is that when you first launch it in a windowed environment you get something that looks an awful lot like Sublime, VSCode & Atom: a text editor window with a menubar and toolbar similar (yes, it's not perfect!) to what you'd expect from any other editor native to your chosen platform.
The time investment involved in learning how to use it is also considerably less than implied elsewhere in this thread. In fact I really doubt that it's significantly more than you'd have to spend educating yourself about any other "advanced editor"'s configuration, keybindings for non-obvious actions, extension mechanism, etc. It's easy enough to learn the (admittedly unconventional) keybindings for a handful of common things like opening and saving files when you have the menus to refer to, and by default it'll even open a buffer containing clickable hyperlinks to helpful things like tutorials. I still haven't seen an editor or IDE with better built-in help.
Even configuring Emacs isn't all that hard: there's a built-in interface for installing packages, most of which will pretty-much auto-activate once installed (i.e. less need to mess around with elisp), and for changing configuration there's "customize", which is a nicer way to change configuration variables than just editing a JSON file. When you do have to start writing some elisp code (you'll almost certainly have to write a little) the documentation is superb and there are more than enough resources on the web to help you. A programmer who is already familiar with a dynamic language like JS will probably have less trouble learning elisp than a C programmer did 20 years ago.
None of which is to say that there aren't areas where Emacs isn't behind. I'd like to see better support for projects, snippets and auto-completion out of the box, as well as being more nicely pre-configured for popular languages like JavaScript and Python. Emacs 24 is four years old at this point, and that's a very long time for any developer tool to stay still.
These days I'd say the most confusing thing about Emacs is working out which of the many competing packages you should choose for whatever it is you're trying to do. Age is working against it here, because what was the almost-universally-recommended package five years ago - for which you'll get plenty of helpful google search results - has often been superceded by something better.
But with a handful of plugins installed (yasnippet, helm, projectile, auto-complete) it's (IMO of course) still the best editor out there.
Thanks for sharing the link :-)