The Harm of Hard-Wrapping Lines (80-Characters Per Line) (2005)

Computing Folks of the industry:

Please spread the debunking of the truncating line business of the
fucking unix-loving fuckheads, as outlines here:
http://xahlee.org/UnixResource_dir/writ/truncate_line.html

If this myth-debunking is known widely enough, there wouldn't be any
more line truncating business.

Emacs community has always been a thinking community as opposed to the
unix criminals. However by historical happenstance, the emacs of GNU's
Not Unix is essentially a program for unixes, so unavoidable it has to
deal with and inherit some of the ill shits of unix, if for nothing
but to be practical.

However, as of today, emacs doesn't really have reason to have
arrow-down behavior to be dependent on the hard-coded line wraps. I
want the next emacs version's down-arrow behavior to be fixed. (and
optionally as another mode to move by EOL.)

The reason for this change is easy. For those habituated with hard
wrapped lines, this would cause no difference. However, for those who
have lines that return at logical places, this would be a
improvement. (This is the intuitive way, and all non-geek editors
behave this way, even most editors or IDEs designed for programing.)

The need in this change is significant. By the current behavior of
down-arrow by EOL char, it discourages logical line breaking,
encourages hard-coded line breaking, and engenders the huge and
wide-spread problems as a consequence (as partially detailed in the
url given above): Programs posted online are broken, the who-said-what
quoting systems are a mess to process and comprehend, and needless
complex programs that processes and re-process the hard-wrapped
lines… And also it seeds the bad notions by creation of a generation
of imperative languages based on hard-line wraps (For example, many
language's line comment; and cannot be nested), and the misleading
and harmful habituation in Info Tech of sizing software by
EOL-counting. (both of these are hindrances to the prosperity of
functional programing.)

Further, in programing there's large chapters and energy spent on
what's called “coding style”, which refers to the petty issue of when
and how to press a return so the lines all jag in some uniform
way. This ubiquitous “coding style” activity is helped by the
hard-wrap habit of thinking, which created these EOL-centric language
syntaxes in the first place.

(When coding in a programing language, programers should never have to
enter returns for the sake of display-formatting. The language's
syntax and the editor should be able to display the code well on the
fly by a brainless parsing. Some 70% of EOL in codes today are there
manually entered by programer that does not serve any function other
than hard-coded pretty-printing.
 (as oppose to the sometimes a intentional return to make a point in
  the code, either as logical break, or emphasizing a section.)

And as a psychological and practical effects of these EOL-centric
languages is that attention are put on code by the lines, instead of
functional or logical units. For example, comments tends to be based
on lines of code, as opposed to on a functional unit or algorithmic
block. Boolean clauses inside IF clause each span a line, as opposed
to being together as a predicate unit.
 (which smother new developments of such predicate unit in language
  syntax or semantics)
IF blocks almost always span multiple lines, as opposed to the idea of
a single coherent unit of “if PREDICATE do BLOCK”.
 (and such EOL-centric code tends to engender practices such as
  calling and setting global variables here and there inside code
  blocks).
 Temporary variables occupy a line by themselves, as oppose to tucked
 inconspicuously inside its functional unit… etc and so on.

 (a example of a language that is not EOL-centric is Mathematica,
  which displays the code with sensible justification, all done
  automatically behind the scenes, just as a word processor is to
  writing.

  Similar milieu are in LISP languages, but they did not push this idea
  further.

  (That is to say, in LISP communities, they on occasion still do and
   talk about the petty issues of manual return-pressing for style, even
   their languages are potentially immune to the hard-wrap psychology.)
 )
)

I hope the above is some elucidation on the hard-wrap and
line-truncation business. Please spread the info.