Click on an internal link in a pinned note should open a brand new tab

Use case or problem

When I’m in a pinned note, if I click an internal link, the target note will open in a different tab. The problem is that sometimes it opens a brand new tab (if there is no unpinned tab yet), or it reuses some arbitrary unpinned tab (the first it finds from left-to-right, probably).

This is inconsistent and surprising as it essentially “hides” the content of one of tabs (I used to have a tab there and now it’s hidden and I have no idea what disappeared until I go back in history).

Proposed solution

Simple: always open a brand new tab.

Now I recognize that it’s theoretically possible that some people may want the current behavior: people who both want to use pinned tabs and also want to reuse one or more unpinned tabs as much as possible. But is that common? It seems unlikely to me.

Current workaround (optional)

Probably, recognizing that I’m in a pinned tab. And if I am, instead of clicking on the internal link, I will always ⌘Click. The problem is that I have to think :slight_smile:

Related feature requests (optional)

Related but not the same: Pinned note does not open if that note is selected


not sure how common it is, but i uses that flow (1 pinned tab and 1 “free” tab) as part of my weekly review. i would do weekly summary and monthly summary (which both has links to daily and weekly based on templater). for example i would pin the weekly and then click on the linked daily notes to go through each one.

i would say always use the cmd/ctrl + click should be the solution to your problem “have to think”. you propose would require you to think "am i in a pinned tab? if so i just click, but if i’m not, i must cmd/ctrl + click.

just my opinion. to add to the flavour

If I “always” hold Cmd/Ctrl + click, then I’m stuck with IDE-style navigation where tabs are never reused whereas most of the time I do want to use browser-style navigation where unpinned tabs are reused. So I lose a major feature: if I wanted to navigate like in a browser, I’d have to click, then go back to the previous tab and close it, and then go back to the new tab—not practical.

Conversely, it doesn’t sound like you intend to continue using the content of the unpinned tab that you’re keeping around (correct me if I’m wrong about your workflow), so I could suggest to you that once you’re done with your unpinned tab, you can close it before you go back to the pinned tab, in anticipation of clicking links inside of that pinned tab that would open a brand new tab. This wouldn’t mean hitting more keys for you since you’re already hitting another key (or mouse click) to switch tabs anyway, and it’s conceptually consistent: when you’re done with a note and about to navigate to another tab, it makes sense to close it to signify that you’re done. Whereas in my case, I keep tabs opened because I’m not done with them, so having a pinned tab’s links “overwrite” one of my unpinned tabs is disruptive (and again, it’s practically unpredictable which one will be overwritten: it could be an unpinned tab I opened a few hours ago).

Current behavior (reusing tabs) is confusing for me. I’m used to pinned tabs in Firefox and when I click on link in pinned tab, new tab is created.
Maybe compromise can be to have some settings for reusing tabs, but default value (in my opinion) should be new tab.


The current behavior is especially a problem on phones, where the tab list is hidden so it’s easy to not notice that an open note has been replaced.


will be implemented in v1.3. No ETAs.


This is awesome. Similar to this it would be nice if this would be implemented as well :smiley:

I am definitely one of those people. The new behavior – “Clicking on links in a pinned tab will now open a new tab instead of reusing a random existing tab” – breaks an important workflow that I use daily. In this workflow, I have an index of a knowledge base on the left, and clicking links on the left opens articles on the right. This will not work any more, and I really wish this was configurable. Perhaps the developers can consider making this behavior optional.

I realize that I can place the index in a sidebar, but that’s worse than it was before, because my sidebar is split horizontally, and so I can only allocate part of the vertical space to the index note. Also, for me the optimal width of the side bar is different (smaller) than the optimal width of an index note, so I would be constantly resizing things depending on what I’m doing. All in all, not a replacement for the old behavior.

1 Like

This was undone in v1.3.4