←back to thread

358 points tkgally | 4 comments | | HN request time: 0.785s | source

The use of the em dash (—) now raises suspicions that a text might have been AI-generated. Inspired by a suggestion from dang [1], I created a leaderboard of HN users according to how many of their posts before November 30, 2022—that is, before the release of ChatGPT—contained em dashes. Dang himself comes in number 2—by a very slim margin.

Credit to Claude Code for showing me how to search the HN database through Google BigQuery and for writing the HTML for the leaderboard.

[1] https://news.ycombinator.com/item?id=45053933

1. chrismorgan ◴[] No.45072623[source]
As #10 on this list, here’s how I do it on my laptop.

I remap a key to the right of Space to Compose, and add various custom sequences. Before long, I was completely comfortably and casually typing dashes and curly quotes and more, and in fact it takes conscious effort for me to limit myself to ASCII when typing prose. (Writing code, writing *, /, -, ' and " is easy. But writing prose, I genuinely will write ×, ÷ if it feels the right one in that place, −, ‘/’ and “/”.)

On one previous laptop keyboard I mapped Menu, on my current one RAlt is more suitable.

When on Windows, I use WinCompose. On Linux, I used to just use it bare, which had advantages and disadvantages—apps implement a Compose key inconsistently, some messing things up related to includes and some handling overlapping sequences differently. More recently I wanted to be able to type Telugu and installed fcitx5 which is no longer mostly broken under Wayland like it was last time I tried, so now fcitx5 is handling the Compose sequences across the entire system, and working more consistently. Also I can use Ctrl+Alt+Shift+U and get a popup where I can search Unicode by code or description. Now if only that pesky popup would handle Shift+Space and Ctrl+Backspace itself rather than letting them fall through to the parent…

In my ~/.config/sway/config:

  input * {
      xkb_options "caps:backspace,compose:ralt"
  }
(caps:backspace isn’t entirely relevant here, but it’s on the same line and I choose to mention it. When people are remapping Caps Lock, I’ve never understood why so many seem to choose to make it Escape. Just extend the left hand and slap the corner of the keyboard with the ring finger, it’s not a huge movement and is easy to reach and return. Backspace, however, tends to be needed at least as often (and yes, I say that despite using Vim), and is much harder to hit. In my mind, a far better candidate for shifting to that prime real estate.)

For my ~/.XCompose, I start with the defaults and one good set of additions, https://raw.githubusercontent.com/kragen/xcompose/master/dot...:

  include "/usr/share/X11/locale/en_US.UTF-8/Compose"
  include "/home/chris/.XCompose-kragen"
Then I add all kinds of additions. Lots of fine typography stuff like zero-width space and non-joiner, narrow no-break space, thin space… a few more hyphen/dash mappings… and lots of other things like nice emoji sequences, music notation stuff, Greek letters matching Vim digraphs, superscript ordinals (ˢᵗ, ⁿᵈ, ʳᵈ, ᵗʰ), the keyboard shortcut symbols macOS uses (⌘⌃⌥⇧⌫ and another dozen less common ones), control pictures like ␆, and a handful of other things.

When all’s said and done:

• Compose - - - gets me — EM DASH (stock)

• Compose - - . gets me – EN DASH (stock)

• Compose - - = gets me − MINUS SIGN (custom)

• Compose - - w gets me ⸺ TWO EM DASH (custom; w for wide)

• Compose - - W gets me ⸻ THREE EM DASH (custom; W for Wider)

The last two I use occasionally, the other three I use very frequently. I went through a phase of using HYPHEN and SOFT HYPHEN, now I seldom use them.

I also like to write &c. (italic where supported) for et cetera.

For quotation marks, I also use custom mappings:

  <Multi_key> <semicolon> <semicolon>   : "‘"   U2018 # LEFT SINGLE QUOTATION MARK
  <Multi_key> <apostrophe> <apostrophe> : "’"   U2019 # RIGHT SINGLE QUOTATION MARK
  <Multi_key> <colon> <colon>           : "“"   U201c # LEFT DOUBLE QUOTATION MARK
  <Multi_key> <quotedbl> <quotedbl>     : "”"   U201d # RIGHT DOUBLE QUOTATION MARK
Think about how you physically type them, and I reckon these mappings make a lot of sense, very easy to type. Much better than the stock bindings (<' >' <" >") or kragen ones (`Space 'Space `` ''; or 6' 9' 6" 9").

—⁂—

(Oh yeah, that one’s <Multi_key> <h> <r> : "—⁂—".)

Now, I have one question I’d like answered. Overlapping sequences. If you have -> → and <- ← you’re fine, but when you add <-> ↔, I can’t find any way of using the <- sequence any more. Before fcitx5, some apps would ignore one or the other (in ways difficult to explain which I think involved the fact that some definitions came from includes), and some would let you terminate the sequence early and match the shorter one (e.g. Compose < - Enter). Is there some proper solution I’ve missed?

I have plans for an article on my keyboard arrangements, including sharing a full .XCompose, but I’m going to finish my next major revision to my website first. Because then I’ll be able to draw things instead of just writing.

—⁂—

On mobile, I think I use FUTO keyboard at present, which lets me access most of these things, but not elegantly. I want to make my own keyboard layout that lets me access the good stuff more easily, but I haven’t got to it yet.

Also: anyone want to join me in advocating for completion dictionaries and libraries to replace their ' apostrophes with ’, or at least to support both approaches equally? I’m fed up with not having this stuff, Vim is the only place where it was straightforward to get it about right, and mobile is just a mess.

replies(2): >>45072935 #>>45074283 #
2. lostlogin ◴[] No.45072935[source]
I’m no longer concerned you’re an AI, but I am concerned.
3. frumiousirc ◴[] No.45074283[source]
> If you have -> → and <- ← you’re fine, but when you add <-> ↔, I can’t find any way of using the <- sequence any more.

X11 is likely walking a tree of .XCompose entries with each keypress. Once it gets to '<' and '-' it finds '←' and does not continue to consider your next '>'. So, you need to provide a way to walk a different path.

This works for me.

    <Multi_key> <less> <period> <greater> : "↔"
It is like how EN DASH is "--." to be distinct from EM DASH's "---".

In general we must consider the entirety of .XCompose when choosing new compose key bindings. Maybe there is some utility to help with that. For me, I removed 98% of the default Compose file entries which makes manual checking feasible.

replies(1): >>45074855 #
4. chrismorgan ◴[] No.45074855[source]
There is no X11 involved here, and even on systems running an X server instead of Wayland, judging by the symptoms I’ve seen, the X server isn’t actually involved in interpreting Compose sequences—each app implements the whole lot itself, and judging by the inconsistencies, not all are using the same library for it.

Some only let Compose < - (←) work, stopping and preventing Compose < - > (↔) from working. Others, if I remember correctly, let Compose < - Enter work to get ←.

Once an Input Method is involved, it can handle the Compose key, and that’s what fcitx5 is doing for me now, so that everything’s behaving the same… but that “same” is not what I reckon it should be.