line hardwrap ~70 chars, from punchcards, a crime
line truncation to ~70 chars, from punchcards, a crime
That convention ultimately traces to punch cards with 70 holes or so. It's the worst convention, still harbored by ignorant programers to this day, even in magit (it warns when your commit line is long).
here's a sloppy fast typing rant summary.
The main problem is it encourages manual labor or labor of creating tools (emacs “fill”) to semi automate it, and created a whole industry where the botched lines creates more problems (email quote > and nested > becomes impossible to parse and often screwup), and entire convention and thinking patterns and programing languages that are line based hardcoded-format concept damage.
The proper solution is margin, in all word processors since 1990, but still rarely seen in programer editors or IDE. (by the way, emacs has it, but san good UI. [see Emacs: Novel Reading Mode http://ergoemacs.org/emacs/emacs_novel_reading_mode.html ])
short line convention created huge number problems with long lasting consequences:
- Unix tools truncating lines silently. e.g. Solaris ps even in 2000s. tar corruption when file path is longer then some 120 chars.
- All bag of tools even today, don't work well with long lines, requiring user to truncate lines.
- All programing languages becomes line based (and created the semicolon complexity), instead of the concept of semantic unit based (e.g. lisp).
- Created silly conventions such as don't touch/reformat any part when u edit code. (else diff would fkup)
- Worsened the entire industry of “style guide”. Even in languages where the author specified designed the lang to be not line based, some hacker idt spread/push a line based style guide for it. (this happens in emacs, elisp, ruby. Forcing programer to manually insert/edit EOL (e.g. paredit))
- It was a big flame war in emacs 2009 when visual line was introduced (by prev leader Stefan Monnier).
- it was also huge flame wars in email/usenet era for over 10+ years, with some people (what you call activists today) that tell people to truncate lines. (e.g. one of the infamous perl guy Chris...)
i've written tens of articles on it since 2000. here's few lead-ins:
- Programing: the Harm of Hard-wrapping Lines
- Emacs Why line-move-visual
- Rants on Emacs Visual Lines by Don Hopkins and Mark Crispin
human perception system
it is the most curious phenomenon. I had a acquaintance friend, on g+, his name is Nick Alcock. He is an emacs/xemacs oldbie, using since i think 1980s, a C expert, and also one of the rare few who uses Maltron keyboard, AND the Maltron layout.
I learned a lot of things from him over the years since g+ started, he is one of the very knowledgeable classic hacker type of the old school, and one of the best thing happened to me on g+. (the other is mathematician John Baez)
everytime i post my typicallly unsual programing opinion and topic , he's got things to say that i find very interesting and sip from. Not the typical hackerdom scriptures that are plastered daily on slashdot reddit hackernews etc.
now, i'v said about the line truncation fak a few times. At first we disagreed and debated, and he alwasy came to understand what i mean, and agree with it. However, whenever this topic came up again next year, he totaly forgot all discussion we had about it, and start by insisting that programer must hit return. Why, because: human eyes this and that.
you see? did u see the word “margin” in my post? but, this word, somehow, just escapes his eye. and we had to start the conversation again all over.
and here on reddit, i now got 2 replies telling me about human eye this and that. No mention of margin whatsoever.
did the eyes of ya all, somehow have a builtin sensor that auto skips the word “margin” when this topic comes up?
yes. I learned over the years, that human animal's perceptive system have builtin filter, that auto skips foreign things before it can reach brain. Like, each person is nice and open and all, however, their eye audo filter out things, so a dialogue is like, in 50% vain.
emacs margin system
Q: should i set margin to 72 chars?
you probably should, set it to whatever width you feel comfortable for reading. (and ~70 is a good max.)
But emacs's margin system isn't great. It doesn't have UI. And set-window-margins takes left and rigth margin as args. You have to calculate your window width to make sure your text is displayed at 70 characters width, and when you resize window such as toggling between full screen, all's screwed up, you have to hook or something to recalculate and refresh.
but maybe the packages posted by u/CbBO8SPZbh:
https://elpa.gnu.org/packages/visual-fill.html and https://melpa.org/#/visual-fill-column
solves the problem.
and there is always the problem of established convention vs better system. The thing is, if you follow logical line break and never hardwrap your lines for display purposes, but everywhere you go, your code, gonna encounter problems among friends, coworkers, and all the tools. They gonna complain, or find you weird, tools screw up (e.g. diff) etc. So if you do coding, it is actually more practical to just damn hardwrap your lines. Like many stupid established conventions, change will come, but like flowing honey, basically wait till old gen die out.
for example, golang, is a big progress here. It has gofmt builtin, which automatically format your code to 1 universal format. And, it advocates tab instead of space for indent. And, it says long lines is good, that we are no longer using punch cards.
Programing Language as Markup Language
am not quite sure what's your argument. Are you nitpicking, or showing a example as to entirely throw away the softwrap concept?
if you hardwrap, then it'll be hardwrapped, e.g. you can hardwrap anywhere in HTML, XML, markdown, org mode, and wordprocessors, etc.
in some of these, there's special markup that forces a line break in display mode, e.g.
programing language isn't a markup lang, but it can be. Mathematica (aka wolfram lang) is a example. Visual languages (e.g. prograph) is another. TeX can also be considered as such. Fortress is a modern example. In these, the programing language run algorithms, but also serves as a presentation format. (jupyter notebook, org mode, are examples)
Depending on how much the language supports markup, there's concept of raw source code vs rendered code. e.g. links in org mode, you can see the raw code vs rendered code.