Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not process links within code blocks #3

Open
dubinsky opened this issue Jul 2, 2024 · 2 comments
Open

Do not process links within code blocks #3

dubinsky opened this issue Jul 2, 2024 · 2 comments

Comments

@dubinsky
Copy link

dubinsky commented Jul 2, 2024

Plugin detects and converts to HTML all links that math a regular expression, ignoring boundaries of code blocks.

This makes it difficult to quote a link in such a block (e.g., [[TODO]]) and have the quote display as it should, without being turned into an HTML <a> element. The only work-around I found is to insert an invisible Unicode zero-width space character between the first and the second opening square bracket. If this is the right way to "escape" a wiki-link, maybe it should be documented...

Of course, it would be much cleaner if the plugin did not process the code blocks at all ;)

Thank you!

@manunamz
Copy link
Contributor

manunamz commented Jul 8, 2024

I have spent some time trying to make code span/block handling work, namely by trying to convert the generator portion into a converter -- which seems more appropriate. However, since wikirefs require the url of a target document on render, you need more than just the text given to you to implement wikirefs. In Jekyll, as far as I can tell, this means you need access to the site object while you're rendering. IIRC, converters do not have access to the site object and converters are what would give you the ability to gracefully handle code spans/blocks.

Due to the fact that Jekyll is essentially a legacy system and I don't expect large features or deep architectural refactors any time soon, there seem to be two options here:

  1. Hack out a way to pass urls to converter plugins, most likely from the site object.
  2. Hack out code span/block handling manually alongside the current regex implementation.

I can put the time into this if someone wants to fund these features / the project. I am also open to PRs implementing this functionality.

Your note on escaping wikirefs is a good one and documentation has been added here.

@dubinsky
Copy link
Author

dubinsky commented Jul 8, 2024

Converter does seem more appropriate, but I suspect that in addition to the site object not being available to converters, life-cycle restrictions can also apply...

Backslash-escaping the opening square brackets does not seem to work for me inside the code blocks; if there is a way to enable it that I am not aware of, the work-around would be workable, but if there is no such way, I am kind of stuck, since inserting a zero-width space between the two opening square brackets makes the code inside the code block unsuitable for reuse by copying (in addition to throwing off the code colorizer and making necessary to use editors that actually show invisible characters)...

I do not control any corporate purses, and thus can not arrange any significant funding; I am open to the idea of paying my own money for the features that I need but can not implement; the question is - how much is needed ;)

I do __control the sources of my personal website, and I am not married to Jekyll (although so far all the customizations that I worked on used Jekyll), so if there is some non-legacy system that I can use instead, I'd like to know what it is :)

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants