RyotaUshio / obsidian-pdf-plus

PDF++: The most Obsidian-native PDF annotation, viewing & editing tool ever. Comes with optional Vim keybindings.
https://ryotaushio.github.io/obsidian-pdf-plus/
MIT License
823 stars 15 forks source link

[FR] Automatically hide internal link parameters (removing need for link description) #100

Open mdbraber opened 8 months ago

mdbraber commented 8 months ago

Describe your request

When adding backlinks, PDF++ also has to add a pipe symbol to show a 'nicer' version of the link without the parameters: [[File.pdf#page=1&selection=0,4,2,8|File.pdf]]

This causes problems if File.pdf gets renamed, because although the first File.pdf in the internal link will be renamed, the second part (rather a description than a link) will not be renamed, which can be confusing.

A solution would be to change the way Obsidian shows internal links. There is a plugin with functionality which, for internal links, hides the part before the pound sign (#): https://github.com/scottwillmoore/obsidian-short-links (it's built to only show headings rather than full-length internal links). But this functionality can easily be adapted to do the opposite, namely hide everything after the pound sign.

If this functionality could be integrated in PDF++ it could be enabled for internal links that end with pdf#


Quick POC, clone the obsidian-short-links plugin, go to file sources/EditorExtension.ts and change L183: https://github.com/scottwillmoore/obsidian-short-links/blob/main/sources/editorExtension.ts#L183 to

builder.add(linkFrom + internalLink.lastHeading.from - 1, linkFrom + internalLink.lastHeading.to, Decoration.replace({}));

and comment out L200-203 and it will hide everything before the # sign in Live Preview

RyotaUshio commented 8 months ago

Thanks for the idea and I totally get your point. But isn't it something that should be implemented by the short link plugin independently from PDF++? Like, that plugin can add an option to hide the subpath (i.e. after-hash part) instead of the file name depending on the file extension. To me, it sounds more natural and reasonable in terms of the modularity of plugins. Also this approach can be easily extended file types other than PDF.

mdbraber commented 8 months ago

@RyotaUshio yes you're right, it might best fit the Short Links plugin, rather than PDF++. My idea is although that (1) it would need a pattern check for links (ending with .pdf) so that might make it more PDF++ specific; (2) it might be that more PDF++ users want this functionality by default (although they might just install Short Links of course)

mdbraber commented 8 months ago

I've created an FR to add this to the Short Links plugin: https://github.com/scottwillmoore/obsidian-short-links/issues/17