Qownnotes: note:// and file://media are bad for portability

[mlinchitstest]

I can see why these features are there, but they make much less portable.

• Can we have an option in the settings that allow will dumping media in the the same folder as the notes? Perhaps, you could prefix all media filenames with media_, so they are easy to separate from notes. That way all other markdown edits will be able to read the file.
• Can we have an option in the settings to open all .md filenames _that are registered in the notes database_ in qownnotes? So instead of note://, you'd just use the file:// protocol.

[mlinchitstest]

or just open all links to *.md files in qownnotes by default, regardless of whether it is a note or note —whichever is easier.

[pbek]

Can we have an option in the settings that allow will dumping media in the the same folder as the notes?

I'm not sure yet what side-effects that would have.

Can we have an option in the settings to open all .md filenames that are registered in the notes database in qownnotes?

If we do that the file handler from the markdown edit would open the notes with an external program when they are clicked, I'm not sure yet if there is a way around that.

[Maboroshy]

I've tried QOwnNotes generated files in many markdown editors including the ones in Android and haven't encountered an issue with "media" directory yet. I wonder why "media" makes notes less portable.

The "note://" is pain sometimes though.

If it it's "won't fix" for QOwnNotes I can implement both functions in Bash-note script I write to get the functionality that is beyond QOwnNotes conception. The script is for GNU/Linux but link handling part can be made to support OSX with some testing.

[Maboroshy]

I've just thought that if using "media" really needs to be an option it can be made by allowing user to change the relative path of directory used to store images with "/media/" being the default.

So "/" will be a note root directory.

[minthemiddle]

file:// is also bad for working with pandoc as it does not recognize this URL structure. Pandoc is perfect for converting the Markdowns to PDF or Word.

Here is how I would solve this. Note that this solution does not require any changes to QON but is rather a workflow including some CLI tools.

• Create a root folder with three folders: notes, input and output
• Place your Markdowns in notes and add this folder to QON's notes' list
• Create a Makefile in root which copies your *.md from notes to input
• Add a simple sed search & replace in your Makefile which will replace file://media to media
• Add your Pandoc conversion to your Makefile such as make pdf or make doc
• (Optional) Add grunt or gulp for tracking changes to your notes and automatically fire your copy, search & replace and make commands

[Maboroshy]

I have another solution that can be little simpler.

QOwnNotes use relative links as default but it also works with absolute links. Relative links don't work without "file://", absolute do.

So the easy way to go 100% portable is convert all links to absolute and truncate all "file://" out of notes. Anyway most markdown apps I've tried don't work with relative links.

Bash-note being the shell script to use CLI tools for markdown workflow can already convert links in all notes to absolute with one command. I can easily make an option to delete/add file "file://" in the next version.

[Maboroshy]

The bad thing is QOwnNotes shows images with such links without scaling them to fit the screen:
empty or file:/DIR - absolute,real size
file://DIR - relative
file:///DIR - absolute,scaled

Anyway I've just added it to Bash-note as one of link types available to convert to. Will be in the next release.

[Maboroshy]

I can implement the "Makefile" routine too if there is any potential user for it.

[obmk]

There is one more issue with that file:// thing when using the MD files in other environments.

