zim-wiki-ffap on display text of link constructs wrong path

[mooseyboots]

i just tried the latest commit, and it doesn't work for me.

eg if i have a link [[top:middle:lower level multi words][description multi words]], put point on it somewhere, and zim-wiki-ffap, it creates a new page with the word at point as word.txt for the filename.

(save-excursion
             (skip-chars-forward "^]|") ; forward to end of link
             ;; (skip-chars-backward "^[") ; move back to start
                     (search-backward "[[")
                     (forward-char 2)
             (ffap-string-at-point 'file))

here (ffap-string-at-point 'file) returns the one word. seeing as you go from end to beginning of the link, why not just mark and copy it? alternatively you cd add a text prop for only the inner part of the link, excluding the [[ | ]], then when point is on alink, you grab the range of the text prop and that's your string.

[WillForan]

I think dokuwiki (and zim-wiki) link syntax is [[path|text]] (vs [[path][text]] ) but it looks like the way this is searching for a path, it shouldn't matter. I hope there's no pathological filename containing [.

~~Testing just now, the zimwiki desktop app replaces spaces in the path with _ when resolving the file. I like the suggestion to mark and copy. space-> _ on the results would be easier than trying to get ffap to work with spaces(?)~~ This is already handled by the wiki2path functions. 11e077a's now using search-between-points instead of ffap as suggested!

It looks like dokuwiki-mode has different text proprieties for the two link parts. Using those seems like an economic way to get the link path -- it's already been processed. But I'm clueless how to do that in elisp (and how to apply dokuwiki-mode on the buffer within an ERT test)

[mooseyboots]

ah, i didn't realize you didn't have any parsing implemented for zim links.

you'd need to parse the zim tree style too, ie: [[top level:next level down:actual multi word file.txt|description]].

in zim the levels are folders (and a file of course) and the last is a text file, so you need to convert it to a file path, using / and as you mentioned, _ for the spaces.

no probs if you've not got that far yet, i just didn't realize! the interface looks so nice i thought it had all the bells and whistles. that said, file navigation is a pretty core feature.

i wonder if dokuwiki propertizing cd be modified to propertize the first part of the link differently to the [[ | ]], then you'd have your zim link in full more precisely.

(unforch i don't have the time, at least at the moment, to hack on this much myself.)

[WillForan]

sorry I'm writing in circles. I think zim-wiki-wiki2path has solidly handled wiki path to file path: :a:foo bar to (zim-wiki-root)/a/foo_bar.txt. And as of the most recent commit, extracting the complete wiki path at a point should also find the whole :a:foo bar spaces and all. That's passed onto wiki2path to open the actual file the path points to by e.g. zim-wiki-ffap [default binding: C-c C-o or hydra z o]).

But the wiki path extraction at point will fail if \| or \]is part of the wiki path. I'm hoping that's not possible.

[I'd also love to add a click action to e.g. dokuwiki-link text-property, but haven't figured out how to do that yet.]