Bug: Ellipsis substitution inserts a range mark #1143
Comments
|
Hey @tryonkus , thanks for sending in your feedback. I think it is possible to update the Linter to allow the user to pick a style for ellipses to make it use the desired format for them. The code definitely does support that option. But I think I am having trouble following a couple of things.
Normally the Linter will only recognize one format as valid and force everything to be uniform as opposed to allowing multiple different formats for the same thing. So could you elaborate on whether or not you expect the Linter to both allow you to format ellipses a certain way and also list out possible formats to leave as is? Right now that is my biggest hangup on this. Also, as for
Have you looked at using custom replacements for this at this time? The Linter may be able to do this in the future, but my attention is geared towards some performance related changes which may take me some time to get in place. |
|
Hi Peter,Thanks for your prompt response. I was writing in the car yesterday while riding home from vacation and may not have expressed myself as clearly as possible. 🙄In the first item, I was trying to think of all the common variations on ellipses that I’ve seen. There may very well be others I missed. The second item is the core of my request. There are differences in how ellipses are treated in the two major style guides—Chicago and AP—and Linter currently only follows the AP style. I was taught (and prefer) Chicago style, and I’d like the option to make all my ellipses consistent with that. Because some folks prefer the AP style, I suggest making this a choosable option, much like using asterisks or hyphens for bullets.The bit about U+2606 gets really picky. It is labeled as an elipsis in the Unicode standard, but the spacing is even tighter than an AP ellipsis, and I was taught that it is really a range mark (e.g. 2…3 or A…Z). MS Word has led the majority of people to believe it is an ellipsis, but I believe that is mistaken. Much of typesetting is a matter of style and opinion, and I learned graphic design from a typesetter who used wider spaced ellipses. I’d have to do some research to understand the history and current practice completely, but the Wikipedia article is a good start. The upshot is that a user should be able to choose which standard they want to follow and make all their ellipses conform to that. Regarding true dashes, I noticed the regex option yesterday, and you’re correct that I could use that to fix double hyphens. I just need to figure how to leave horizontal rules alone—I should be able to look for exactly two hyphens. I hope that answers your questions. I know this is about picky details, but that’s kinda the whole point of a linter, right? 😏Thanks,Ken===================Ken ***@***.*** +1-585-690-9653===================On Aug 21, 2024, at 8:12 AM, Peter Kaufman ***@***.***> wrote:
Hey @tryonkus , thanks for sending in your feedback. I think it is possible to update the Linter to allow the user to pick a style for ellipses to make it use the desired format for them. The code definitely does support that option.
But I think I am having trouble following a couple of things.
Linter should offer the option to recognize any of the following as an ellipse if checked in settings (there may be other common variations that could be included):
. . .
...
...
Linter should offer the option to follow the Chicago or AP style guides:
Chicago: . . .
AP ' ... '
AP with U+2606: …
Normally the Linter will only recognize one format as valid and force everything to be uniform as opposed to allowing multiple different formats for the same thing. So could you elaborate on whether or not you expect the Linter to both allow you to format ellipses a certain way and also list out possible formats to leave as is? Right now that is my biggest hangup on this.
Also, as for
On a related note, it would be helpful if there was an option for Linter to convert double hyphens (--) to true en (–) or em (—) dashes according to user preference.
Have you looked at using custom replacements for this at this time? The Linter may be able to do this in the future, but my attention is geared towards some performance related changes which may take me some time to get in place.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Describe the Bug
As someone who has set a lot of type professionally, I have strong opinions about ellipses. While the Unicode character, U+2026, is called an ellipsis, according how I was taught, it is actually a range mark. A true ellipsis is composed of three periods separated by nonbreaking spaces.
See: https://en.wikipedia.org/wiki/Ellipsis
How to Reproduce
Type " . . . " in text and run Linter with ellipsis substitution enabled.
Expected Behavior
Linter currently follows the AP Style Guide, sort of—U+2026 is labelled as an ellipsis, but the spacing is smaller than most commercial typesetting. Given that there is a difference in the Chicago and AP style guides (two of the most commonly used) and disagreement over whether U+2026 is a true ellipse, I recommend the following options:
. . ..... . .…This may seem like a picky detail, but if the plugin is going to offer the option to correct badly formed ellipses (which actually is a common problem), it should respect the differences in style guides. Ultimately, it would be best if Unicode added a wide ellipsis character, similar to en and em dashes.
On a related note, it would be helpful if there was an option for Linter to convert double hyphens (--) to true en (–) or em (—) dashes according to user preference.
The text was updated successfully, but these errors were encountered: