retext-spell error on autolink about remark-retext HOT 6 CLOSED

Thanks for the detailed info!

There are several “constructs” in language which are fine being ungrammatical: emoji, URLs, @mentions, and more. For those three, there are separate plugins that you can use before retext-spell: retext-emoji, retext-syntax-mentions, and retext-syntax-urls.

Could you try and see if that works for you?

from remark-retext.

Alright, I’ll close this then! Glad it now works for you.

I was still thinking about your previous comment. I understand your mental model, which is indeed different from how it technically works in Markdown (and thus in this project).

And I don‘t think we should change <link> → ``: Spell checking isn’t the only reason to get the natural language from Markdown. In other cases, it makes sense to instead have link. And if you don’t care about as words/punctuation/symbols, then `retext-syntax-urls` can be used.

Appreciate the discussion too! Stay safe

from remark-retext.

Ah, I see. Indeed, that does work:

--- a/package.json
+++ b/package.json
@@ -12,6 +12,7 @@
     "remark-stringify": "8.1.0",
     "retext-english": "3.0.4",
     "retext-spell": "4.0.0",
+    "retext-syntax-urls": "2.0.0",
     "unified": "9.0.0",
     "vfile-reporter": "6.0.1"
   }
--- a/index.js
+++ b/index.js
@@ -10,6 +10,7 @@ unified()
     require('remark-retext'),
     unified()
       .use(require('retext-english'))
+      .use(require('retext-syntax-urls'))
       .use(require('retext-spell'), {dictionary: require('dictionary-en')})
   )
   .use(require('remark-stringify'))

That solution makes a lot of sense when you might also have URLs floating around your content. And, of course, I'll use it. But I would expect (naively, perhaps?) that a URL in an autolink would not get translated to text in remark-retext. Out of curiosity, how does the syntax translation work in this case?

from remark-retext.

Hmm. I view autolinks (<https://example.com>) somewhat as a shortcut for “normal” links ([https://example.com](https://example.com)), as they behave exactly the same (and are also a bit inferior: they don’t have an accessible label but instead print the whole URL). Specifically, in the syntax tree, they’re the same. The fact that the tree is lossy (AST vs CST), is mostly a benefit: it makes it much easier to deal with trees, or for example to change heading without having to deal with how they were originally written. So this project has no knowledge of whether something was a literal URL, autolink, reference link, or “normal” link and hence does no translation.

I would expect [...] that a URL in an autolink would not get translated to text

Should [https://example.com](https://example.com) have the same behavior? How about https://example.com?

from remark-retext.

Should [https://example.com](https://example.com) have the same behavior? How about https://example.com?

I guess it depends on what you want to do with the text. If you expect to work with natural language based on the input syntax of Markdown, then these are the kinds of translations I would think of, at first blush:

• <link> →
• [label](link) → label
• link → link

That is, the syntactic link (not the implicit link) in the source is not found in the target. Is it ever necessary? That may the part I'm missing. But I'll certainly admit that my mental image of a translation is less flexible, because it drops more information than the existing concrete translation.

from remark-retext.

To update, I consider my specific problem to be solved by using retext-syntax-urls, as shown in #13 (comment).

The rest of the above conversation could be considered out of scope or food for thought in future development. (Thanks for the discussion!) You are welcome to close this issue or leave it open, whichever you prefer.

from remark-retext.