4/3/2026 at 6:13:15 PM
Because, like UNIX/Linux itself, worse is better: https://en.wikipedia.org/wiki/Worse_is_better - and perfect is the enemy of "good enough."We want to encourage people to produce written output with minimal friction. Barriers to writing--and especially barriers to producing documentation--should be minimized. Writing well is difficult enough!
Markup is overhead. Complex markup is even more overhead. Markdown is the best compromise we know of today that provides just enough structure and typographic capability, while imposing very little cognitive load on the author.
Besides, if you need something more complicated these days, you can have your favorite AI agent do it.
by otterley
4/3/2026 at 6:35:52 PM
It's also worth remembering that markdown tried very hard to encode conventions that were already used in Usenet, email, and other text media. A > to indicate a quote was widespread Usenet convention. Asterisks or underscores to indicate emphasis was also a common convention; both are legal because both were common. Double asterisk or double underscores to indicate really, really emphasizing something was also a common convention. So were asterisks to display a bulleted list, blank lines to separate paragraphs, and indenting 4+ spaces to write code.It's a good example of "pave the path" design philosophy, where you do what users are already doing rather than trying to impose some platonic ideal of what the world should be like. And it works quite well at that.
by nostrademons
4/3/2026 at 6:40:51 PM
markdown tried very hard to encode conventions that were already used in Usenet, email, and other text mediaFor those of you who weren't there:
*bold*
_underline_
~strikethrough~
/italics/
> Quotation
- list
- list
- list
by reaperducer
4/3/2026 at 7:26:10 PM
Your quotation and list syntax should work out of the box in most Markdown flavors (HN has a very non-standard and crippled version - basically nothing other than italics, paragraphs, and code/preformatting works.)Strikethrough and bold are doubled to avoid common ambiguities. Your underline should technically work, but it comes out as an <em> (emphasis) tag, which is rendered as italics in most browsers.
by nostrademons
4/4/2026 at 5:07:42 AM
What ambiguities are there with bold?by 8n4vidtmkvmk
4/4/2026 at 5:28:48 AM
Suppose you want to use asterisks to mark footnotes.* As soon as you add a second footnote,** you're in trouble because your asterisks disappear and everything between them turns bold.* I had to escape all of these asterisks.
** I see this happen fairly often to people's comments here.
by nickloewen
4/4/2026 at 6:20:57 AM
Disappearing asterisks is just terrible UX. It should turn bold but keep the asterisk displayed so you can still edit as normal.The bullet point problem is fixed by only bolding when the asterisks are on either end of word characters.
by 8n4vidtmkvmk
4/4/2026 at 9:49:27 AM
> It should turn bold but keep the asterisk displayed so you can still edit as normal.This is just terrible UI, why do you need garbage marks when you already have bold? And you can edit "as normal" if you like, but that only requires displaying asterisks during that tiny % of time you edit the word, not all the time when you read it or edit something else.
by eviks
4/4/2026 at 10:02:30 AM
This is just a personal preference. I strongly prefer to see the markup as I write it. I can't stand disappearing characters.by localuser13
4/4/2026 at 11:32:08 AM
Do you enable visibility of tab and space?by eviks
4/4/2026 at 10:55:59 PM
I do!by reaperducer
4/4/2026 at 1:50:51 PM
So you can still see the actual text that you're editing. And to reduce ambiguity. If you don't leave them, then you can't distinguish between adding more bold text to currently bold text or adding non-bold text immediately afterby duskdozer
4/4/2026 at 1:59:28 PM
> So you can still see the actual text that you're editingBut you're not editing that text! You're editing some other text and see a bunch of asterisks all over the place. And this is especially bad in nested styles - try some colored bold word in a table cell - without hiding the markup you'll basically lose most of visibility into the text/table layout
> to reduce ambiguity
it does the opposite, you can't easily distinguish between an asterisk and an asterisk, which is... ambiguity
> can't distinguish between adding more bold text to currently bold text or adding non-bold text immediately
Sure you can. In a well-designed editor you'll see the style indicator right near your caret is so it's always obvious whether and how your typed text is styled or not.
In a not-so-well-designed editor you'll get that indicator far away from your caret or just get asterisks appearing when you need them.
In a not-designed editor you'll see them all the time even when they don't serve any purpose.
by eviks
4/4/2026 at 9:49:15 PM
Ha, I remember this religious debate all the way back in the days of text-mode word processing in the 80s on CP/M and PC. I was indoctrinated in the WordStar camp where style controls were visible in the editor between actual text characters, so you could move the cursor between them and easily decide to insert text inside or outside the styled region. This will forever seem a more coherent editing UI to me.This might be why I also liked LaTeX. The markup itself is semantic and meant to help me understand what I am editing. It isn't just some keyboard-shortcut to inject a styling command. It is part of the document structure.
by saltcured
4/5/2026 at 2:50:42 AM
> easily decide to insert text inside or outside the styled region.Only for the 3 primitive styles that were supported? 3 table cells of RedBold GreenLowerCaps BlueUnderlineItalic isn't easy anymore
But also - there wasn't a single app in the 80s with a different easy approach, right? So removing noise had a downside.
> styling command. It is part of the document structure.
Not for the most used markdown markers, where styling = semantic.
by eviks
4/5/2026 at 5:32:51 PM
Heh, I'm not even sure WordStart other styles at that level. Changing the color back then would mean having the print job pause and the screen prompt you to change ink ribbon and press a key to continue. I can't remember if it could also prompt to change the daisy wheel, or whether font was a global property of the document. The daisy wheels did have a slant/italic set, so it could select those alternate glyphs on the fly from the same wheel. Bold and underline were done by composition, using overstrike, rather than separate glyphs.But yeah, this tension you are describing is also where other concepts like "paragraph styles" bothered me in later editors. I think I want/expect "span styles" so it is always a container of characters with a semantic label, which I could then adjust later in the definitions.
Decades later, it still repulses me how the paragraph styles devolve into a bunch of undisciplined characters with custom styling when I have to work on shared documents. At some point, the only sane recourse is to strip all custom styling and then go back and selectively apply things like emphasis again, hoping you didn't miss any.
by saltcured
4/5/2026 at 4:55:05 PM
Same, same.And... I preferred WordPerfect's separate "reveal codes" pane, which reduced the opportunity for ambiguity. WP 5.1 has never been equalled as a general-purpose word processor.
by eszed
4/4/2026 at 7:45:37 AM
What ought, amn'tby registeredcorn
4/4/2026 at 2:45:29 PM
For the love of god, yes. Slack is the worst for this with backticks. Editing the start/end points is a giant pain.by roblh
4/4/2026 at 4:02:22 PM
Asterisk * has other uses too. Even more common than footnotes would be x*y=42 X=42/yedit: HN automatically finds this example and puts in escapes to make it work. From elsewhere in the discussion I just want AsciiDoc.
https://docs.asciidoctor.org/asciidoc/latest/asciidoc-vs-mar...
by bnjms
4/4/2026 at 5:08:32 AM
One problem with the /italics/ form is that it's not convenient when writing about filesystem paths (though I do like its visual indication of slanting).by beautron
4/4/2026 at 3:52:42 PM
I agree that file paths should be in `backticks`.Or italics can be //double slash// to avoid ambiguities with file paths. That still leaves the windows style //some/file/path as ambiguous But I’ll never accept single * as natural for italics.
by bnjms
4/5/2026 at 3:04:20 AM
Try finding the backtick on a mobile phone keyboard in less than a minute, tho. So very annoying. (SwiftKey I'm look at you, bud.)by AceyMan
4/4/2026 at 3:28:18 PM
A path should be written `/root`...by _bernd
4/4/2026 at 9:21:29 AM
Yeah, *asterisks* for italic has always felt wrong to me. I can understand underscores if slashes cause confusion with file paths.*bold* and _italic_ would have been better.
by mcv
4/4/2026 at 1:25:28 PM
I agree that using *asterisks* just feels wrong for italics, and are much better suited for bold. However, surely the _underscore_ is just perfect to visually indicate underlining?As for /slashes/, which would visually be perfect for italics, the only reason they conflict between italics and filepaths is the fact that in both cases they are expected to be used at the beginning and end of a word. Maybe using an unnatural placement of )parentheses( could have worked as a non-conflicting indicator of italics.
by Mordisquitos
4/4/2026 at 2:16:14 PM
_underscore_ for italics conflicts with most identifiers in most languages.Markdown was created in an era before the web had easily used components for structural syntax highlighting (tree-sitter) and where reliance on regex-based approaches was more common.
by politician
4/5/2026 at 4:01:38 AM
> Maybe using an unnatural placement of )parentheses( could have worked as a non-conflicting indicator of italics.Using different delimiter for opening and closing is a good idea on its own, too. I think it makes parsing simpler and unambiguous wrt nesting.
I've imagined something like this:
`(monospace)
_(underline)
/(italics)
~(overstrike)
by sudahtigabulan
4/7/2026 at 7:09:57 PM
> Maybe using an unnatural placement of )parentheses( could have workedO, c'mon! That is clearly a giant heading in a display font, squeezed in the middle and wider at the top and bottom. (-;
by IIsi50MHz
4/6/2026 at 12:49:07 AM
Like Typst does ;-)by johannesrexx
4/4/2026 at 11:43:55 AM
Thanks for posting this. I feel like for years we've been getting gaslit by the Markdown guys who inexplicably decided that stars should make text go italic instead of bold. I get it wrong every single time and then have to go back and look up a cheat sheet. It really isn't intuitive at all, and it also doesn't codify how we used to write before rich text entry boxes where available everywhere. Markdown reminds me more of all the custom wiki and forum markups that proliferated in the 2000s than any text-based conventions in use prior.by alisonatwork
4/5/2026 at 1:36:36 PM
I have long used underscores for _emphasis_, but I never made the connection that it was meant to resemble an underline until now.by oftenwrong
4/5/2026 at 12:34:21 AM
I have historically used asterisks for emphasis and slashes for the use/mention distinction.by TRiG_Ireland
4/4/2026 at 2:11:03 PM
Org-mode FTWby tmalsburg2
4/3/2026 at 7:29:51 PM
But Usenet style didn't have a trendy name, an 'inventor' or Github stars. So it didn't exist.by dingaling
4/4/2026 at 1:58:07 AM
GitHub stars weren't a thing when Markdown was roughly codified. Was GitHub even around then?by geerlingguy
4/4/2026 at 1:32:58 PM
Git wasn't even around.by Jtsummers
4/3/2026 at 6:41:12 PM
Stepped right on the rake though because it uses sigils which were common, but requires they be used in uncommon ways (by doubling etc) which it why most chat UIs don't actually use markdownby singpolyma3
4/3/2026 at 8:06:47 PM
Somehow basically only Discord gets it almost perfectly right though.by packetlost
4/4/2026 at 2:04:51 PM
Which is very recent. Discord only added full markdown support a couple years ago.by devmor
4/4/2026 at 4:33:41 PM
Even when they only had a subset, that subset was correctby packetlost
4/4/2026 at 7:43:16 AM
Writing mark down linter, i am i nterested in - if you think that you requirements for markdown formatting could be encoded in (relatively) simple rules?by je42
4/7/2026 at 1:03:54 AM
Commommark is the best, then looking at the most commonly implemented extensions:- Superscript with hat symbol (^)
- Hidden content (also known as spoiler tags, content warnings, click-to-reveal, etc...) with two pipe symbols (||) at start and end of hidden content. Interact with the content to show the content inside.
- Table syntax to show tabular data and align content with pipe, hyphen, colon symbols
---
After that, I'd look at the extensions that are only useful for the use-case you're targeting:
- Subscripting with tilde symbol (~)
- IDs, Classes and Attributes
- Task lists
- Sections / Containers
- Language labels for code blocks
- Math Support (mathml, latex, katex, etc...)
- Table of Contents / Footnotes
- Definition lists
- etc...
by spartanatreyu
4/4/2026 at 8:06:32 AM
Just search "Markdown grammar"by guerrilla
4/4/2026 at 10:27:43 AM
Check out commonmarkby bityard
4/4/2026 at 1:29:52 AM
> worse is betterIt's a very old idea
In the paper, Copernicus postulated the principle that "bad money drives out good", which later came to be referred to as Gresham's law after a later describer, Sir Thomas Gresham. This phenomenon had been noted earlier by Nicole Oresme, but Copernicus rediscovered it independently. Gresham's law is still known in Poland and Central and Eastern Europe as the Copernicus-Gresham Law.
by neonstatic
4/4/2026 at 6:57:30 AM
I'm not quite sure I understand the connection.by edanm
4/4/2026 at 8:05:04 AM
I see one, but then maybe I am just seeing things.The wikipedia page about "worse is better" re: software linked above states:
It refers to the argument that software quality does not necessarily increase with functionality: that there is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability.
by neonstatic
4/4/2026 at 10:01:03 AM
Bad money drives out good money only if there is a legal tender law such that both have to be accepted for the same nominal value. In this case, good money is hoarded because it cannot be traded for its true value.by atanasi
4/3/2026 at 6:21:35 PM
The solution is sufficiently perfected with markdown. Just like new revolutionary technologies doesn't replace wheel technology.by wisemanwillhear
4/4/2026 at 1:49:35 AM
To actually manage notes and information in plain text I like org-mode markup. For just writing, markdown is good enough.by SoftTalker
4/4/2026 at 12:23:10 AM
This is exactly why ReStructured Text is better/worse.by ZoomZoomZoom
4/4/2026 at 1:19:40 PM
> We want to encourage people to produce written output with minimal friction. Barriers to writing--and especially barriers to producing documentation--should be minimized. Writing well is difficult enough!What about something like AsciiDoc (or reStructuredText)?
* https://docs.asciidoctor.org/asciidoc/latest/asciidoc-vs-mar...
* "Markdown, Asciidoc, or reStructuredText – a tale of docs-as-code": https://news.ycombinator.com/item?id=33468213
Simply things are still simple, but there seem to be more advanced options for those that want/need them.
by throw0101c
4/4/2026 at 2:59:23 PM
The problem is that proposed Markdown alternatives are targeting a vanishingly small niche of scenarios: for almost all simple writing Markdown is good enough, and for anything too complicated for Markdown, people will use HTML or LaTeX/Typst. The in-betweens just don't seem to have a reason to exist.by Analemma_
4/4/2026 at 11:43:41 AM
Saying, that it is the best compromise we know of is going a little far, I think. There are more readable intuitive formats, but they simply don't have the spread, that markdown formats have.by zelphirkalt
4/5/2026 at 6:08:44 PM
Why do you think that is?by NetMageSCW
4/5/2026 at 9:42:30 PM
Because I think, that there are other formats, whose formatting rules are more intuitive than Markdown's formatting rules. For example: (1) I can never remember, whether I need to use [] or () first, when embedding an image. In Org mode syntax one simply uses [] for both parts.
(2) Or whether ** is bold or italic or * is bold or italic. Other formats use the well known / to mean italic, which optically already makes more sense and also doesn't interfere with something being bold or not, because it is a separate symbol. This makes Markdown also harder to parse btw..by zelphirkalt
4/4/2026 at 5:27:04 PM
It's the inescapable truth that even after sitting down and engineering a magical solution ... sometimes just a basic CRUD function with just a couple bits added that doesn't have all the bells and whistles is what actually lasts when I write code and requires less maintenance.There's the stuff that wows people and the stuff that people actually USE.
by duxup
4/3/2026 at 6:31:11 PM
For me, Markdown produces a lot of unnecessary cognitive load compared to other markup languages.• I have to decide whether to use asterisks or underscores for bold and italic.
• I have to decide whether to use asterisks, hyphen-minuses, or plus signs for unordered lists.
• I have to remember all the various rules and edge cases about parsing.
by xigoi
4/3/2026 at 6:40:23 PM
> compared to other markup languagesI think it would be easier for me to appreciate your comment if you named some of these other languages. Markdown is the only standardized one I regularly come across that I type by hand, these days.
What are you contrasting to?
As for Markdown specifically- the only thing I regularly mix up is the syntax for links. I frequently reverse the [] and (). But that's just because I don't use it enough to have the muscle memory.
by mh-
4/4/2026 at 8:27:58 AM
> the only thing I regularly mix up is the syntax for links. I frequently reverse the [] and ()I remember it as passing parameters to a function that requires an URL as an argument. Maybe it's not the most straightforward way, but it works for me
by klez
4/4/2026 at 5:43:16 AM
I used to flip the link syntax all the time too. What finally helped me to remember it was noticing how I write links in plaintext emails.In email, I naturally write things like "...on the example website (www.example.com)..."
Markdown keeps those () in the same place, and just adds the [] so you can delimit the visible text: "...on the [example website](www.example.com)..."
by nickloewen
4/4/2026 at 5:58:10 AM
I remember it like this: If you squint the brackets around the link text make a rectangle and look almost like a button you can press. [Press here](to.go.there)by mschnell
4/3/2026 at 6:50:21 PM
> I think it would be easier for me to appreciate your comment if you named some of these other languages.HTML? Also my markup language I created for myself, which is currently not published.
by xigoi
4/3/2026 at 7:23:09 PM
[flagged]by mkldd
4/3/2026 at 6:38:07 PM
1&2 just pick one, it doesn’t matter. 3 mostly you’re the parser… if you’re after accuracy there are better versions, but it sure is simple to read and writeby nxpnsv
4/3/2026 at 6:34:51 PM
I suggest trying Obsidian for WYSIWYG markdown editing. It beats heck out of typing it raw and eliminates that cognitive load.by chrisweekly
4/3/2026 at 6:52:03 PM
I don’t like WYSIWYG editing, as it makes the formatting invisible.by xigoi
4/3/2026 at 11:55:02 PM
Then you might like Obsidian. When the cursor is in some bit of formatted text, it displays all of the characters. When the cursor is elsewhere, it just shows the formatted text.In the worst case, the barrier to entry and exit are pretty low.
by delecti
4/4/2026 at 6:15:30 AM
Obsidian has 2 main advantages to me.First you can switch from WYSIWYG to text editor instantly.
Then you have an outline where you can manipulate your “markdown blocks” [i.e title and its content] by drag n drop. Or extract a “markdown block” as a new note, and leave a reference where it originally was extracted from.
And then [the killing feature], it displays the content of a link, web link or internal link, as a [kind of] iframe, if you prepend a ! to the link.
by lolive
4/4/2026 at 9:32:16 AM
[flagged]by GandalfHN
4/4/2026 at 4:54:44 PM
[dead]by arunbose
4/4/2026 at 8:21:12 AM
[flagged]by GandalfHN
4/5/2026 at 8:57:42 AM
> We want to encourage people to produce written output with minimal friction.What's wrong with .txt ?
by hulitu
4/5/2026 at 6:10:57 PM
We also want standard structure so the more than the content is understood.by NetMageSCW
4/4/2026 at 4:36:21 PM
> barriers to producing documentation--should be minimized. Writing well is difficult enough!Writing is a demanding kind of encoding. At the same time, we all expect but rarely get good, accessible, searchable documentation. Why? The one barrier that cannot be removed is the need to retain semantic structure.
In TFA, the author writes:
The Bad -- We don’t know what we want.
We consistently fail to manage meaning. It's strikingly paradoxical because the art of programming is all about meaning. We organise code semantically because it is essential to do so (not just for compiling, but also) for extending/refactoring/review/retrieval/understanding.
We need to write with the same considerations. This need not be complicated. Yet we persist in using the wrong utensils for the recipe.
> Markdown is the best compromise we know of
It reduces keystrokes and makes the handraulic act of writing easier. But... it addresses only part of the problem.
As an example of a small improvement, HTML5 offers a minimal set of semantic tags: <summary> <article> <main> <section> <details> <aside> <figure> <figcaption> <time>
It may be a simplistic set of tags, but it is an improvement over easy-to-type text blobs.
by heresie-dabord
4/3/2026 at 10:44:00 PM
Worse is better doesn’t mean worst is best either.by sph
4/3/2026 at 11:44:30 PM
Markdown is pretty far from the worst. It's decent and unobtrusive. Worst would be something like Troff or jira formatting. Midtier would be RST.by AlotOfReading
4/4/2026 at 12:14:55 AM
Ugh, troff. It's mind-boggling that the closest way to have an actual (hyper)link in a manpage is to use your pager's "search for text" function. No, "JuSt usE gNu iNfO it'S beTtER" is not an answer either.by Joker_vD
4/4/2026 at 1:09:33 AM
groff can produce output with links in it, and does by default in HTML mode! The GNU version of the Unix man page macro set has .UR and .UE for “URI start” and “URI end”. (I don't know whether these were present earlier in the lineage or whether they were introduced by GNU.) Also, the lowdown Markdown converter when in man output mode will output those for links. For fun, try: echo 'Hi there! Have a [hyperlink](https://www.gnu.org/software/groff/manual/groff.html).' | lowdown -st man | groff -man -Thtml
So if I set MANROFFOPT=-rU1 in the environment, I can get clickable links in man… if the man page author included them that way in the first place. I'm not sure how common that is in the wild, but grepping the ones on my system, I find firejail(1) contains a link to a GitHub issue embedded in that way, and it does indeed work when I hit ^O^N to seek to it and then C-mouse1—though the mouse gesture I have Alacritty using for links doesn't seem to work through tmux (there might be a way involving twiddling the tmux terminal-features setting, but I ran out of steam before trying this), and I didn't see a great way to get either grotty or Alacritty to style them on display instead of having them blend into the surrounding text, so it's still kind of scuffed in practice. (Though I bet the cool kids have moved on from Alacritty by now?) less displays the link target in the status line when you use the navigation commands, so it's not inaccessible, but for opening selected links directly from less with the ^O^O gesture rather than leaning on terminal support, it looks like you need to explicitly set the LESS_OSC8_ANY and/or LESS_OSC8_‹scheme› environment variable to a shell command that outputs a shell command pattern to substitute the link into; if I set LESS_OSC8_ANY='echo xdg-open %o' then it passes it to my Firefox. I wonder if they'd take a patch (or if any existing distributions patch it) to use that as the default?
That was a fun little rabbit hole to go down, thank you.
by dasyatidprime
4/4/2026 at 9:33:00 AM
I mostly care about links inside the man page (look at man bash — there are tons of internal references like "described below under CONDITIONAL EXPRESSIONS" or "section SHELL BUILTIN COMMANDS below", or operators being underlined and looking like hyperlinks, which you can't easily interact with to just go to where they refer to. You have to employ full-text search, but it also turns up the references themselves, and good luck searching for the place where e.g. command "." is described) and links to other man pages, not the normal Internet URLs being clickable (those things are trivially copy-pastable into a browser next window).by Joker_vD
4/4/2026 at 4:25:38 PM
Ah! Yeah, that makes more sense—I misinterpreted you at first since I don't normally think of “internal link” as the default exemplar of “hyperlink”. And yeah, I don't see good target markup for that. Stuff like starting your search regexp with “^ +” helps but is still janky. I'd tend to categorize this mostly as “man pages aren't meant to be long treatments of more complex software”, of course? Some large packages do something which I kind-of like but which I'm not sure would work well if everyone did it (mainly due to ergonomy around disambiguation) where they split up a bunch of their documentation into shorter pages with the origin as part of the section when making it accessible through man: pcap_init(3pcap) from libpcap, Bigarray(3o) from OCaml. Shells, as you notice, get hit by this really hard; Zsh tries to do some splitting in the man version of its docs, but it's really not enough, like I'd want to see fc(1zsh) (and then fc(1bash), etc.) but instead it's all in zshbuiltins. (Eventually I facepalmed when I realized an Info version was available and switched to that. The way I found this out was actually by eyeing the Zsh source tree and noticing that the documentation files were written in Yodl, which I'd never heard of, and then noticing that the schema they were using looked a lot like Info…)… wow, hang on, I just checked for Bash, and it has an Info file but it says it's just an intro and the manual page is the definitive version‽ That's… hah. There must be some timeline jank around that; ambiguous NIH vibes around Info aside, I wouldn't have expected it from an actual GNU program! Did Bash show up before Info existed?
by dasyatidprime
4/4/2026 at 2:27:35 AM
If the manpage is written with the 4.4BSD -mdoc semantic markup macros then it can contain hyperlinks like .Lk https://dotat.at/ "Tony Finch’s web site"
by fanf2
4/4/2026 at 1:51:55 AM
troff was originally used to format printed output, where hyperlinks would not make any sense.by SoftTalker
4/4/2026 at 6:47:37 AM
But you still have to use it for man pages, even though nobody prints man pages anymore.by xigoi
4/4/2026 at 4:50:53 PM
A man page is simply a formatted text file. The display of it is performed by the program defined in the MANPAGER or PAGER environment variable, or by a default program, usually less(1). That is the program that would be responsible for navigating any hyperlinks, and the format of references to other pages is already pretty easy to pick out so developing a man page reader that could follow references to other man pages would not be particularly difficult. Many web-based and GUI man page viewers do this. Example: https://github.com/zigalenarcic/manglby SoftTalker
4/5/2026 at 2:46:46 AM
> The display of [a man page] is performed by the program defined in the MANPAGER or PAGER environment variable, or by a default program, usually less(1).A man page source isn't a binary format, so your statement that they're "plain text" is technically correct. (The same is also true of TeX and LaTeX files, and even PostScript if you want to stretch the definition of "plain text" until it snaps.) But the renderer is groff or (legacy) troff with the `an` macro set. less(1) (or, originally, more(1)) is just the pager that consumed the former's output (if the output format is ASCII, which is one of many) and handled paging on the terminal for the convenience of the user.
In my old Sun workstation (and even early Linux desktop) days, I rarely used man(1) in the terminal because 1/terminals were usually too small and weren't usefully resizable like they are today, and 2/unadorned monospaced fonts don't look nearly as nice as properly typeset pages do. (Color terminals were just coming on the horizon, and text could only be emboldened, not italicized.) Instead, I typically used xman whenever I could. The best way I can describe xman is as if you were rendering man pages into PDFs and viewing them in Preview on the Mac. Man pages were much more comfortable to read that way.
by otterley
4/3/2026 at 6:32:29 PM
I came here to say this.by recursivedoubts