Follow resolvable hyperlinks about zettlr HOT 17 CLOSED

because of the negative lookahead, which is still unsupported in ES6

Slight confusion I think - negative and positive lookahead are fully supported in all browsers all the way back to Internet Explorer <10 (we use them in Kiwix JS and Kiwix JS Windows all the time). It's positive and negative lookbehind that are not supported, and Chrome has just introduced them -- see https://www.regular-expressions.info/javascript.html (search for lookbehind on that page). Btw, I strongly recommend RegexBuddy, as it allows you to test regexes for every language and even different browsers. Well worth it for a developer!

from zettlr.

Hee, hee, Microsoft moves in mysterious ways... Some intern probably said "This keyboard looks way too crowded... Who uses the alt key anyway?", and deleted it. Since they fired all their quality assurance testers, no-one noticed.

Anyway, "it would be nice", but don't spend a lot of time on this marginal use-case. May be worth a separate issue so you can close this one.

from zettlr.

it is a bit surprising that Zettlr can follow a link to another file constructed with Wiki-style links like this

It's magic =D

No, seriously, I see your point. As anchored links are already correctly displayed and clickable, this would be only natural. If you have time, would you mind looking into how Pandoc actually determines these automatically generated link targets? If so, it would be easier for me to implement, as I don't have time to research currently.

Concerning the relative default links, I have two questions. First, what benefit do you see in using relative links to other Markdown files? And second, what is Zettlr supposed to do with them on Export?

Always remember that anything I change in the DOM of the editor to render images, click links, display citations, etc. pp. is only meant for previewing purposes and must be constructed in such a way that it does not significantly alter the structure of the document in a way that it becomes a foreign language to any other interpreter.

I see the difficulty that by allowing all sorts of redirect-links, it becomes more and more difficult to blindly trust that the Markdown is so standardised that you can paste it somewhere else and it will also understand it correctly.

from zettlr.

@nathanlesage I completely understand there is a lot still to do on Zettlr, so this is not high priority, but since you asked...

The rules for constructing the links are explained here:

http://garrettgman.github.io/rmarkdown/authoring_pandoc_markdown.html#extension-auto_identifiers

However, you don't need to construct such implicit links, just follow them. To match a header from an auto-generated link, I'd do something like this:

var hash = '#tangos-photography-and-film';
// Turn the hash variable into a new regular expression to match the corresponding heading
findHeaderFromHashRegExp = new RegExp( '#\\s[^\\r\\n]*?' + 
          hash.replace(/-/g, '[^\\r\\n]+?').replace(/^#/, '')', 'i' );
// The new regex should now match the corresponding heading in the document
document.match(findHeaderFromHashRegExp);

This works by turning the string of the hashed link into a regular expression: simply by replacing hyphens with [^\r\n]+? (= match any character that is not a carriage return or a line-feed at least once and as many times as possible, non-greedy). It won't go past a line-end even in different systems using different line-end characters. So '#tangos-photography-and-film' becomes the regex
/#\s[^\r\n]*?tangos[^\r\n]+?photography[^\r\n]+?and[^\r\n]+?film/i which in turn will match
'# Tangos, Photography, and Film'.

NB, just wrote this quickly, I haven't tested it, and some escaped backslashes might need an extra escape added to them, it's difficult to be sure till actually testing.

Hope it doesn't look like monkey-wrenching!!

Regarding the standard markdown hyperlink syntax (link)[files/document.md], that's actually more standard that [[document]] for markdown files, no? So I don't think you'd be polluting the markdown by supporting it.

As I say, it's not high priority!!

from zettlr.

Ha, an interesting discovery: it's possible to support the standard markdown syntax for navigation, like
[1 Title Page](1 Title Page) just by entering ]( for "Link start" and ) for "Link ending" in Preferences -> Zettelkasten. However, it would be nice to support this syntax also without breaking the Zettelkasten feature support.

In any case, this syntax makes it posible to have a separate Table of Contents, in a file by itself, and use it to navigate to any document, and still look readable (the [[..]] syntax doesn't looks so good in a T.o.C.). You do have to click twice into the links. Example:

from zettlr.

Uhh, pretty interesting idea to simply convert the links to RegExes! Nice one 👍 And thank you very much for your research, I'll see to it in some time!

And concerning your Wikilinks-Hack: Didn't think of this, but of course it does make sense.

Regarding the standard markdown hyperlink syntax (link)[files/document.md], that's actually more standard that [[document]] for markdown files, no? So I don't think you'd be polluting the markdown by supporting it.

I'm still unsure. Markdown is a Source-code-file, meant to be exported to another format, and not a finally rendered HTML/PDF/DOC/whatever. This means: The relative file links to other Markdown files will be invalidated during export, because something will change with the target file as well. And I think that Markdown hasn't been made to support file linkages after all, so I think hacking Markdown links like that would indeed "pollute" the Markdown in some way. Links should always be in the format they are supposed to after export, not prior to it.

It is because of this that I decided to implement Wikilinks: They are definitely not standard, but are ignored by parsers and can be easily removed from files prior to exporting them (as the settings in Zettlr allow you to do already).

An example: If you decide to export some files to another format that contain these "special" links, this will result in you having several dead links inside the exported file — but you can't tell from only looking at the link; you'd have to click a link to see that your browser tells you that it can't open the target. If you only use Wikilinks for these internal links, you won't have that problem.

But you know what I suddenly realised? Markdown in Zettlr has evolved so far that it is more and more used not as a source file to compile to something else, but as a standalone file that just … stays Markdown and is never to be exported. There you see what impact on a human's perception auto-previewing of links, images, etc. can have!

from zettlr.

The relative file links to other Markdown files will be invalidated during export, because something will change with the target file as well. And I think that Markdown hasn't been made to support file linkages

You're right, I actually thought that pandoc would convert links to other markdown files that are also being converted in the same batch, but I see that it doesn't do this without a custom filter: https://stackoverflow.com/questions/40993488/convert-markdown-links-to-html-with-pandoc . So that does indeed create a difficulty.

Nevertheless, I'm happy that I can sort of customize Zettlr to make linking work for my own needs as per the TOC screenshot shown above. It would work even better if: (a) Pandoc would attempt to follow a link of the type shown in the screenshot above when clicking on it (if it understands what it is linking to) -- i.e., not force me to click twice, once to open the outer link, and another time to open the inner; and (b) if the setting shown in the screenshot below were actually a single editable regular expression, in line with the other settings on the page:

So, if you allowed a regex, for your Wiki-style [[…]] format, it should look like this:

Link regular expression:
\[\[(?:[^\]]|](?!]))*]]

That looks hairy, but it just means: select [[ then anything that is either not a ], or a ] not followed by another ], as many times as possible (or not at all), then select ]].

By the way, there's currently a bug if a link contains square brackets in the link -- yes, I know it's a poor choice for a document title, but with researchers in the Arts and Humanities, I've seen them name files Doc about 'space' & cities (& time and $$!!!) [edited 4th July] .old .docx (a Linux nightmare...). The regex above ought to solve that bug.

from zettlr.

Nevertheless, I'm happy that I can sort of customize Zettlr to make linking work for my own needs as per the TOC screenshot shown above.

Yeah, your damned hack :D But I like your approach, though. It is indeed creative!

(a) Pandoc would attempt to follow a link of the type shown in the screenshot above when clicking on it

Pandoc will never be able to allow you to click on links, because it is just a converter. What you mean is the previewer that I've written for the CodeMirror-Editor :P

And yes, the anchor-linking is a good idea and that will be implemented (b/c such links don't need to be converted, and they can even be used to create a custom TOC, because Pandoc will attempt to convert such "file internal" links automatically to clickable links, even inside PDFs).

(b) if the setting shown in the screenshot below were actually a single editable regular expression, in line with the other settings on the page:

Yes, and no. I've thought about that, but actually, this way it's extremely easy to implement certain things in Zettlr, which would not be possible with a regular expression:

• Automatic removal of internal Links on export
• Not accidentally assume an ID that is inside a link to be the ID of the very file
• Some other magic that wouldn't be able with a single expression
• Letting users w/o any knowledge of Javascript regular expressions easily manipulate this thing.

\[\[(?:[^\]]|](?!]))*]]

I promise you that this won't work, because of the negative lookahead, which is still unsupported in ES6. This has been a pain in the ass for me, because these would make writing code so much easier, as I could remove a ton of if/else clauses that I currently need to re-check a RegEx-Match afterwards to emulate that lookahead/lookbehind behaviour.