Assuming you use the (marvellously working) "paste from clipboard" feature in QON for making screenshots to illustrating a process documentation, QON creates this code:
![screenshot 2016-07-06 at 11](file://media/185346365.png)
and shows the image correctly.

Opening this by "open in external editor" (i.e. Texts) we wont see images because the image link is still pointing to the resource "absolutely".

Of cause, we now can discuss about "who's going to change its point of view?" but I think it might be the easiest way to change that in QON.

BR
Stefan

[Maboroshy]

It's rarely the "file://" issue but the relative links one.

Rare markdown editors support relative links QOwnNotes use, but most support "file://" links correctly as long as they have absolute path.

I can't test Texts myself but try putting ![screenshot 2016-07-06 at 11](file:///absolute/path/here/media/185346365.png) and check what's the real issue with it.

[Maboroshy]

I suddenly have some new feedback on the subject.

I've started to use the new Android app Epsilon Notes which is the most advanced markdown editor for that platform. It has a cool preprosessing feature, which is supposed to handle non-standart markdown codes. It's makes a text regex replacements on a rendering stage.

As we wrote earlier, QOwnNotes has relative linking and note links which are mostly specific for this app. I used to overcome linking by converting all links to absolute, that are commonly supported. But now, with that preprosessing thing, I can replace file://media/ to file://storage/emulated/0/notes/media on render, without any file changes.

Another feature of Epsilon Notes which is rare for markdown editors - it follows links to markdown files internally, as a note links. QOwnNoted doesn't, it uses note:// tags for that.

These tags are nasty. They have _ instead of spaces. They are no relative links. They are no absolute links. They are no file links at all. So converting them to file links is a way beyond simple regex replacement.

I see 3 solutions, from hard to more moderate:

• teach the app to open files, so user could associate .md. with it, and it would open basic links to .md files.
• open note:// same way as file:// - absolute links, relative links... no problem. No "I'm a text editor" routine, but still lots of moves to stay sane when link target is outside of note folder.
• open note:// as a relative file links. Like note://I'm a note.md or note://sub-folder/another note.md. Almost like it's now but file based, available for processing.

[pbek]

With having written a new markdown parser and highlighter I'm planning on having a 2nd look at implementing urls without url-descriptor for images and links. Might be quite some work to make everything work tho..

[Maboroshy]

Do you mean file:// and note:// by "url-descriptor"?

[pbek]

Yes. I aim for images like ![](image.jpg) and links like <file.md>. I'm not sure yet about all consequences...

[Maboroshy]

You mean like ![](/sub-folder/image.jpg) or more like ![](you can't have sub-folders in media folder.jpg?

[pbek]

I think of doing it more like https://apps.nextcloud.com/apps/files_markdown or I guess also GitHub. Relative urls with subfolders...

[Maboroshy]

Good stuff. If note links would get to the file level, making them portable will be an easy task.

[Maboroshy]

I can't test Nextcloud Markdown Editor, but readme says links are relative to a document.
So if the note is in root, it's ![](media/image.jpg), but what if it's in sub-folder? Or you'll stick to note root folder as a zero-point as it's now?

[pbek]

Can you please define note root folder as a zero-point, @Maboroshy

[pbek]

Ah, you mean note sub-folders with media files in the media folder of the note folder (not the sub-folder)... An excellent question... Any suggestions?
So far I've only thought about "supporting" non-valid images and links, I'm not sure about what the insert media (and drag & drop and pasting via clipboard) and insert link dialogs should do...

[Maboroshy]

Personally I don't see, why change the current approach. Yes, file:// and note:// can and maybe should be deprecated. Absolute links works without file:// even on current version.

But changing "relativity" rules will cause a major headache. Implementing is one thing. You'll still need to leave old logic for backward compatibility. Also current relative links are easy to process, - put a note root folder path at the beginning, and it's an absolute link.

And I don't see any suffice gains really.

Maybe go for just deprecating descriptors with a corresponding "insert link" behaviour and backward compatibility.

[pbek]

Without note:// it also has to be detected that in several places if a note should be opened or an external program. And that's just the tip of the iceberg.

[Maboroshy]

There's a note file extension selector in options. All links to files with that extension will be considered as "note links". Opening them in external editor will go to the right-click context menu.

[pbek]

I know that there is. But that doesn't solve the technical problems that I will have to overcome in the process at making everything happen at places that doesn't know of these settings... in other words, I will not get bored. 😁

[Maboroshy]

That's very true. Less boredom, better app. Sounds like a a motto.

[pbek]

And apparently adding truckloads of complexity too... :/
And then people will start moving a note to different note sub-folder and complain why the links are broken... Same with images...

[Maboroshy]

Making links "path independent" you'll get into issue with images/notes having same name.

I think it's better not to go too far away from markdown, or you'll end up with app-tied syntax, like Wikidpad.

You could go a hard way saving all the links to database, and using that data on every note move operation. It's also possible to rebuild links that were broken externally to a certain degree. By the way it won't be very hard to make my script do that since it already has links parser and converter. It scares the users though.

If the user doesn't understand, how markdown works and what are the app's limits, it's just a matter of time, when he will break something. The only way to avoid it is store all notes data in database to exclude external modification. By the way that would also dramatically reduce I/O load. But that would be whole different app in a quite full market.

[pbek]

Saving the names in a database would surely be "bad for portability". :D

To find a system to rename the note links in all notes is hard with sub-folders because you cannot parse the links easily...

• some-folder/note-name.md
• ../note-name.md

Storing everything in the database would lock all notes down.

[Maboroshy]

Yep, storing everything in db is a lock up. I was exaggerating posting about that.

But storing information about links is db by parsing notes isn't. It's just the catalogue of links. If the app knows some link target moved, it can replace catalogued links that become broken with a new correct ones. But it's a hard path and even after proper implementation the app won't recover many broken links after note external modification. Personally I'm not sure that the broken links are a major issue. At least for starting something as big as this db thing. Don't see lots of users posting issues about it.

As for my parser. It parces image links, file links, web links, relative, absolute, file:// or no file://, reference style links, links with multi-line syntax, title or no title... almost anything the app renders. Name, what it can't do, and I'll make it do.

[pbek]

16.12.9

• added experimental support for regular file links like <my-note.md> or
  [my note](my-note.md) in the note edit pane and the note preview
  
  
  
  • no paths are allowed
  
  
  • only note files are supported
  
  
  • when Ctrl - clicked the note will be opened
  
  
  • the file link is internally converted to a note://my_note url, file
    
    extensions will be stripped
  
  
  • highlighting for such links was also added
  
  
  • in the preview these file links are replaced with note links, that also
    
    takes place when such a link was found in a code block
  
  

There now is a new release, could you please test it and report if the new features work for you?

[Maboroshy]

[my note](my-note.md) works. But without a path it can only be used with a single folder structure, isn't it?

[pbek]

Thank you for testing. It works like the current note links work. It matches all sub-folders...

[pbek]

in the preview these file links are replaced with note links, that also
takes place when such a link was found in a code block

And I already very much dislike that I had to cripple the preview for it...

[Maboroshy]

It matches all sub-folders...

It works only for the same folder for me. Anyway, without a path it's only portable with the same folder.

[pbek]

It works only for the same folder for me.

Interesting, I haven't tested it, because I translate the links... Do the current note://my_note links also only work for the current sub-folder for you?

[Maboroshy]

Looks like it. And trying note name without spaces or with only ASCII symbols didn't help.
Both [note](note://my_note) and <note://my_note> doesn't work.

[pbek]

As far as I remember it just simulates a click on a visible note. I guess it would work if All notes is selected in the sub-folder tree widget. But maybe I'm wrong, I haven't looked at the code...

[Maboroshy]

That would explain, why it worked, when I had note with the link opened and changed selected sub-folder to the one with the target note.

[borisrorsvort]

Any updates on this?

[pbek]

From my side this is on hold, there are far too many troubles and regressions with every involved process because of the "non-urls"...

[obmk]

from my side, no visible changes in terms of using md files including file:// links in other editor environments. Looks like the discussion doesnt come to a finish because the overall target(s) might not defined.

As read earlier, absolute links in QON work already w/o the file:// (well, the image does not scale in the QON preview but that might be a minor) and absolute links work in other editor environments too.

I agree, that changing the relative / absolute link philosophy might produce long term impacts and there has been more advantages from relative perspectives than glueing to absolute viewpoints, so, from my point of view: Why not offering a check box to the user to enable or disable the file:// prefix? In this case, the user has the choice and at the end, its all made for the user, isnt it?

BR

[borisrorsvort]

The file:// relative links dont work in macdown nor atom markdown-preview for instance. Do have an osx app example where this works? Why not just use normal img markdown relative path? this works everywhere without a doubt.

[pbek]

The above implementation made in 16.12.9 is the current state in QOwnNotes. So far there was not much feedback, so I guess no one really cares... I'm open for pull requests if anyone wants to improve on that.

[RomanGurinovich]

Hi Patrizio,

using v17, still facing compatibility issue. ![](/image.png) doesn't work

Best regards,
Roman

[pbek]

yes, still an url is needed for using images...

[RomanGurinovich]

maybe you can suggest some workarounds or when to expect feature release?

[pbek]

![](/image.png) would point to the root directory because of the /, did you really want that? you can play around if everything that has a file:// in it.

[pbek]

You could also play around with markdown-it from the script repository...
https://github.com/qownnotes/scripts/tree/master/markdown-it

[wwtex]

added experimental support for regular file links like <my-note.md> or
[my note](my-note.md) in the note edit pane and the note preview

Hello, first thank you for making such a full-featured and cross-platform program. I'm using it for Zettelkasten, so I'm definitely one of the people who cares about it.

But I'm seeing a conflict between the <my-note> syntax and Multimarkdown, which has already claimed the <(...)> for email links. Moreover, cross-note links already have a syntax defined as [[my-note]] in Notational Velocity.

Since the issue is still open, why not conform to the existing [[my-note]] standard? This would allow compatibility with Notational Velocity and avoid conflicting with Multimarkdown at the same time.

[pbek]

Thank you for your kind words, @wwtex. I'm sorry, so far there is nothing new to report here. There are so many technical side-effects then not using real URLs in links... And in addition [[my-note]] would be faaaar away from the markdown syntax.

[pbek]

19.9.0

• added support for relative image tags like ![photo](path/to/my/photo.jpg)
  in the preview and the PDF export
  
  
  
  • if the note is in a sub-folder the path counts as relative path in relation
    
    to the sub-folder
  
  

[pbek]

There now is a new release, could you please test it and report if it works for you?

[pbek]

19.9.2

• the note sub-folder will now be correctly set when switching to notes that are
  not in the current note sub-folder
• you can now use relative links to markdown files to switch to notes
  
  
  
  • clicking <My note.md> or [Text](My note.md) jumps to the note My note
  
  
  • clicking <My subfolder/My note.md> or [Text](My subfolder/My note.md) jumps
    
    to the note My note in the note sub-folder My-subfolder relative to the
    
    note sub-folder of your current note
    
    
    
    
    
    • there still are a cases where links would not work in the preview (or even be shown)
      
      
      when sub-folders are involved
    
    
    
  
  
  • this should not only work in the preview but also when you Ctrl + Click
    
    on the link in the note text edit
  
  

[pbek]

There now is a new release, could you please test it and report if it works for you?

[pbek]

19.9.3

• relative links to notes in sub-folders like <My subfolder/My note.md> or
  [Text](My subfolder/My note.md) will now be rendered correctly in the preview
  and are also clickable
• you now can open files from markdown links like <My folder/My document.pdf> or
  [Document](My folder/My document.pdf) by Ctrl + Click on the link in the note text edit
  or clicking the link in the preview
  
  
  
  • the links are resolved relative to the current note
  
  
• you can now also Ctrl + Click on markdown images like ![Image](My image.jpg)
  in the note text edit to open it in an external image application
  
  
  
  • the image links are resolved relative to the current note
  
  

[pbek]

There now is a new release, could you please test it and report if it works for you?

[pbek]

19.9.6

• when inserting images into your media folder like with the Insert image dialog,
  the Evernote import, via drag and drop or from the clipboard now markdown tags
  like ![imagename](media/30933630.jpeg) are created
  
  
  
  • this also works if you are inserting images in notes in sub-folders, then the
    
    image would look for example like ![imagename](../media/30933630.jpeg) if
    
    the depth of the sub-folder is one
  
  
  • the scripting functions downloadUrlToMedia and insertMediaFile will now
    
    also generate a markdown image relative to the path of the current note
  
  
  • you can still use the old file://media/30933630.jpeg links if you enable
    
    legacy links in the General settings
  
  
• when inserting files into your attachments folder like with the Insert attachment dialog,
  the Evernote import or via drag and drop now markdown tags like [filename](attachments/45412706.pdf)
  are created
  
  
  
  • this also works if you are inserting attachments in notes in sub-folders, then the
    
    file would look for example like [filename](../attachments/45412706.pdf) if
    
    the depth of the sub-folder is one
  
  
  • you can still use the old file://attachments/45412706.pdf links if you enable
    
    legacy links in the General settings
  
  
• when linking to notes like with the Insert link dialog or when splitting notes
  now markdown tags like [note](other note.md) are created
  
  
  
  • this also works if the linked note is in another sub-folders, then the
    
    link would look for example like [note](../other note.md) or [note](sub folder/other note.md)
  
  
  • you can still use the old note://other_note links if you enable legacy links
    
    in the General settings
  
  

[pbek]

There now is a new release, could you please test it and report if it works for you?

[dejastew2]

Very nice; this fixes the relative image path incompatibility I was seeing on #803. Thanks @pbek for fixing this issue so we don't have to rely on preprocessor macros any longer!

[pbek]

Thanks a lot for your feedback, there really goes a lot of work into this. Please keep on testing the next releases too! :smile:

[pbek]

19.9.7

• the Orphaned image files dialog now detects relative image tags like ![imagename](media/30933630.jpeg)
  
  
  
  • the dialog is now also able to insert relative image tags
  
  
• the Orphaned attachments dialog now detects relative attachment tags like [956321614](attachments/956321614.pdf)
  
  
  
  • the dialog is now also able to insert relative attachment tags
  
  

[pbek]

There now is a new release, could you please test it and report if it works for you?

[pbek]

19.9.8

• highlighting of broken note links now also works with relative note links like
  <note file.md> and [note](note file.md)
  
  
  
  • links to note files like ../note file.md and sub folder/note file.md also work
  
  

[pbek]

There now is a new release, could you please test it and report if it works for you?

[pbek]

19.9.10

• added support for note links from one sub-folder tree to another like ../../folder1/folder2/note.md

[pbek]

There now is a new release, could you please test it and report if it works for you?

[pbek]

19.9.12

• if you rename a note you now will also be able to automatically rename new
  relative note file links like [note](note.md) or <note.md> in all other
  notes if they are found
  
  
  
  • this also works with links from other note sub-folders
  
  

[pbek]

There now is a new release, could you please test it and report if it works for you?

[pbek]

19.9.13

• if you move notes to another sub-folder you now will also be able to automatically
  adapt the new relative note file links to that notes like [note](note.md) or
  <note.md> in all other notes
  
  
  
  • furthermore relative links of images and attachments in the moved notes will be
    
    automatically adapted to the new sub-folder
  
  
• if you copy notes to another sub-folder relative links of images and attachments
  in the copied notes will be automatically adapted to the new sub-folder
• above changes conclude the monstrous effort of the migration to more portable relative
  file links for notes, images and attachments in #266

[pbek]

There now is a new release.