Use gf/gx to open files/URLs from anywhere in a link

[victorkristof]

Hi there! I really enjoy your plugin, that's really great great work.

I'm using Markdown to take notes, and I often link one note to another like this:

Look at this [other note](other-note.md).
              ^

With the cursor positioned between the squared brackets (indicated by ^), I tried to use gf to open other-note.md but it didn't work.

It does work with gx though (and when the link is a URL).

Any chance to make gf behave like gx?

Thanks again for the great plugin!

[samarulmeu]

I do not think is a wise thing to change the standard behaviour of the gf.

There is another way of linking files using [[some-file.md]] and then you can use gf inside the [[

[victorkristof]

But this is then inconsistent with gx, which does work from inside the squared bracket - no?

Good point for [[some-file.md]] but it lacks the (description), which is useful.

[SidOfc]

Hello @victorkristof!

Thank you for taking the time to submit an issue, it's always appreciated :)
I must say though, that mkdx touches neither of these mappings, so both gx and gf should behave like regular vim/nvim.

I checked :h gx and it takes me to a netrw-gx section whereas :h gf takes me to a built-in section, perhaps it is netrw that enables this enhanced version of gx to work for you, maybe reading these help sections will give you some clarity as to why they work like they do.

With that said, I think you can remap gf to gx in your vimrc to solve the problem however this may cause issues when using gf in other places. In turn this can be solved by only applying the override for FileType markdown buffers using an autocmd (:h autocmd).

Let me know what you think, or why I should still implement this as a native feature of mkdx, personally I don't think it's worth it if it can be solved by remapping within vimrc without too much pain :)

[victorkristof]

Alright, my bad, actually gx doesn't behave like I thought it did. It doesn't open the URL from within the brackets. Sorry for that...

That being said, I still think it could be a nice-to-have feature for both gf and gx to open a file or a URL when the cursor is within the brackets. (I think some other Markdown plugins have this feature, but I prefer yours :p).

I also understand, however, the philosophy of your plugin to keep things simple and minimal, which I really like and which @samarulmeu pointed out ("I do not think is a wise thing to change the standard behaviour of the gf.").

Thank you again and feel free to close this issue!

[SidOfc]

@victorkristof, seeing you mentioned other plugins do support it, it might actually be interesting to support it as "disabled by default, when enabled, only apply to markdown filetype buffers".

I've done this with many features as to not step on users' preferences, if they want something from mkdx, they can choose to opt-in instead which allows me to make quite a lot of crazy functionality :)

I'll keep this issue open for now and think about it a bit, I want to make sure that it provides good functionality and doesn't impede with default behavior too much if possible. I'm not sure when I'll add it but I don't like keeping issues open for too long if it can be helped :)

Could you help me out by specifying some plugins that provide this functionality? Then I can take a look at what they did and perhaps save myself some time finding them.

[victorkristof]

Hey @SidOfc, this sounds great!

Could you help me out by specifying some plugins that provide this functionality?

I've seen vim-markdown implement this for gx. As per this comment, here is the entry point to their implementation of the feature.

I hope this helps and thanks again for the great work!

[SidOfc]

Cool cool @victorkristof, thank you for gathering the info,

I'm a bit busy coming week but may be able to squeeze it in somewhere, otherwise possibly coming weekend.

Thanks for your patience in the meantime :)

[victorkristof]

Sure, no problem! Thank you for the great work!

(I edited the title of this issue.)

[SidOfc]

Alright @victorkristof, should be there as well now in master (no crazy count bugs this time I promise :P)

What I did was just enhance gf since it is faster to press than gx, this also allows netrw to keep control over gx even though that can also be "proxied" if need be.

It will open files and URL's from anywhere in a markdown link but anywhere else it acts like regular gf. Open for any suggestions you may have about this, if all is well I think we can close this one too :)

[victorkristof]

Just tested it - really cool! A few bugs on my side:

1. When using gf outside of a link (say, on "text"), it shows

Error detected while processing function mkdx#gf:
line   11:
E447: Can't find file "text" in path

It should only display E447: Can't find file "text" in path.

2. When the link is a path to a file, then it doesn't work when the cursor is in the "parenthesis" part of the link:

[a file](path/to/file.txt) >> works (opens file.txt in a new buffer)
 ^
[a file](path/to/file.txt) >> doesn't work (nothing happens)
         ^

It works fine when path/to/file.txt is not in a link, and it works with URLs in all cases.

