Hello, I am trying not polluting text with too many links so I thought I would use the Markdown Reference Links syntax to move the lenghty web addresses down the document but it seems not to be working…
Ex:
In VSCodium I get proper rendering:
Am I doing something wrong here?
That syntax is not supported but footnotes are. It’s not the same result but maybe they can be useful for you anyway. Here there is an example: https://docs.logseq.com/#/page/649d8096-40b2-476d-abd4-fd44e673a44c
On a side note, I am quite shocked that even some standard Markdown is not supported 
;
Regarding your suggestion, I followed the link but can’t enter in edit mode on that block so I can see how it’s written.
Edit: found some explanation online; [^descr]
[^descr]: https://www.youtube.com/watch?v=K8qqhetEvUA;
However, links alone don’t seem to work:
[^descr]: [Getting to Know Logseq - Logseq Footnotes](https://www.youtube.com/watch?v=K8qqhetEvUA);
but if I put some text in fromt of the []() Link it would work:
[^descr]: Link [# Getting to Know Logseq - Logseq Footnotes](https://www.youtube.com/watch?v=K8qqhetEvUA);
Thanks.
Sorry, Markdown footnotes are like this:
Lorem ipsum dolor sit amet[^1].
[^1]: http://example.com
Thanks, I was replying inline in the previous reply and doing all sorts of tests in the meantime.
But now the syntax is broken for another markdown viewer/editor/script
So i’d rather have the few markdown syntax rule not being unsupported by Logseq and have some flexibility abut it …
I see, it must be a bug, probably it is worth reporting it 
Just opening this thread to point out that Standard Markdown Linked References will show nothing of the “footnote” Link, which can be SOO useful in many situations where you might want to have some text without it being rendered on screen -or in print.
For example I have a block/page I want to export as PDF but I have all sort of notes inside it so that I remember to add stuff, remove stuff, call X for feedback, etc. I am exporting rev1 and the resulting PDF will not contain my notes, while I can use them to remind me to work towards rev2, etc. And this is just one possibility.
Another HUGE possibility is to have PROPERTIES and Block IDs without them being rendered on screen if using an external markdown editor/viewer and still being able to retain that information in the file. I see this being implemented in the following way by Logseq:
[Property]: # "property::value" or [ID::value] # "local_file.md", which would retain the information of the property in the Markdown file without it being visible on screen when the markdown file would be imported for publishing in a web server or shared with other users who use a different app to read it and maybe make notes themselves by just writing a [Name_Of_Note]: # "Some Feedback Note for the Author", etc.Moreover, besides Properties, some other useful features would become “Standard Markdown”, like Block/Page IDs. Right now, the ID that is created when you Ctrl+C (copy block) or Ctrl+E (copy embed) are inserted in the Markdown file as a new soft-breaked line just below the block text. In Standard Markdown, there is no Sot-Break and these IDs just show as if they were written on the same previous line:
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
id:: 64abad7e-ee4f-40b4-bbcd-e0ff18444bf2
* Pellentesque felis est, [...].
It will show on a different line though if the previous line has some sort of Markdown header formatting like “###” but, nevertheless, it shows in rendering something that makes no sense for the text (it only makes sense for Logseq internally). So, if I want to export the page for printing or sharing with someone, that Logseq internal formatting in the Markdown file would be stripped off. But it might be still useful, just like with Properties, so why not implement the Standard Markdown Linked References Syntax where the following:
###Lorem ipsum dolor sit amet, consectetur adipiscing elit.
[id:: 64abad7e-ee4f-40b4-bbcd-e0ff18444bf2] <"./some__name-spaced__page__name.md">
* Pellentesque felis est, [...].
would be rendered as:
In my opinion, using this Linked Reference as a way to keep Logseq Markdown as close to Standard as possible would greatly enhance its appeal to us who came here for it’s local first, privacy first, open source and Mark-down based qualities;
Thanks.
I thought it too but then I discovered Djot, that is basically Markdown done right and with more metadata. Logseq and other PKM apps would benefit a lot from a transition from Markdown to Djot, so I support that instead of more hacks on Markdown.
I studied briefly AsciiDoc and ReST -restructured text- and think they are too a good fit but Markdown is wildly accepted in so many tools already that it would be counterproductive -at least by my understanding- for Logseq -and for other Markdown-based tools out there- to transition to anything not wildly accepted and used. At least for my example, I have one of my Logseq Graphs on a shared folder and am doing some of the documentation in there. After some back and forth documentation sessions and meetings, we settle on a final one. From there, people can take it and import it in their own tools like Jupiter Notebooks, even Confluence and many more tools that ca use and render Markdown. Also web wikis and other tools are currently either markdown based or supporting mainly markdown for this kind of stuff.
I would myself love another, better text-based light-markup language that can do whatever Markdown does and more, be compatible with web browsers, documentation apps, wikis, etc, but for now I don’t see Markdown being replaced anytime soon.
That’s why I am trying to solve my own situations with whatever Markdown “hacks” I can and Standard Markdown as well.
Just on a side note, maybe this can help someone. As long as [Note]: # "by FlorinF: Logseq should support 100% Standard Markdown and use specific-Logseq-features as much as possible within that standard Markdown framework" is not possible in Logseq atm, I am using the Normal Link to achieve something similar, with the only issue being having an extra empty line where the Markdown Link is:
[](.#Note "by FlorinF: Logseq should support 100% Standard Markdown and use specific-Logseq-features as much as possible within that standard Markdown framework")
Update: another very cool feature this method would have is that I can [WIP]: # "/today /time" (by even employing a text expander to quickly insert it whenever I start working on the Project/Document and then add a [TBR]: # "/today /time" (To Be Resumed) to Pause the WIP. I would love to have Logseq do this automatically by using the suggested Linked References Standard Syntax instead of polluting the md file with org-mode clock lines that would look awfully in an external editor. Until then, this is how I keep track of my time on projects.
The .md files by Logseq can’t be used as they are elsewhere and Logseq doesn’t support normal paragraph. So what Logseq uses is a subset of Markdown with additional syntax, including the one for metadata like “collapsed:: true” or “id:: 12334567890…”.
Djot is very similar to Markdown, there are minor differences. You can convert Djot documents to Markdown easily with Pandoc. If one wants to produce unambigous Markdown that works almost everywhere, one of the best option is writing in Djot and then convert. (P.S. there are not good enough tools to convert Logseq Markdown to standard Markdown).
Also notice that Djot is not defined by some random guys, but by the author of Pandoc and of the Commonmark spec (basically the flavour of Markdown we are using almost everywhere, even here on Discourse because the author of Discourse is a proponent of Commonmark too). So Djot is by a person that loved Markdown and contributed a lot to make it what it is now.
But Markdown has huge problems. I am tired of having to check PDFs that I export from Markdown because ambiguities can lead to unexpected rendering issues. With Djot I have guarantees when exporting to PDFs, Markdown and everything supported by Pandoc.
Maybe Markdown won’t be replaced soon, but Djot is already a good tool in the Markdown-ecosystem.
but what can the casual user do with Djot atm? Regarding to Logseq, of course. If me and 10000 other people use Logseq and generate data in journals and pages in md files, if Logseq itself doesn’t transition to it, then it isn’t of much use is it? How are you using Djot with the Logseq workflow?
I can select a block or a page and use Logseq built-in feature that can remove bullet points and other stuff, then convert from Markdown to Djot and take advantage of Djot features manually, then export for example to PDF (and it would have huge advantages when publishing to the Web).
But the “Logseq-flavoured Markdown” could be removed by this process if Logseq used directly Djot for storage (keeping the export to Markdown dialog as it is now).
In a certain sense, Djot is doing the same Logseq does to Markdown but in a standard, documented and cross-application way, with already different implementations in most common programming languages.
I myself write everything in journal pages, even large pieces of documentation, write-ups and so on. I just zoom on the bullet and build from there. The only thing I am missing is being able to add multiple headings to different Soft-Breaked Lines within that bullet.
With that said, if I was to take the Logseq Markdown of that whole bullet and do a simple REGEX Replace like this: Search For: \t+[- ]\s+, Replace With: <Nothing>, I would get perfect Markdown, minus the annoying metadata, which remains in line with the text around it.
To even get that one sorted out without loosing it (collapsed:: true is useless but author:: Some Author or WIP:: /date /time) are useful, so why not encase everything-metadata in a Markdown Referenced Link like so:
Find and Replace:
^(s*.*::.*)$
[Meta]: <$1>
These would get me:
[Meta]: <collapsed:: true>
[Meta]: <cover:: ![image]()(:height 172, :width 98) >
What I don’t like is that Logseq will not recognize anymore the strings inside the angled brackets so the above would break the metadata in Logseq if applied in place by a sort of job that performs the above search&replace whenever the journal md file time changes, so it’s only feasible when exporting some piece of markdown. Or, I’d like to be able -for example- to serve on web as a wiki, some pages directly from the Graph Folder, and, if they get updated, the wiki to reflect that in real-time, which would only be possible if Logseq itself would wrap the metadata in some standard Markdown that is not displayed by markdown renderers/viewers.
My main point was that the Markdown you get from the above is usable for sharing the resulting files with other people who you don’t know what app they use to view/edit/converti/etc.