AFAIK most computer keyboards don't have em dashes. Rather than hit ALT+0151 every time, I've always just strung along two hyphens, like: --
Absolutely proper and correct use of em dashes, en dashes, and hyphens is, to me, the most obvious tell of the LLM writer. In fact, I think that you can use it to date internet writing in general. For it seems to me that real em dashes were uncommon pre-2022.
This test feels biased by the fact that, like others have said, macOS provides keyboard shortcuts. For example, I'm only Gen Z and yet have tried for many years to use the proper dash characters in the right places, which is made much easier by virtue of being on a Mac.
Of course, I guess it's entirely possible—even accounting for OS—that this test remains statistically useful. It makes me kinda sad that my (very much human-generated) writing fails the Turing test....
Windows does too now via Windows+. which opens the "emoji keyboard" but you can switch to the "symbols" tab to see unicode. It does have multiple dashes in the quick access bar at the top or you can search.
I've used WinCompose¹² to add key composition to Windows for many years (after discovering the concept in Unix-land), which I still find more convenient than the other options I've tried (including the Windows Emoji keyboard).
[2] Though having checked just now, the sequences for en-dash and em-dash don't seem to be working. Perhaps one of my custom macros is interfering somehow… (it is behaving overall, ellipsis just worked as did the following diacritic and other symbols: áèîöūñ±⁰¹²∞¡¿‽π⬚). I'll have to poke at it later and see what is ary.
That has nothing to do with being on a Mac. Em-dashes and the compose-key work fine on Linux, and Android has them under the '-' of the on-screen keyboard when long-pressed.
(Windows probably has some way, but those are rarely discoverable.)
I disagree, there is absolutely no easy way to do it on Windows. You can install a third party program that emulates the compose key but on macos it "just works". And I think that makes a difference for 95% of users
I've always (well...for 20 years) done a Google search for "em-dash" then copy/paste the character off whatever result page come up. Word and other fancy editors always provided a popup pane where these characters could be clicked to insert.
It's a bit funny. On macOS en and em dashes can be natively typed with alt+- and alt+shift+-. The responses to your comment are apparently suggesting these methods are just as easy as that:
1. Install and configure this extra tool, which also by default enables a ton of other things you may not want, and may as well be a third-party tool even though it's technically built by Microsoft
2. Do a Google search and copy-paste (!)
3. Use a keyboard shortcut to bring up a symbol picker, then click on the tab containing the en and em dashes, then click to type them in
I hate that this feature doesn't have a timeout, so when you want to type "--" you have to "- -" and then go back and delete the space. You can't just wait as with double-space vs space-wait-space. It can be turned off, but that turns off other locale-based punctuation like quotes.
Just install a proper keyboard layout with proper typography support once.
It is maddening that the whole world uses typewriter keyboards with some facelift in the era of Unicode and even blasphemous full color emoji font rendering. What has changed in decades? Windows logo key, power keys, media keys, IE and Outlook logo keys — all Microsoft's fancies.
So initially IBM made some ad hoc decisions on what keys would be suitable for a single user office computer (as opposed to data input and admin terminals they had). Then everyone copied that, because sending unexpected scan codes could lead to bad things (random BIOS and program code couldn't care less about your ideas of forward compatibility). Then Windows became the “basic system” installed on most computers. Microsoft really pushed forward the internationalisation at the time, making a lot of national layouts and code pages (sometimes contradicting the national standards, for better or for worse). Then everyone copied what they decided. What's more important, even single byte code pages had the basic typographic symbols, anyone could've been using them for three decades, but they were not added to most physical keyboard layouts.
I wonder if that was because they wanted Word to seem more sophisticated than it was, and to make people think it was a requirement for “proper documents”, or because programmers still treated all non-ASCII symbols as free data markup constants that would “never appear in a regular text”.
Alt+hyphen or alt+shift+hyphen is an endash/emdash. You may not have been aware of it because it's so subtle, but many people (including myself) used emdashes long before 2022
Typing <word><hyphenminus><hyphenminus><word><space> yields an em dash.
Typing <word><space><hyphenminus><hyphenminus><space><word><space> yields an en dash.
That this has been true for some 3 or 4 decades makes me doubt all the comments that em dashes are a "tell" of LLM authorship. On the other hand, I guess when we confine this possibility to web content, I can see how people haven't used Office for web authoring lately, and whatever they do use (like web-based content management systems) don't tend to have this feature.
> Typing <word><space><hyphenminus><hyphenminus><space><word><space> yields an en dash.
More importantly, typing just a single hyphen minus in this constellation triggers the autoreplace, too. (Typing the double hyphen is only necessary without spaces in order to distinguish between an intentional hyphen and an em dash.)
Good point. Either way, it's kind of peculiar that getting an en dash in this manner demands flanking the hyphen(s) with spaces, and those spaces persist after replacement, when the typical usage of an en dash specifically doesn't demand spaces.
From TFA:
> August 1–August 31
From a top comment:
> Boston–San Francisco flight, 10–20 years
To achieve this using the replacement feature we're talking about would take something like <word><space><hyphenminus><space><word><space><alt+leftarrow><bksp><leftarrow><bksp><alt+rightarrow> which is ridiculous.
In professional typesetting, like a book, I sometimes see spaces flanking an em dash, however.
I can't get this to work in Powerpoint. It's funny, I clicked on this thread because I was struggling with trying to make an "emdash" in Powerpoint yesterday and couldn't find the correct search term for the "long hyphen" that I was looking for.
Works fine for me on PowerPoint for Mac, oddly enough. Unrelatedly, Mac also allows easy (non-alt-code) keyboard entry: option-hyphen yields an en dash, while option-shift-hyphen yields an em dash.
That's one of my favorite features of macOS keyboard layouts, but it's so close to one of my least favorite ones – option + space inserting a non-breaking space.
I almost never want that, and when typing "space, en dash, space", it happens quite easily and is usually impossible to tell visually.
`misc:typo` has been in xkb for about 15 years. There's also xkb-birman (matching the current state of the project that inspired all of it). If your national layout does not have level 3 and 4 symbols set, those should work straight away. If it does, it is highly likely that they clash, so you need to create a suitable subset. It is highly advised to find like-minded people, discuss the best options, and then gently push the result to upstream to make it available for everyone. After all, it's Linux, if you won't do it, no one will.
Certain corners of the world have absolutely cared about and employed the proper use of all the “dashes” well before but all the way up to 2022. I’d imagine LLMs have just consumed some of that material.
Pretty much everything professionally edit and typeset does, and those will generally be retained in Unicode text (obviously, not if it gets converted to ASCII). It’s less common in internet fora because not all users either know the use of dashes or have easy access to them on the devices they are using, and if its not both familiar and easy, people are going to skip it in quick messages.
I always use an em dash when possible when I should, and double en dash when I can't, just because I'm that kind of nerd. But it is the case that a double en dash on iOS autocorrects to an em dash, so I'm suspicious of the claim that em dashes are a tell for LLM writing.
Not in all fonts. In most monospace fonts, two hyphens will show with a small gap between them, for example.
I also personally prefer en dashes, surrounded by whitespace on both sides, over em dashes. Apparently some WYSIWYG software interprets two hyphens as an em dash, while other will interpret that as an en dash, so I'd rather just use the real thing if possible to avoid the ambiguity.
I've tried to use real hyphens and dashes since learning a bit about typography roughly 10–15 years ago. macOS makes it really easy with just alt and hyphen for en-dash, shift+alt and hyphen for em-dash. Definitely not an "obvious tell" of an LLM!
Thanks for the '⇧⌥<dash>' tip— from 2022–2025, I have been using macOS en's thinking they were em's.
(Side note: GTP says apostrophes should be used for pluralizing only for single letters to avoid confusion, but this seems more readable than "ens and ems" IMO.)
I recently got accused of using AI for some writing I submitted because I regularly use both en-dashes and em-dashes, and have for years. I said in another thread recently they are second and third, to semi-colons, as my favourite punctuation marks.
I was able to demonstrate my long use of them, prior to LLMs. And since I write in quarto markdown I don't need keyboard shortcuts.
Automatic conversions have been happening for a long time. In fact, a few years ago there was some combination of settings on my terminal locale settings and man (well, troff/groff most likely) was converting hyphens in param definitions to some sort of dash character, meaning I couldn't copy and paste out of the man page. I think it also affected perldoc for the same reason.
I don't doubt there are publishing platforms that do it automatically as well, so I wouldn't count on seeing them as an indicator of generated output, even if it may be processed in some manner.
It's like we spent twenty years writing (mindlessly copying) web pages with &mdash and only viewing them with lynx, and then somebody makes a graphical browser and the mistake is apparent, but I don't think the browser is in the wrong.
While this is true, this is an amazingly silly omission.
Serbian and Croatian XKB keyboard layouts have had em- and en-dashes since early 2000s even if they were not standardized: AltGr (right Alt) + hyphen (to the left of right Shift) produces an em-dash, and press Shift on top, and you get an en-dash.
This is how long I've had them easily accessible on any keyboard (I even have them converted to MacOS keyboard layouts for use with Karabiner).
The lack of em dash usage in popular culture speaks more about typical people than it does about whether a text's author was an LLM. In fact, the average person has never even noticed—let alone considered—that the em dash exists. If they've read for 20+ years, they've seen at LEAST hundreds of them.
Imagine being an NPC (a human bot), flattering yourself with the thought that people who understand the language are language bots...
21% of adults in the US are illiterate in 2024 and 54% of adults have a literacy below a 6th-grade level[1]. “The average person” isn’t really a high bar, unfortunately.
Is this a legitimate institute? The linked article offers many statistics and even financial figures but cites no sources or studies. There is a “TOLL FREE” (capitalized) phone number in the website footer, and the comments are full of prostitution ads.
Not at all. It's just inconvenient for most of the Windows-using world, as the characters are not accessible. It's ALT+[whatever] or Google-it-and-ctrl+V. Hence an awful lot of internet writing didn't really use any of that stuff properly.
Two chained hypens, as was pretty much the norm back then.
And did you just call me an NPC?!? It's not a matter of "understanding the language" at all. It's a matter of convenience and of a sort of evolved convention.
On mac it's very easy to get an em-dash, just alt+shift+`-`. Though I do concur that it's more likely to come from an LLM, I don't think it should be considered a tell — I find it more of a predictor of the writer's age.
That’s interesting to note. I have usually taken the time to properly use en-dashes when it seems appropriate because I frequently deal with strings that represent academic years. At least where I live, these span two calendar years. I have noticed that a lot of college websites tend to use the en-dash properly (e.g. on their academic calendar webpages).
(La)TeX would typeset -- as an en dash. --- gets you an em dash.
I, of course, used proper dashes in typeset documents, at least after I'd learnt about them in Knuth's The TeXbook. I have found myself occasionally use them in ASCII contexts just as ---. But I've never sought out the proper unicode character.
> Absolutely proper and correct use of em dashes, en dashes, and hyphens is, to me, the most obvious tell of the LLM writer.
Or just someone who likes to use the right characters. There was a report a few months back about how writing from autistic kids keeps getting mislabelled as LLM simply because they use the correct specific terms.
Please stop associating being precise with being an LLM.
The option key is IMHO the most underrated feature of the Mac platform. Having another modifier for character input is insanely handy, and I know where to find numerous characters like trademark™, divide (÷), pound (£), degrees (°), pi (π) and so on.
What i've been using: Install https://github.com/samhocevar/wincompose and you can then press AltGr then three hyphens to insert one. or if you're on Linux just search for "compose key".
More sophisticated clients require we use dashes correctly. I first encountered it pre-pandemic, so in professional contexts it's not a sure-fire signal of LLM use — Should you see em dashes correctly used in the Hacker News comments or Reddit, for that matter, then it's pretty reliable tell... Usually. ;)
I'd like to have the record show that I've been using them since before LLMs :)
Not sure when I started; my guess is that I got into the habit of using them in LaTeX when writing my thesis, and then at some point realized that they are easily reachable on standard macOS keyboard layouts (via "option" + "-").
As I mentioned above, I've had them easily accessible with a keyboard layout for >20 years on all the systems I've used — the only caveat that I find it really ugly with no spaces around em-dashes, which is usually recommended for English.
Usually I split it into two sentences, but yes. I don’t really see semicolons used in most business communications, so I treat them as a tell that the text was generated by LLM. Maybe I’m over reacting and prejudiced against semicolon usage.
Most word processing applications auto-substitute EM dashes as appropriate - some do it for two consecutive hyphens, iirc. I don't know if they substitute EN dashes automatically ... I don't know if there's a logic for that without understanding the text.
I've been using real em- and en-dashes for decades, in more or less the way M-W describes. MacOS and iOS make it easy to do, and growing up Mac kindled a life of typographical nerdage.
I wrote for a magazine during college days a few decades ago that uses the Chicago manual of style. I still use em dashes, en dashes, and hyphens regularly. They don't show up as such in markdown, but they are effectively: one dash for hyphen, two for em-dash, and one with spaces surrounding it for en dash.
The default US English Mac keyboard is so extremely good, and has been the way it is for so long, that I remain baffled that other platforms haven't simply copied it. I came to it relatively late in life and it's one of the reasons I wish I'd started using Macs sooner.
It's pretty decent but the fact that I can't type an arbitrary unicode character has been a huge annoyance of mine since I switched from Windows/WSL to Mac.
They have shortcuts for Í, Î, and Ï but not for many commonly used characters like arrows
You can add the "Unicode Hex Input" keyboard layout, which lets you enter BMP characters by holding down Option and entering its code point in hex (similar to the hex entry on Windows). Expanding the Emoji & Symbols pane minitech mentioned also lets you browse by category (e.g. arrows), and you can customise the categories and add a full Unicode character picker (not limited to BMP like the Windows Character Map) there as well.
It's very easy¹ on MacOS to make yourself a custom layout with the characters you commonly use. Personally, I put arrows on ⌥⇧HJKL, vi-style.² (Doing so for Linux is a little more work, as xkb is more complicated and less capable.)
Aside from the solutions other people have mentioned, if you have often-used symbols, you can set up a text replacement in keyboard settings. For instance, I have :x: for the multiplication sign.
Control+Command+Space or Fn+E or Edit > Emoji & Symbols if you know the character’s name. It’s not very convenient for repeated use, but it gets the job done in a pinch.
Yeah it's not great. Edit isn't always there. Fn+E seems to make the most sense. I've heard about ctrl+cmd+space but commonly forget it. Both of those open the same GUI which combines emojis, stickers, and unicode symbols—preferring the first two categories over the last. To type out a unicode symbol it takes at least three clicks on top of me starting to type in the name of my symbol
> Edit isn't always there. Fn+E seems to make the most sense. I've heard about ctrl+cmd+space but commonly forget it.
You can remap Fn/Globe directly to it if you want. It's also accessible from the Input menu bar item if you show that.
> Both of those open the same GUI which combines emojis, stickers, and unicode symbols—preferring the first two categories over the last. To type out a unicode symbol it takes at least three clicks on top of me starting to type in the name of my symbol
Are you using the expanded Character Viewer window[0], or the default collapsed Emoji & Symbols pane[1]? Because the expanded Character Viewer lets you customise and reorder the categories[2] (though that doesn't affect search), including adding a full Unicode view[3]. And they both default to the search bar when opened (though the Character Viewer opens unfocused for some reason).
This specific key combination is not US keyboard specific.
I like how they managed to group characters that are formally similar by binding them to the same keys.
I appreciate that the designer of the layout clearly attempted to make some kind of mnemonic connection to the degree they could. Makes it easier to discover and remember the key-combos, even without a cheat sheet.
That's c-cedille here, because to write English fluently you need to be able to type French loan words like façade—but not quite so often as someone in Switzerland, probably (especially so in some parts of the country!) so I assume you've got it somewhere even more prominent on your keyboard.
It's pretty bonkers (and mildly depressing, really) to imply that correct grammar and usage is a reason to accuse someone of using an LLM.
I mean if it's an obvious break from their normal style, sure. But by itself? Every time I hear this argument, it just seems like sour grapes from poor writers.
For a while, em dashes were really popular among LLM enthusiasts because of the idea that it would encourage the LLM to draw from training data that contained em dashes—which typically were higher quality training data written by a professional writer or somebody with a professional editor. Subjectively, I think it worked. I suspect that the LLMs trained to be used as chatbots were finetuned to use the em dash liberally for that reason. Now, after a few generations of these models, I think that the em dash is starting to have the effect of drawing from "slop" training data that was written by other LLMs rather than well-written human data.
Using spaces is not wrong. Typographically, a hair space or another thinner than usual space is usually used, but in plain text a space is often preferred. Style guides vary of opinion on this, but newspapers often space them. Without a space they end up looking like elongated hyphens joining the words on both sides. That's not their function.
Its not wrong for en-dashes (and en-dash set open—with space on either side—is generally an alternative to an em-dash set closed.) And its not wrong on the trailing side of an em-dash used in dialogue to show an abrupt stop mid-sentence if the stop is followed by a new sentence. And there's a few other particular uses, but, generally, setting an em-dash open is wrong.
> but newspapers often space them.
I've never seen a newspaper set em-dashes open, but I have seen them use en-dashes set open instead of using em-dashes at all. Given the space premium in print newspapers, em-dashes set open, which would consume enormous horizontal space, would, other concerns aside, be an odd choice.
LLMs do use dashes "properly"; it could just as well be argued that you don't: The very article at the start of this discussion mentions that, while thy don't use spaces, using spaces is a valid alternative.
As a diligent user of ALT+0151 for many years on Windoes systems, I can contradict that it is a sign of LLM writing — perhaps in combination with other factors it can be used to increase the likelihood of LLM authorship, but alone, nope.
I'm married to an editor and friends with an editor at work. They both use em dashes appropriately—even with informal writing. I've now learned the keyboard shortcut just to confuse people in the age of AI slop.
A few years back a journal editor maticulously reviewed all dashes in our manuscript and pointed out places where em dashes should have been used. Since then I started noticing different dashes everywhere around the internet.
Absolutely proper and correct use of em dashes, en dashes, and hyphens is, to me, the most obvious tell of the LLM writer. In fact, I think that you can use it to date internet writing in general. For it seems to me that real em dashes were uncommon pre-2022.