3. This is rather a comment about how the feature works. I think it is a bit counter-intuitive to have gf open both files and URLs, as gx is usually used to open URLs. That is, I would expect to use gf and gx as I would usually do. It would just change the scope of it to capture their behavior from inside the whole link object, as you implemented :)

I understand your argument of "gf is faster to type than gx", but it differs significantly to what one is used to. I'm not sure I understand this sentence:

this also allows netrw to keep control over gx even though that can also be "proxied" if need be.

Thanks!

[samarulmeu]

My thoughts on the subject

1. When the link is a path to a file, then it doesn't work when the cursor is in the "parenthesis" part of the link:

[a file](path/to/file.txt) >> works (opens file.txt in a new buffer)
 ^
[a file](path/to/file.txt) >> doesn't work (nothing happens)
         ^

I agree with @victorkristof that this is not nice. The standard behavior of gf must still be available. I think that a plugin should try as much as it can not to overwrite the standard behavior of vi. And is easier to remember gf (f from file).

Thank you both for making the plugin better.

[SidOfc]

Alright, cheers for the feedback!

I believe the first point is just about verbosity of the error, so now it will require you to press "enter" explicitly whereas before it would just show up in the bottom. Will fix that one.

I'll also look into the second issue as well, it should function exactly like gf, all I'm doing is moving the cursor to the position of the file (inbetween parens) and then executing a rergular gf.

About the third issue, gx already works the way it does right? So you can already open URL's with it? In that case isn't it also an option to just ignore the functionality of being able to open a URL with gf also? This really is a matter of taste and I would "personally" prefer to have them unified if it can make a clear distinction between what is a URL versus what is a file (the "Do What I Want" idea)

Also @samarulmeu I decided it would not interfere too much (I understand right now the verbose error makes it more annoying) since it's only different while on markdown links, you can, of course disable the mapping: https://github.com/sidofc/mkdx#unmapping-functionality-using-plug

map <Plug> <Plug>(mkdx-gf)

[samarulmeu]

Actually my problem was with issue no. 2 of @victorkristof . gf not opening files inside a markdown link. Only now I've seen the wrong numbering in the quote.

I like the new way gf opens the link to the file, buy I would also prefer the default behaviour of gf to be available.

[SidOfc]

Of course @samarulmeu I understand, this is indeed not intended but rather a bug which I am currently working on :)

[SidOfc]

@samarulmeu @victorkristof

1 should be fixed
2 should also be fixed
3 is something that I need more info for, if this behavior is annoying or can be ignored instead, It's not exactly clear what I should here from my perspective (also since my opinion differs on it from you guys)

Cheers for pointing these things out, 1 and 2 were definitely unintended bugs and perhaps 3 is too, looking forward to your replies 👍

[SidOfc]

I'd also like to stress that both of you have been very useful and constructive during all this, thanks for that and taking the time to think about what is good and bad behavior, these are usually things I have to figure out by myself. It really is lovely to have multiple brains crunching on these scenario's :)

[samarulmeu]

Thank for your kind words. But from my part, all the praise goes to you as you are doing the hard work.

Now gf works as expected.

Concerning 3 I also think that gf and gx should have different behavior like in normal vim (although gx is provided by netrw).

Some new issue that I discovered: it will be nice to have the same thing on images too ![image](image.png). Having the cursor on image using gx to open the image with external program, as gx does when positioned on image.png.

Thank you for your prompt answers and solutions. You are amazing and the plugin is getting better and better.

[SidOfc]

@samarulmeu the gf mapping now also supports opening images from anywhere in a markdown link, it basically works the same way as it does with URLs now :)

edit: it uses the existing g:mkdx#settings.image_extension_pattern setting to determine what images are based on extension as well.

As for doing this for gx, I can also override it to work like mkdx#gf, basically both keys would be mapped to the same functionality, is that something we'd be interested in?

[SidOfc]

I'd also like to expand on some reasoning actually.
I think that the mnemonics could also be defined as follows:

• gf could also mean go find, which would make it mentally ambiguous.
• gx could also mean go explore, which would be equally ambiguous.

I know Vim literally specifies gf as mnemonic for goto file but don't think it must be a "local" file for that reason (a webpage is also a file, just served over some other protocol and using a different program, ditto with images, but those are actually local files).