regex101.com is pretty nasty in that regard because they already implemented the RFC, although not even Chrome supports this yet (the respective RFC is from … May, if I'm not mistaken).

By the way, there's currently a bug if a link contains square brackets in the link -- yes, I know it's a poor choice for a document title, but with researchers in the Arts and Humanities, I've seen them name files Doc about 'space' & cities (& time and $$!!!) [edited 4th July] .old .docx (a Linux nightmare...). The regex above ought to solve that bug.

Oh dear … yeah, I've seen such file names, a nightmare indeed. But in this case I'm playing the educational card: It's not I who should adapt the software to such an extend that the worst behaviour of people is actually rewarded, but it's them who should learn how to damn name their files. While I try to make the entry into the world of Markdown, Pandoc, and LaTeX palatable, I won't make software that basically tells them "Oh, you have no sense for what a computer might do? You want to use characters inside filenames that don't work on any Windows computer? That's fine, I'll just clean up everything behind you!"

That is the work of Microsoft to do, not mine.

from zettlr.

Ahh, that is so great news. This means it'll only take some more weeks until the electron guys deliver the current chrome version until I can finally flatten out my code :)

This would then also make it possible for me to have link previews not render links if they are escaped. (Or, for that matter, anything)

from zettlr.

Just implemented your regexy-thing, and it seems to work rather well!

Please feel free to test some edge-cases, but it should work now :)

At least your Tango-example, and some of my own examples did work very well!

from zettlr.

Hmm, this one isn't working for me. But I wonder if we're looking at the same type of link? So, I have a t.o.c. produced by pandoc. A link in the t.o.c. looks like this:

The corresponding heading further down the document looks like ## Neorealism (on a line on its own. When I click on the green link above, nothing happens. I've tried in dev tools putting a pause on the function that should process these links (the new one you've added, line 170 of zettlr-editor.js), but markdownOnLinkOpen doesn't seem to fire, either on opening of the grey link, or clicking on the green link. Are you supporting only [[...]] links here?

Also, am I debugging the right file when trying to debug this (zettlr-editor.js), or is this just a list of functions that are applied by another function, or a worker?

from zettlr.

Hey, the markdownOnLinkOpen-function is indeed the correct one.

But it only fires if you click on a link that has been rendered by the renderLinks command. This means, it must become underlined on hover. And, more importantly: You must Alt-Click the link! It shouldn't open (what happens if you simply click somewhere inside), but follow the actual link (which happens when alt-Clicking).

This behaviour is by design, because the first action you'd want to do in an editor is to edit, and only a secondary action is, e.g., to follow a link :)

Does this work for you?

from zettlr.

OK, now I know how to do it, it works! What I was doing was clicking on the grey link, which opens as in the image above, and then clicking on the green.

I completely agree that the main function of an editor is to edit, not to browse, so Alt-click makes sense. My only doubt is for touch-screen use. The standard Windows on-screen keyboard doesn't have the Alt key, so could you consider mapping Ctrl-click (Command-click on Mac, I think) as well? I've just tested this on a Surface. Ctrl is available using on-screen keyboard.

from zettlr.

The first question I have now is "Why on Earth would Microsoft not add the ALT-Key to their onscreen keyboards?"

Something something …

Well, alright, I'll look into it whether or not it makes sense to also bind Cmd/Ctrl+Click, or if that would break something else!

from zettlr.

Alright, thank you very much again! :)

from zettlr.

Hello,

I was looking for a way to create links to paragraphs in the same file and I found this helpful (very helpful) explanation.
Thank you very much!

I believe, however, that there is a slight problem if the title from which the link is generated contains an accented letter.
Writing:

##Choix d’implémentation

within Zettlr I can find the paragraph and create the link. I'm not really interested in following the link within the tool, I'm more interested in exporting it and having it available in the final document (Latex).

But in Latex the link can't work: the label is
\label{choix-dimpluxe9mentation}
while the reference is
\hyperlink{choix-dimplmentation}{Choix d'implémentation}

it seems that the accented letter is in one case is removed while in the other case it's translated as a double character.

I found a workaround: after creating the link it is necessary to edit it by adding the accented letter that was missing. In this way, during the extraction of the latex code, the two labels are produced in the same way and the link works correctly.

Thanks in advance. Best regards,

               Andrea

from zettlr.

@AndreaTosoni That could be behavior that might be improved. Feel free to try out more combinations and then open a new issue with these, so that we can improve Zettlr's behavior!

from zettlr.