[a1369209993]

> Instead, I would prefer a soft semantic wrap

So would I, but...

> if a single semantic unit (be that a word, a clause, or whatever else) extends beyond, say, 80 characters, we keep it on the same line and let the editor/file viewer handle wrapping.

...the editor can't do that because it doesn't understand the semantics.

> that wrapping based on semantics is an orthogonal concept to hard and soft wrapping

Yes, that's why I've been saying "hard and/or soft [but in either case nonsemantic] wrapping".

> > > With semantic wrapping you put each sentence (or similar) on a new line [...] But if that sentence runs over e.g. 80 characters, [then...]

... You don't need to fall back on non-semantic wrapping, you can just just keep breaking it up into smaller and smaller semantically-meaningful pieces.

(You have to do that 'hard'-ly because the editor doesn't understand the semantics, but that's not "decid[ing] whether you're going to hard wrap or soft wrap", it's being forced to hard wrap as a implementation detail because that's what results in correct wrapping.)

It might not be worth the effort to do that, but you're never forced not to (given not-pathologically-short line length limits like 20 characters).

[MrJohz]

Hmm, I think we have different definitions of a semantic line wrap. To me, semantic line breaks means that line breaks are used to separate clauses and sentences, such that at least every sentence is on its own line, and every line break represents a semantic clause or sentence gap.

To you, I get the impression that semantic wraps are about ensuring that every wrap/line break happens at a semantically valid place, where semantically valid could be a semantically valid clause, but also a semantically valid intra-word line break.

In that sense, I can see how your strategy would produce the same effects as hard wrapping, albeit with different choices about where to put the wraps. But I think then, like I said, you end up running into the same difficulties that you do with conventional hard wrapping, at least in pathological cases.

[a1369209993]

> such that at least every sentence is on its own line

Yes, with the obvious possible exception of trivial/degenerate cases like "i++; j--;" in C or "This is a cat. That is a dog." in English.

> and every line break represents a semantic clause or sentence gap.

Specifically, it represents a maximally coarse semantic gap, drilling as shallowly down into subclauses as possible/practical.

> wrap/line break [can happen at ...] also a semantically valid intra-word line break.

Preferably only if that word would already be alone on its overly-long line. Eg:

  # bad, breaks subordinate clause before superordinate
  That sounds supercalifragilistic-
    expialidocious.
  
  # semantically valid, but ugly (a pathological case)
  That sounds
    supercalifragilisticexpialidocious.
  
  # vertically larger, but probably fine
  # (unless you're feeling incunabulum-y[0])
  That sounds
    supercalifragilistic-
    expialidocious.

> you end up running into the same difficulties that you do with conventional hard wrapping, at least in pathological cases.

I've yet to see any evidence that really pathological cases exist. (As opposed to "I'm lazy and can't be arsed" cases, which I'm fairly explicitly not disputing.)

0: http://code.jsoftware.com/wiki/Essays/Incunabulum

[a1369209993]

> given not-pathologically-short line length limits like 20 characters

Poor phrasing; 20 characters was meant as a example of a limit that is pathologically short.