This looks fantastic!
One thing though - isn’t AceEditor is going to be replaced with CodeMirror?
Thanks for looking into it but please keep in mind that we might drop Ace Editor in favour of Code Mirror at some point (maybe sooner than I thought), so it might be best and even easier to get it working on Code Mirror instead.
1 Like
Ah ok, I didn't know this. After the little work I did with Ace Editor and looking at the docs for Code Mirror, I can see why this might be happening. Is there a branch where Code Mirror is the default editor and can be worked on? It probably wouldn't be hard to add this autocomplete feature to it (they even have documentation! 
) , but I would need to mess around to get it working.
4 Likes
The Code Mirror editor is already in the pre-release but you need to enable it in the Settings => Note => Enable Code Mirror
This is great. Before I read all the replies I wanted to say that upgrading Ace was on our list anyway.
But it seems that Laurent wants to get rid of it. I actually hoped that it would be here to stay, but if Code Mirror has the same functionality as Ace, I don’t care.
e.g. I really like the fact that I can move lines up and down with Opt+Up and Opt+Down.
However, I have the feeling that Code Mirror is more visual than text. And I really like just simple text in the editor. But I could be wrong.
It is just a simple text editor. But it has proper Unicode support, support for variable line heights, and is more extensible. Personally I would like to make the editor more visual, but obviously not everyone would want that. The current hearing changes can be disabled using the userchrome.css but ideally we’ll also have a toggle in the settings for users like you that just want an editor.
P.s. I’ll look into the line switching thing, should be easy to add
2 Likes
wow, this looks amazing! Maybe we can open a draft PR to add this feature based on Code Mirror together!
3 Likes
This Would Be great and the zettelkasten editor called obsidian .md was mad e by two people and wouldn’t be dfficult to implement so plwase do it
Great man this would be a deal breaker for me how do you implement this, i have no idea about what to do
Great man this would be a deal breaker for me how do you implement this, i have no idea about what to do
GIven you came up with this cool solution, I have a follow up question. How hard do you think it is to implement the same functionality in the Markdown editor? Is it at all possible?
For note linking, would it be intuitive enough to use the current Goto Anything feature and allow copying the note link from there. Then the process while editing a note would look like this:
Ctrl-g
search term
Ctrl-c (would close the Goto Anything dialog)
Ctrl-v
I'm not sure if this is technically possible as I haven't reviewed the particular code, but it does use roughly the same number of keystrokes.
Edit: This by itself would not allow linking on mobile since the Goto Anything feature does not exist on mobile (as far as I can tell).
4 Likes
Or just allow right click to have Copy Markdown Link option on Go To Anything.
(Ohh. v1.2 ditched right menu altogether, there was some Copy menu in 1.0)
1 Like
As far as I can tell, Drag&Drop only works inside a single folder while notes can be seen&selected…
I like to use keyboard without mouse to write notes, and I really like this idea!
I think we also need to have keyboard shortcuts to go inside the note which the cursor current on, like go to definition. Then we need shortcuts to go back and go forward like ctrl+oand ctrl+i in vim.
1 Like
Looking forward to seeing either version (ctrl-p/go-to-anything (in linux)) or [[; I'm considering migrating my notes from Zim to Joplin - I make extensive use of linking across notes in Zim, residing in multiple "sub notebooks", so drag & drop doesn't work and right-clicking to copy the link to the notes and then pasting looks really cumbersome (I have a few hundred internal links)
So looking forward to a way to easily search a target note by title and insert a link to it all without using the mouse; even more awesome would be a two-step selection where first the note is searched by title and once selected, the anchors within the target note are listed so this way we can insert links to a specific section of the target note
3 Likes
I'm also very much looking forward to this, especially with a backlink feature.
Is there a road mop somewhere where feature requests / plugins could be upvoted?
2 Likes
these two plugins work great:
2 Likes
The Quick Links plugin might offer the general functionality you were looking for. It implements within the body of the Markdown editor rather than via its toolbar icons, but otherwise seems like what you're after.
[Edit: Ah, I see someone else already linked the same (plus another). Have you found something that's working for you?]
With regard to a syntax for linking to other notes, @tessus previously suggested an approach where the editor would help create links by offering an auto-complete/search popup when you type [[. This approach is also implemented by the Quick Links plugin, but using @@ instead of [[. In both cases, the link that is actually inserted into the note still uses the regular [note title](:hash) link, so no dedicated syntax is introduced.
While this approach is a great step forward and offers a large part of the usability of the [[another-note]] syntax used by similar apps, it is not a complete substitute. In particular:
- The dedicated syntax is a lot more concise. When using links in running text, the markdown source is significantly more readable when it contains
[[another-note]]than when it contains[another-note](:/ca58c582bf03455881cd9f292dfe2e88). - With a dedicated syntax, you can also link to notes that do not exist yet. This allows a workflow where you just write one note first, already putting in link to other to-be-written notes without having to break your writing flow to create these notes first (or remembering where you wanted to add links and remember to add them later). After completing the first note, you can just click the "broken" links to create the other notes next. If I understand it correctly, this kind of workflow is part of the Zettelkasten method. In addition, you can even postpone writing these linked notes further, keeping the links as a reminder that you would like to write about these subjects, or just to ensure that if you ever do decide to write about them, they are already linked (this is the wiki workflow, I guess).
Node identity
Note that having a syntax on the Markdown side is not necessarily enough, since this also heavily impacts the concept of note identity. In Joplin, notes are identified by using some immutable opaque id/hash, which are also used as filenames in storage. Looking at other apps that use this [[note]] syntax (I've briefly looked at Obsidian and Logseq), I suspect that they all use human-readable note ids/filenames. This means that a syntax like [[foo]] is essentially just a shorthand for linking to the file called foo (which works well if filenames are in a flat namespace, if directories are used for structure, the links might not be directly resolvable).
Translating this to Joplin, if a [[foo]] syntax would be introduced by itself, using e.g. the target note's title (or a slug derived from it maybe) to link, this would require some lookup from node id to filename to resolve these links, making the resulting markdown more closely tied to the Joplin app than if it would just point to a filename directly.
I am not sure if these other systems interchange the node id and title, or that the the node id is derived from the initial title and then becomes immutable, or maybe can be changed updating all backlinks, but any of these approaches seem possible and reasonable. As for updating backlinks, that is of course a little fragile, but could be manageable if backlinks are tracked in a separate metadata database table as suggested elsewhere in this thread (for displaying backlinks automatically).
Syntax
With regard to syntax, it seems the [[node-id]] syntax is quite commonly used in similar apps. The original post already mentioned NVAlt , Roam Research and Zettler , and I've also seen Obsidian and Logseq to do the same. The origin of this syntax is probably various wiki markups that also use it to create links to named pages.
I've looked to see if this syntax is somehow standardized in CommonMark, but it seems it is not in the core spec and CommonMark (probably intentionally) does not specify any extensions. I did find a very old discussion/proposal about such a syntax, that essentially suggests that [[foo]] should be a shorthand for [foo](foo).
One other thing to consider is that markdown allows "reference links", e.g.:
This paragraph contains a [link][target] with the target defined out-of-line.
[target]: httpshttps://example.org
There is also a collapsed version of this ([link][] as as shorthand for [link][link]) and reading the spec I found that CommonMark also added a shortcut version ([link] as a shorthand for [link][link]).
Possibly this syntax could also be used. For example, when you insert a link using the "Quick Links plugin method", it does not insert [another-note](:/ca58c582bf03455881cd9f292dfe2e88), but inserts:
Some running text linking to [another-note].
[another-note]: :/ca58c582bf03455881cd9f292dfe2e88
The reference definition (link target) could be maybe inserted at the end of the note, to keep them out of the way. This would solve the readability consideration above, though still not allow linking to non-existing notes.
Another approach could be to omit the "reference definition" clauses and automatically resolve reference links without a definition to other notes (based on the note title, or the filename/id if moving away from the hash as note id). i.e. just use [foo] in the running text, and if no [foo]: ... line is found, resolve that as a link to the foo page. This would allow links to non-existing pages as well (but would maybe be less suited to auto-completing links, since [ could also start the link text of a regular link...)