Velocity Reviews - The Harm of hard-wrapping Lines

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)

- C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)

- - The Harm of hard-wrapping Lines (http://www.velocityreviews.com/forums/t437857-the-harm-of-hard-wrapping-lines.html)

The Harm of hard-wrapping Lines

The Harm of hard-wrapping Lines

20050222

Computing Folks of the industry:

please spread the debunking of the truncating line business of the
****ing unix-loving ****heads, as outlines here:
http://xahlee.org/UnixResource_dir/w...cate_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 don'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 an
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 (e.g. many
languages's line comment; and cannot be nested), and the misleading
and harmful habituation in IT of sizing software by
EOL-counting. (both of these are hindrances to 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, the programer 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 simple parsing. Some 90% 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 consequence 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 algorithm. 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
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.
(and the language happens also to display typeset mathematics on the
fly.)
Similar mileu 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, even their
languages are potentially immune to the hard-wrap problems.
)
)
)

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

---------
This email is archived at
http://xahlee.org/UnixResource_dir/writ/hard-wrap.html

Xah
xah@xahlee.org
∑ http://xahlee.org/