Markdown is still just plain text without any "crazyness".
Stuff like "## Header" isn't any more "crazy" than the ASCII art used in many Readme's of old and on top of that doesn't rely on specific monospace fonts or fixed width.
And more advanced stuff like hyperlinks or tables are hard to do "right" in text anyway, since it's basically meta data without an objective "right" or "wrong" way of representing it.
I also truly believe that it's time to finally let go of the 80-columns obsession. It's not 1975 anymore and even the ancient VT100 from 1978 had a 132-column mode. It's just an indefensible relic that held developers hostage for way too long.
Still want 80 columns on your 4k 27" 10bpp HDR monitor? Fine, but don't insist on others bending over backwards just not anger the grey beards on top of Mount Teletype... Text editors are perfectly capable of introducing proper line breaks even at word boundaries if need be.
It's really just become l'art pour l'art to force this arbitrary (by today's [and by today I mean the past 30 years!] standards) restriction on developers with no benefit to readability.
I'm not against markdown per-se, but against markdown readme files that use so much markup (heh) that become unreadable as plain text, no matter your screen size.
> Still want 80 columns on your 4k 27" 10bpp HDR monitor?
This is offtopic, but a strong YES. There's good reason why on printed books you don't ever see more than about 70 characters per line of text. Long lines are just unreadable, regardless of your font/window/screen size.
They go beyond the limit by displaying text in columns. Imagine how difficult it would be to read a broadsheet newspaper if the text ran from one edge of the page to the other. As lines get longer, it is increasingly difficult to find the starting point of the next line and reading speed and comprehension are reduced.
Just for shits and giggles I grabbed a random book from the shelf and counted characters per column.
The book I grabbed was "Spoken Language Processing", Huang Acero, Hon (ISBN 0-13-022616-5) and I counted 88 characters per line. The book is still very readable, despite exceeding the claimed 70-odd character limit for books/columns. Another book sitting next to it (a numerical mathematics textbook) had 82 characters per line.
Granted, the limit of no more than 70 characters per line applies if whitespace and punctuation aren't counted, but that's never done with hard limits in digital documents either, so...
I have a 4k 43" monitor. Now I can easily see 8 separate chunks of code with my monitor split into 4 columns and 2 rows. Or I can see 2 columns and have the app on the left half of the screen with a debugger. I break the 80-char rule frequently, but having code be limited in width is still useful.
I find soft-wrapping code pretty tedious, so even with huge screens IMHO indeed breaking around 80-100 (accounting also for indentation) is nice.
BTW I recently go a 24" screen (I was all about laptops, turns out I was torturing myself...) and I can easily fit 3 columns in Emacs, with a large-ish point size (238 chars across the monitor, DejaVu Sans Mono). If it's not a preference thing, and assuming (corrected-to-)fine eyesight, shouldn't 43" be capable of like 8x2 easily?
Stuff like "## Header" isn't any more "crazy" than the ASCII art used in many Readme's of old and on top of that doesn't rely on specific monospace fonts or fixed width. And more advanced stuff like hyperlinks or tables are hard to do "right" in text anyway, since it's basically meta data without an objective "right" or "wrong" way of representing it.
I also truly believe that it's time to finally let go of the 80-columns obsession. It's not 1975 anymore and even the ancient VT100 from 1978 had a 132-column mode. It's just an indefensible relic that held developers hostage for way too long.
Still want 80 columns on your 4k 27" 10bpp HDR monitor? Fine, but don't insist on others bending over backwards just not anger the grey beards on top of Mount Teletype... Text editors are perfectly capable of introducing proper line breaks even at word boundaries if need be.
It's really just become l'art pour l'art to force this arbitrary (by today's [and by today I mean the past 30 years!] standards) restriction on developers with no benefit to readability.