5 ms·

I took up a similar style for most of my writing perhaps a year ago, with a strong preference for breaking at punctuation. (I even sometimes do it to a more lim

I took up a similar style for most of my writing perhaps a year ago, with a strong preference for breaking at punctuation. (I even sometimes do it to a more limited extent in handwriting.) This has influenced my writing style, which naturally inclines to more complex structures, to favour shorter clauses—though certainly I still end up with plenty of non-punctuation-adjacent line breaks. My greatest annoyance with the style (which honestly is the sole reason I didn’t take it up a few years earlier) is bad handling of em dashes, of which I am fond. In normal English typesetting, there is a line-breaking opportunity before and after the dash, but no space; but in all markup languages that I know of that support soft breaks, the line break is equivalent to a space. Well, actually this is no longer normative for HTML (see https://www.w3.org/TR/css-text-3/#line-break-transform https://www.w3.org/TR/css-text-3/#line-break-transform, which shows the problem for CJK, which doesn’t use spaces between words), but for now, all user agents still implement it as “line break → space”. Consequently, when writing in these markup languages, I can’t break the line after an em dash as I would like to, because it would change the output. One of the features of the lightweight markup language I’ve been designing, then, is the ability to control soft break behaviour in order to correctly handle at least CJK and em dashes that were not otherwise paired with a space. (And I’m curious if anyone has similar cases not well-served by current rules.) —⁂— (If you’re not sure what I’m talking of: source: Example: an em dash— like this. Expected result: > Example: an em dash—like this. Actual result in the likes of HTML, Markdown and reStructuredText: > Example: an em dash— like this.

yakubin 4y ago
Shouldn't an em dash be surrounded with spaces on each side anyway?
- kqr 4y ago
  Not in English. The two equivalent English alternatives -- as far as I know -- are the en dash surrounded by spaces---or the em dash with no space. I actually like the look of the em dash with no space better, but for the reasons mentioned in the GP I end up using the en dash anyway. (Another reason is that Swedish, which I also write, only has the en dash, so its nice that I can be consistent.)
- kragen 4y ago
  i've read a lot of books professionally typeset in english that either do or don't space around em dashes — used to denote pauses, in the way we are discussing here. my preference is to space around them, but i prefer using \u2009 'thin space' instead of a full word space. unfortunately hn rewrites that to a full word space.
  - chrismorgan 4y ago
    I don’t think I’ve ever seen a professionally-set work using spaces around em dashes. The two popular conventions are space–en-dash–space (“a – b”) and em-dash (“a—b”). I only recall ever encountering space–em-dash–space a few times (one of which was within the last few days, and the previous was probably years ago), in amateur work. THIN SPACE would certainly make me much more amenable to it, but frankly that suggests a font problem (and I do certainly know of fonts where the em dash spacing is awful and if forced to use that font I would insert THIN SPACE (or very occasionally NARROW NO-BREAK SPACE) every time).
    - shanebellone 4y ago
      Might the em dash convention be a byproduct of the printing press and fixed-width layouts?
      - kragen 4y ago
        not in a way that is obvious to me
        shanebellone 4y ago
        The spaced em dash occupies 10% more space. The traditional syntax is particularly suited for newspapers who valued typographic density.
        kragen 4y ago
        oh, i see what you mean now but wouldn't that still be the case if you were handwriting your newspaper and xeroxing it or something where does the printing press come in also though i don't think fine typography is mostly determined by newspapers
layer8 4y ago
> One of the features of the lightweight markup language I’ve been designing, then, is the ability to control soft break behaviour What does your design for that feature look like?
- chrismorgan 4y ago
  I’m not certain yet; although I’ve been writing all my own stuff in this language for months now, my actual implementation is mostly unfinished. (The only piece that’s fully finished is list markers, which are based on CSS Counter Styles Level 3 plus parsing, so you can use e.g. cjk-decimal or bengali numbering in the source and it’ll retain that style in the output, correct values and all.) For this particular aspect, I’m still undecided on how best to actually implement it. The most likely approach is to hard-code rules (possibly in a couple of groups, e.g. “CJK” and “other”), with the ability to opt into or out of them as part of dialect configuration (which is a bit like how you can define custom roles or change the default role in reStructuredText, but more general, able to change more aspects of the language’s syntax—things like change *…* to be something other than italic, make ~…~ strikethrough, define new counter styles). You could also generalise some form of declarative line-break-collapsing rule like “if preceded and succeeded (after whitespace trimming) by a character with Unicode property East_Asian_Width ∈ {Fullwidth, Halfwidth, Wide}” or “if the preceding line matches /(?!< )—$/” or “if preceded by U+200B (ZWSP)” (this last example borrowing from https://www.w3.org/TR/css-text-3/#line-breaking https://www.w3.org/TR/css-text-3/#line-breaking, basically applying the formatting rules in reverse for parsing, similar to what I’m proposing with the em dash and doing with Counter Styles; when laying out, ZWSP introduces a line break opportunity without adding a space, so when parsing ZWSP and a line break, you clearly shouldn’t add a space). But unless I can be convinced of actual value in generalising it, giving just one or two switches is likely to be the most sensible implementation, for complexity (this will probably be an optional feature, incidentally), manageability and performance.
deleted 4y ago
[deleted]

yakubin 4y ago

Shouldn't an em dash be surrounded with spaces on each side anyway?

kqr 4y ago
Not in English. The two equivalent English alternatives -- as far as I know -- are the en dash surrounded by spaces---or the em dash with no space. I actually like the look of the em dash with no space better, but for the reasons mentioned in the GP I end up using the en dash anyway. (Another reason is that Swedish, which I also write, only has the en dash, so its nice that I can be consistent.)
kragen 4y ago
i've read a lot of books professionally typeset in english that either do or don't space around em dashes — used to denote pauses, in the way we are discussing here. my preference is to space around them, but i prefer using \u2009 'thin space' instead of a full word space. unfortunately hn rewrites that to a full word space.
- chrismorgan 4y ago
  I don’t think I’ve ever seen a professionally-set work using spaces around em dashes. The two popular conventions are space–en-dash–space (“a – b”) and em-dash (“a—b”). I only recall ever encountering space–em-dash–space a few times (one of which was within the last few days, and the previous was probably years ago), in amateur work. THIN SPACE would certainly make me much more amenable to it, but frankly that suggests a font problem (and I do certainly know of fonts where the em dash spacing is awful and if forced to use that font I would insert THIN SPACE (or very occasionally NARROW NO-BREAK SPACE) every time).
  - shanebellone 4y ago
    Might the em dash convention be a byproduct of the printing press and fixed-width layouts?
    - kragen 4y ago
      not in a way that is obvious to me
      - shanebellone 4y ago
        The spaced em dash occupies 10% more space. The traditional syntax is particularly suited for newspapers who valued typographic density.
        kragen 4y ago
        oh, i see what you mean now but wouldn't that still be the case if you were handwriting your newspaper and xeroxing it or something where does the printing press come in also though i don't think fine typography is mostly determined by newspapers

layer8 4y ago

> One of the features of the lightweight markup language I’ve been designing, then, is the ability to control soft break behaviour What does your design for that feature look like?

chrismorgan 4y ago
I’m not certain yet; although I’ve been writing all my own stuff in this language for months now, my actual implementation is mostly unfinished. (The only piece that’s fully finished is list markers, which are based on CSS Counter Styles Level 3 plus parsing, so you can use e.g. cjk-decimal or bengali numbering in the source and it’ll retain that style in the output, correct values and all.) For this particular aspect, I’m still undecided on how best to actually implement it. The most likely approach is to hard-code rules (possibly in a couple of groups, e.g. “CJK” and “other”), with the ability to opt into or out of them as part of dialect configuration (which is a bit like how you can define custom roles or change the default role in reStructuredText, but more general, able to change more aspects of the language’s syntax—things like change *…* to be something other than italic, make ~…~ strikethrough, define new counter styles). You could also generalise some form of declarative line-break-collapsing rule like “if preceded and succeeded (after whitespace trimming) by a character with Unicode property East_Asian_Width ∈ {Fullwidth, Halfwidth, Wide}” or “if the preceding line matches /(?!< )—$/” or “if preceded by U+200B (ZWSP)” (this last example borrowing from https://www.w3.org/TR/css-text-3/#line-breaking https://www.w3.org/TR/css-text-3/#line-breaking, basically applying the formatting rules in reverse for parsing, similar to what I’m proposing with the em dash and doing with Counter Styles; when laying out, ZWSP introduces a line break opportunity without adding a space, so when parsing ZWSP and a line break, you clearly shouldn’t add a space). But unless I can be convinced of actual value in generalising it, giving just one or two switches is likely to be the most sensible implementation, for complexity (this will probably be an optional feature, incidentally), manageability and performance.

deleted 4y ago

[deleted]