c3er/mdview

Anchor Links Open a Subprocess Instead of Jumping to the Anchor

mmillar-bolis opened this issue · 9 comments

Hey there, c3er!

I hope your holidays were good. I am still loving and using your program almost every day to view my writing and notes. Of course, thank you again for your hard work!

Recently, I noticed an interesting behavior when clicking on anchor links.

Here's how I tend to implement them in my text:

[Link Text](#html-anchor)

# html anchor

What happens when I click on an anchor link is that another process starts, opens the file, and then jumps to the anchor, instead of just jumping to the anchor alone.

A small issue that is has not impeded my work, but I thought you would like to know.

Thank you again and happy new years!

c3er commented

Hi @mmillar-bolis,

I wish you a happy new year too!

The described behavior is intentional. I wanted to keep it simple and decided to just open a new window for each link to a local ASCII based file (non Markdown files are displayed as raw text with syntax highlighting). If a link would open inside the same window, something like a back button would be necessary. I also find it advantageous to be able to have different places of a document open in their own window respectively.

But if it's still an issue for you, we may discuss, how to implement the desired behavior and whether that behavior should be configurable.

Best regards

Hey @c3er,

Oh okay, that actually makes a lot of sense, and I must admit, I have also been using multiple windows for document editing, so I see your point. Perhaps I am falling back on my old vim habits of jumping around the document a bit too much. The point about the back button is something I also didn't consider.

I would say that this is not a priority issue as I think I misinterpreted the functionality as undesired. My bad! :) When used as a minimal document reader, I wonder if anchor links are something that may come up later, but as it's primary intention as a viewer that fits into one's current toolkit, I don't see any need to change the current behavior.

If it were to be implemented at some point, I would propose the back button be in the View dropdown, alongside Refresh. As for configurability, I'm a bit stumped there. I could see changing default behavior like anchor link handling as fitting in with the build options. But maybe it should just a temporary behavior, like the toggle for External Content. Though, I don't know how difficult any such options might be to implement.

Thanks again!

c3er commented

I could see changing default behavior like anchor link handling as fitting in with the build options.

I don't think adding a build option for the behavior would be a good idea. Shall I then publish two releases for every version and supported platform? :) I'd introduce a dropdown "Option" that would possibly begin with one item "Open files in new window" or something. I think the implementation wouldn't be too difficult. The implementation of the "back" and "forward" behavior would be slightly more difficult, since I'd have to implement management for two stacks and maybe some additional logic.

Another idea that came just in my mind and seems better to me would be to change the behavior without any options and if one wants to open a file link in a new window, they have to use the middle mouse button.

My question to you: shall I implement back/forward inside the same window, i.e. does the current behavior annoy you (keep in mind that a minor issue is still an issue)?

c3er commented

BTW: doesn't vim allow to open the same file in two views, so you can see and edit the file at different places more easily? The editors I use (VS and VS Code) have this feature.

Shall I then publish two releases for every version and supported platform?

No, that's an excellent point that I think I failed to elaborate my entire thought on. In that scenario, I guess I imagines no change to the default behavior and no publishing with that behavior, just an option available to particularly stubborn people, hahaha. I absolutely agree with you that resorting to publishing two releases would be a bad idea.

if one wants to open a file link in a new window, they have to use the middle mouse button.

I really respect the minimal design and don't want to push you towards a cluttered interface, so this sounds like a fantastic idea! As to your final question, if I were to be honest, I think I would prefer a default behavior of back and forward in the same window. If it wouldn't impede the way you use your own program, yeah I'm in support of you adding it.

The funny thing about vim and I is that I am very still much learning it beyond basic movements. Yeah, I can pull a file open in multiple buffers, which is pretty cool! Unfortunately, with Markdown I can't see all of the rich styling even in GVim (just italics and element highlighting), which pushes me to a more robust viewer. Since I don't work professionally with computers, I've kind of been taking my time to learn it, haha.

c3er commented

If it wouldn't impede the way you use your own program, yeah I'm in support of you adding it.

Well, then it will be done! Coincidentally I have some time this month. But it could still take a while, because I like to do a major refactoring of the tool because I'm not happy with the current state of the code and I feel it is time for that refactoring before implementing additional features.

Yeah, that sounds like a good order to carry it out, and it makes perfect sense that it will take some time. No reason to add features now and risk them breaking in a refactor.

c3er commented

It took a long time, but the new release with the implementation of your request is now out!

If you discover some unexpected and/or unwanted behavior regarding this request, then please open a new issue.

Enjoy!

Thank you so much! I still use mdview daily and this makes it even better! Also, thank you for adding extended markdown features! I tend to use a lot of footnotes recently, so this is a huge plus. Thank you again!!