LInk parser lowercases identifiers about remark HOT 25 CLOSED

Nope, it has to do with the matching of references to definitions. What is your use-case?

from remark.

I'm writing a plugin for Atom (https://atom.io/packages/zotero-citations) that uses the identifier to store the citation keys for a scholarly markdown processor. It changes (currently by regex mangling, trying to move to mdast) [...][@TayEA11] into [(Taylor, 2011)], and adds a full bibliography at the end of the document.

The citation keys are case-sensitive however (whether that's a good idea or not is a debatable of course), so I don't find any matches after the parse. I suppose I could just make the references something like http://TayEA11, but that is not as easy to type duriing writing.

Is there another format I could use in the link field that would retain case? Or another construct I could abuse? The link seemed ideal because it types quite naturally, it's valid markdown as-is (so can be sent through pandoc etc for typesetting), it renders quite nicely to the expected output, and there didn't seem to be (until now) negative side effects.

from remark.

How about [@TayEA11][]? There, the text would be @TayEA11 (which your plug-in will change later), and the reference name will be a normalided version of that.

Would that work?

from remark.

The problem with that (I think) is that the process is not repeatable; my plugin changes the text in the editor in-situ, so it must be runnable any number of times on the editor contents.

from remark.

Hmm okay. And it’s not possible to detect both the short-cut (@TaeEA11) and the replacement, and reprocesses them?

from remark.

Possible, yes, but the citation keys would be present in the final output, which is undesirable. I'm making a change to the backend to do case-insensitive lookups -- not ideal, but probably an edge case.

from remark.

If that’s possible than that would probably be the simplest and ideal. It might be possible to keep the case-sensitive identifier in the node, but it would make looking up the definitions by other plugins a lot harder! Duplicate data is also possible, but not very ideal 😦

from remark.

I have the case insensitive lookup working, but LaTeX authors are notoriously attached to their citekeys with a near religious zeal. If at all possible, would it be possible to have the original unscrubbed identifier text in a separate field rather than replacing the identifier?

from remark.

Wait, you can still write with case intact, and insert with case intact right? Just the look-up part is case-insensitive?

from remark.

True, but if the reference manager has both Dear11 (perhaps from the company name John Dear) and deAr11 (probably someone named "de Ar"), it would pick one at random.

Again, probably (sensibly, even) an edge case, but my users usually have along history of articles and I'd rather not have them in a position where they'd have to change existing keys to accomodate my plugin. Any assumption I've made so far on "surely they won't have this in their citation keys" has been struck down.

from remark.

Ah and no, as I use .process to render back to markdown, the actual user input gets changed. I don't want to insert the resolved keys because not all keys are sure to be found and I'd replace them with empty text, thereby changing the meaning of the text as the user typed it (changing a reference is bad bad stuff).

from remark.

An alternative is to access the raw source from the file (file.toString()) and use the position on nodes to access the definitions. It’s a bit more raw, but works. Here’s an implementation for definition nodes in mdast-lint.

from remark.

That would work (and I don't mind raw), but it would still mean the re-rendered markdown would have the keys lowercased.

All the rest works wonderfully. Is there anything I can stick in that field to make mdast think it's not an identifier?

from remark.

But mdast also lowercases URLs; http://www.google.com/X gets turned into http://www.google.com/x. That can't be right, right? URLs are not case-insensitive by specification.

from remark.

There’s no logic to remove casing when stringifying: https://github.com/wooorm/mdast/blob/eb0e8a7bf57a94085992786a2c7d9739503d7cc3/lib/stringify.js#L1407. If you can access the raw value, you can replace the lower-cased identifier with a cased identifier and it should work?!

from remark.

Hold on, would it be as easy as changing to [](@Tay)?

from remark.

That seems to work: http://mdast.js.org/demo/?text=%5B%5D(%40Tay123123)%0A

from remark.

And I don’t see mdast changing the case of links

from remark.

That's because I forgot the difference between hyperlinks and reference links: http://mdast.js.org/demo/?text=http%3A%2F%2Fwww.google.com%2FX%0A%0A%3Chttp%3A%2F%2Fwww.google.com%2FX%3E%0A%0A%5Ba%5D(http%3A%2F%2Fwww.google.com%2FX)%0A%0A%5Ba%5D%5Bhttp%3A%2F%2Fwww.google.com%2FX%5D%0A

And I want the resulting link to stably be a reference-type link; I point the link to the generated bibliography, which looks something like

[#bibliography]: #start
[@TayEA11]: #latour_ny_2008 "Latour, B. (2008). _En ny sociologi for et nyt samfund. Introduktion til Aktør-Netværk-Teori_. København: Akademisk Forlag. (Original work published 2005)"
<a name="TayEA11"></a>Latour, B. \(2008\). _En ny sociologi for et nyt samfund. Introduktion til Aktør\-Netværk\-Teori_. København: Akademisk Forlag. \(Original work published 2005\)
[#bibliography]: #end

But I'm thinking perhaps something like [](#TayEA11) could do the trick... but that now makes me think that this really only works for single references, not for [](#TayEA11,#Latour2008). Hmm.

from remark.

Why wouldn’t it work for multiple references? e.g., [](TayEA11,Latour2008). just comma split?

from remark.

It would, but the resulting link would point to the non-existent anchor TayEA11,Latour2008. I think that is just something my users will have to live with -- I'll change the code to allow for both #key and @key; if they want working target links, they'll have to use the #key format with only single links.

Thanks for your superb help BTW. I'm much more confident about tackling the atom plugin using mdast.

from remark.

Cool 👍, great to hear, so I can close this?

from remark.

Yep, super thanks.

from remark.

Great, ping me if you run in to more problems 😄

from remark.

Will do!

from remark.