[SUGGESTION] Parsing the URL metadata value as a hyperlink
Completed
With the “Make URLs clickable” option set, in the Editing preference pane, it would be nice if the parser included the value for the URL key in the MMD metadata block. That’s a special case where the preferred approach (at least in my opinion) would be to exclude any hyperlinking syntax (like <url>) as that might interfere with any automation that makes use of this field.
For example:
-
The URL metadata in your example isn't a "real" URL, but rather just text that happens to contain a URL. The "Make URLs clickable" option makes anything treated by Markdown as a URL into a clickable link in the editor, but does not scan all text in a document for other things that look like a URL.
This makes the behavior in the text view consistent with the behavior in the final document (or the preview) -- if it's not a MMD URL it won't be clickable in either the text or in the preview output. Otherwise, it should be clickable in both.
In this case, even `url: <http://foo.com>` is not a link when contained in the metadata, since metadata is not parsed further than the key/value relationship, and is not used to generate a clickable link in the HTML output.
0 -
What is a link?
> The URL metadata in your example isn’t a “real” URL, but rather just text that happens to contain a URL.
I suppose I am thinking more from the perspective of the function and purpose of using that particular metadata field in this context, than whether it is technically Markdown link. Clearly it is not, Markdown does not even have metadata. But given that MMD does have metadata, and given the common reasons one might have for placing a URL in the defining block of the note in nvUltra, think from a practical and convenience standpoint, it even make syntax sense. It is literally defined as being a URL, with the statement “URL:”. ;)
As an aside, I do agree overall with what you are saying, that links should only be clickable if they are indicated as such with syntax, rather than just any old string that might look like a URL. No debate there—my argument above is not contradictory I think, in that I am calling something a URL with a structural syntax and then providing a URL, that is a form of syntax.
> This makes the behavior in the text view consistent with the behavior in the final document (or the preview) – if it’s not a MMD URL it won’t be clickable in either the text or in the preview output. Otherwise, it should be clickable in both.
That kind of symmetrical nature makes sense, but it does I feel also excludes two different but important uses of Markdown (in particular, as a vehicle for taking notes in nvUltra):
- Archival: Where the primary purpose of a document is to simply be an MMD document, to perhaps even never be exported into a fixed format.
In that usage, the mechanisms of the MMD format itself can have a use independent of output concerns. One might have more latitude and use for metadata fields in general if each field is intended to support what you see in front of you, and less to operate as a proxy for external functions, such as being embedded into an HTML file or something. - Hybrid: in asymmetrical usage, which I think this note that I’m typing into right here falls under.
The note itself, as stored in MMD format, is meant to be useful for that purpose all by itself, as well as to produce an output (simple though it may be). This is an interesting scenerio in that there are metadata fields assigned to this note that have no use or purpose being included in the output—and the “URL” field is definitely one of those. It stores the URL of this posting right here, so I can get to it quickly, but there is no need or place for that information in the output.
To my mind both of these uses are of particular interest in a program like this, where the central thrust of the software is to operate as a note-taking tool, rather than a website generator, book building tool—or anything that might have a more strongly pragmatic approach to the application of Markdown.
The spirit of a link
To go back to the symmetrical argument, that links should only be functionally present if some output format does likewise, there are two spots where it doesn’t seem to me that guideline is followed. Maybe they are simply oversights—because at the moment it looks like only the first form of designating a link is considered a “proper” clickable link:
Plain-text / print friendly links:
<https://multimarkdown.zendesk.com/hc/en-us/community>
Standard inline Markdown [links](https://multimarkdown.zendesk.com/hc/en-us/community).
Referenced Markdown [links].
[links]: https://multimarkdown.zendesk.com/hc/en-us/communityI suppose there is a legitimate question here: what is the link in some of these cases? If the idea is to pair function with output as closely as possible, then it would be the text inside the square brackets. But I think highlighting the URL and making it clickable is the more useful result (one thing I dislike about rich text editors that have a link-first click behaviour is that placing the cursor to edit linked text is awkward). It is surely also easier in the case of referenced links.
The concept of internal linking
By internal linking here, I don’t mean links loading other notes in nvUltra, but rather links that would be useful within a single document itself. For example, “What is a link?” is something I can type into this note and it has a referential meaning (I even have auto-completion suggested). Yet it has no internal function. Should this be the sort of thing where if I click on it, it scrolls me to the heading for that section of the note?
And could that same argument be made for other label markers: footnotes, cites, referenced images? And in some of those cases, the internal linkage could be a round-trip thing, much like footnote markers work in word processors: click the marker in the text, jump to the footnote text; click the marker prefixing the footnote next, jump back to where it is referenced from in the main body.
In conclusion, I think what I am getting at overall here is that choosing Markdown as the vehicle for writing within nvUltra should provide inherent function within it, to be in support of the overall philosophy of its usage. If certain notes end up being exported in one fashion or another, that’s great, but secondary to what can be done for and within the software itself. That's my highly opinionated take anyway!
0 - Archival: Where the primary purpose of a document is to simply be an MMD document, to perhaps even never be exported into a fixed format.
-
Thanks for your thoughts -- I will have to respond a bit more briefly however. My apologies. ;)
As for `url:` metadata, MMD doesn't understand anything but a few predefined metadata keys (https://fletcher.github.io/MultiMarkdown-6/syntax/metadata.html). Beyond that, whether it is `url:` or `football:`, MMD is completely unaware.
I agree that MMD documents can be used for a wide variety of purposes. None of that is changed by this. It just means you might have to copy the URL and paste it into your browser. Nothing prevents you visiting the URL just because it isn't automatically clickable. ;)
As for the other forms of links, for technical reasons those will be limited. For example, the reference format isn't parsed into anything useful until later in the process. Which means that `[links]: https://...` is functionally the same as `[links]: foo`, which may or may not be a valid link depending on how the file is used.
As for inline links (`[foo](http://bar.com/)`), I have added support for making those clickable for next release. (That information is readily available at the time of parsing.)
As for more complex internal navigation (such as the TOC used in MMD Composer that allows navigation), that is getting outside the scope of this application.
0 -
Well that explains a majority of my confusion on the matter, then! :) I had it in my head that the URL metadata field was a semi-official field, rather than something I must have just made up along the way, many years ago. So yes, given that, I understand what you are saying and agree with it.> It just means you might have to copy the URL and paste it into your browser. Nothing prevents you visiting the URL just because it isn't automatically clickable. ;)Oh of course, and I'm used to this field (and URL strings in general) not being clickable just about everywhere. I use LaunchBar however, so for me it is as simple as grabbing the selected text with a quick double-tap on the Fn key and then hitting Return to send the string as a URL to the default browser.0
Please sign in to leave a comment.
Comments
4 comments