Plugin: Quick Links Plus — link notes, headings & anchors (@@, @@#, @@id)

Plugins
1

Hi everyone,

I'd like to share Quick Links Plus, a reworked take on Roman Musin's
Quick Links plugin for the current (CodeMirror 6) Markdown editor.

Editor autocompletions

  • @@ — link to a note
  • @@# — link to a heading or inline anchor across all notes, grouped by note
  • @@id — insert a short, note-unique anchor id

Viewer

  • A small chain link icon mark next to every heading and inline anchor — click it to copy a Joplin link to that exact spot.

Settings let you toggle each feature, set the anchor-id length, and show the
notebook name in results.

Full disclosure: this plugin was developed end-to-end with Anthropic's Claude
Opus 4.8, and there is no active human maintainer behind it. It's shared
as-is, without warranty. Contributions and maintainers are very welcome — if
you'd like to improve or take over the project (including publishing it to npm
for the in-app catalog), please open an issue or PR.

Credits to Roman Musin (Quick Links) and Hieu-Thi Luong
(Copy Anchor Link), both MIT-licensed, which this builds on. Licensed MIT.

Repo: GitHub - D0m7n7c/joplin-plugin-quick-links-plus: Quickly link to notes, headings and anchors in Joplin using @@... or copy anchor link form the viewer. · GitHub

Install: download the .jpl, then in Joplin go to
Options → Plugins → Install from file.

Feedback welcome!

2

Thank you very much for extending the QuickLink Plug-in. I really appreciate it. I thought about it, the last weeks to ask somebody to help to program this very helpful feature, nearly the same as from the Note Plug-in System. Thank you very much for your work! :tada::smiling_face_with_sunglasses::+1:

3

Thank you very much. I've also added support for tab completion.

4

Any chance you could please elaborate a little bit more about how you actually did it? Any prompt to share? Or any useful CLAUDE.md skills for Joplin Plugin development in general? Before this did you or did you not have prior Joplin Plugin development knowlege or experience? A list of 2-3 things you wished you knew before starting?

I guess more and more users will be able to develop their own very customized plugins this way, this is an interesting direction which has its own tradeoffs though.

5

@D0m7n7c It would be helpfull if you cloud upload this plugin into the official Joplin plugin repository.

6

I have now published the plugin to the repository. It's mature enough to warrant a release.

7

Thank you very much for putting this plug-in into the official repository. I just tried and found it!

Moreover, I think this plugin is really important for Joplin because it extends Joplin's abilities, the same as it is available for, e.g., Obsidian and LogSeq. I really love Joplin, but after the old "Node plugin System" didn't work anymore in Joplin, I have a need for a quick links plus plugin that not only makes it able to refer to the note name but also to the headers, like it's available in Obsidian and LogSeq. Also, for competition to these programs, I think it's very important, so thank you very much, and I hope this plugin will become recommended by Joplin soon. :+1:

8

Got very excited about the possibility to search across heading within notes. However, not all are found. I have a specific subject that regularly reoccurs in my Journal notes, When I use @@#subject the plugin first looks in notebooks where this subject is in the notebook name, then in the title but not in the headings of the current notebook. Maybe because there are too many instances?

9

Thanks — thanks to your forum post, I took a closer look at the feature, and I think I've identified the problem and found a suitable solution.

First a small clarification: @@# doesn't actually search notebook names. It searches note titles and note bodies, then sorts results by how close each note's notebook is to the one you're currently in — so what looks like "notebook name first" is really "notes in nearby notebooks first".

To explain the real issue, here are the limits the feature works with: for each search it pulls in up to 30 matching notes, and shows up to 60 entries total. Those limits matter for what follows.

The problem is how note titles are handled. Say your subject appears in several note titles — "Subject I", "Subject II", "PrefixSubject". When you type @@#Subject, if a note's title contains "Subject", the plugin currently pulls in all of that note's headings — even ones unrelated to your search. So a single title-matching note with, say, 30 headings fills half of the 60-entry list on its own with entries that have nothing to do with what you searched.

So it's not that you hit the limit with genuine matches — it's that one title-matching note spends the limit on unrelated headings, crowding out the real heading matches you're after. Without those limits it would still be noise; the limits just make the noise actively hide the results you want.

Since you're after the headings themselves, the fix is to stop letting a note's title pull in all its headings — @@#Subject will only match headings and anchors actually called "Subject", so the real matches stop getting buried.

I'll also add a deliberate way to go one level deeper with a trailing slash, for when you know where something is but not its exact name. @@Subject I/ would list the headings inside the note "Subject I", and @@#Subject/ would list the sub-headings and anchors nested under a heading called "Subject". Same idea either way — the slash means "go into what I just named" — so you can drill down on purpose instead of everything being dumped on you at once.

I'll include that in the next version — thank you very much for your reply; it has inspired me to rethink the “search function.”

10

I was hoping that searching for headings would be search first headings, then the note title, preferably starting in the current note book. So in other words @@#subject should not look for the headings inside the notes with subject in the title, but any notes with subject in a heading.

To give an example, sometimes I use the heading "Budget" in my Journal notes. It would be cool to be able to link to a specific budget section in one of my Journal notes.

11

I think you may have slightly misunderstood my previous post. What you're describing is actually how it works in the latest version, which is now available to download. @@#Budget searches headings (and anchors) directly, rather than pulling in all headings from notes with "Budget" in the title. Feel free to give it a try.

12

Hi. Thanks!

Seems to me that one of my fave features from the original is missing - the last 2 options used to be 'create note' and 'create todo', which created the respective note in the same notebook, using entered text as title.

Any chance you'll be adding that? :folded_hands:t2:

13

Thanks a lot for your work @D0m7n7c. I have been using the plugin for a while (and I was an avid user of the previous plugin) and I am happy to have this new functionality.

A few feedbacks regarding my personal usage, if I may:

  • The plugin cannot be installed on Android for now (which is possible with the original plugin). Such a feature would be a great addition for easy notes linking on the Android app.
  • I am personally very much looking forward to the feature @@approximate-note-title/approximate-headingthat you described above, as I often know in which note a specific heading is, but don't remember the exact note and heading names
  • The original plugin lists the notes in last edition order before the first letters are types right after @@. I find this very convenient, as I regularly create a new note somewhere on a notebook and want to reference it straight away on an already existing note. It's certainly not how everybody works, but adding an option to sort the notes by order of edition in the plugin options would be a nice addition IMO.

Hope that can give some ideas :slight_smile:

14

Hi everyone,

Regarding the additional features you've suggested for the plugin, thank you for your ideas. Most of the features that are missing compared to the original are intentional design decisions and are therefore not planned for implementation.

As for an Android port, there are currently no plans to support one. If anyone has the necessary experience and would like to contribute, feel free to open a pull request on GitHub.

Regarding the behaviour when @@ is empty, this is largely a matter of personal preference. If you'd like to see a different default, please open a feature request on GitHub so we can discuss and evaluate what would make the most sensible default behaviour.

I've also written a guide on how to contribute via GitHub. Please read it before submitting an issue or pull request.