To me, having two mappings with "half-assed" functionality is worse than having one (or both) act the same way in this case. Since allowing full functionality for both mappings allows for more freedom, and no punishment for using the "wrong key for the job".

I'm not sure if any or all of it makes sense however, it's just me theorizing about it a bit, happy to hear any thought you guys may have :)

[samarulmeu]

Thank you for the quick answer and solution. I start by apologizing, but it should have been the other way around. To be consistent gx should have the behavior that you've now implemented with gf. gx should open external program for viewing images and gf opening them in vim (no use of it this way, but this is standard vim).

Hope I was clear enough.

From here:

gf open in the same window ("goto file")

So, I think that in order to preserve the spirit we should use gf for opening inside vi (goto locally), and gx for opening outside (calling other program --- browser, image viewer etc.). Or at least this is the way I see it.

[SidOfc]

I understand this @samarulmeu, I mentioned that I know that Vim literally defines this as goto file :)
My question is though, where is the harm in allowing both to do exactly the same? e.g. both handle internal file opening and external file handling?

If you want to use gx on links? You can, wanna use gf because its faster? You can.
This is mainly the point I'm trying to get across here. I can easily map gx to do everything that gf does and you can then proceed to use them however you want, since they both handle all scenario's.

I just see no reason to punish someone for trying to open a link with gf because "it must be done with gx".

[SidOfc]

Or well, that is if I make gx act like gf which currently it does not, but is very easy to add.
Part of the point is also that you think from your point of view, and I think from mine, these already differ since I would like to use gf to do both as opposed to being "forced" to use gx for external stuff anyways.

[SidOfc]

Oke, I just remapped gx to be exactly the same as mkdx's gf in every respect so now you should may be able to see what I mean with this flexibility :)

[SidOfc]

Finally, if we really do want to respect the spirit of Vim, this is something I can't actually deny either when I think about it. In this case I can add a setting to mkdx (which will then also be enabled by default, e.g. respect Vim by default) which will limit gx to external and gf to internal functionality.

I think I'll actually just go ahead and add this setting and I'll just edit my vimrc to allow the "non-vim" behavior for myself :)

[samarulmeu]

My apologies! I've seen your second message only later.

I updated to the latest version but in this case

![image](image.png)
   ^

if I press gx it doesn't open an external viewer. gf does.

About the gf vs gx issues. I get your point of view and, indeed, gf is easier to press, but you have to consider that most people start learning vim and have a certain expectation for standard commands. For me a great plugin is the one that does not change the way vim acts, but adds something extra.

[SidOfc]

@samarulmeu alright, think I've got it implemented by default the way you and victor initially suggested. gf will only be internal, gx will only be external, by setting g:mkdx#settings.gf_on_steroids = 1 it allows both gx as well as gf to be used interchangably.

I've also fixed the issue with gx, it actually refused to map before because netrw already maps it by default, for markdown files I'm allowing mkdx to overwrite netrw's gx mapping now.

Thinking about it I was primarily the one wanting flexibility whereas I had two votes for default implementation, so I could have been less stubborn in this process. I've also shot myself in the foot plenty of times with plugins overriding Vim's defaults, leaving me in the dust as to why something doesn't work sometimes so your remark about expectations is definitely something I can sympathize with :)

Are there any other issues you can see samarulmeu?

[samarulmeu]

Thank you so much! That is great. For the moment nothing I can see. And also toggling bold, italic (#101) was a nice touch. I was missing it, but as I work my way into vim using VISUAL mode and different commands I thought is a way to learn. So much easier now!

Again, great job!

[SidOfc]

Alright, I'll also wait for @victorkristof to report back and to let the functionality "sink in" a bit, perhaps something may pop up later still. In any case I'm glad you were able to change my mind since I do think you are correct about key expectations (especially for folks learning Vim and dabbling around with plugins).

If victor also says it's good as-is then I will proceed to close this issue. Of course if you or anyone else reading this finds one please feel free to reopen at any time!

Now I'm going to update the docs to reflect recent changes as I don't think there will be any other behavioral changes.

As usual, thanks for the feedback! 👍

[victorkristof]

This is absolutely perfect! No bug to report, and the behavior of gf and gx is exactly how I expected it!

Thank you @samarulmeu for providing great arguments to have it that way :)
And of course kudos to @SidOfc for implementing this amazing plugin!

Have a nice weekend both of you and thank you for the discussions.

[SidOfc]

Alright, closing this one, have a good remainder of the weekend!