Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

citekey: link to BibDesk (in wiki.vim too) [feature request] #341

Closed
alexandreroberts opened this issue Apr 1, 2024 · 27 comments
Closed

Comments

@alexandreroberts
Copy link

This is a feature request just like the one I just opened for vimtex. It too is based on an old thread from a year ago about how doing so might be feasible.

What I would like is to be able to enter a single command (in the case of wiki.vim, simply <CR>) in order to open the citekey under the cursor in BibDesk (on MacOS). Unlike in vimtex, I don't think wiki.vim "knows" which .bib file to use, so perhaps it would make most sense for it to simply be a reference to whatever .bib file is open in BibDesk at the time. I think this might be what open x-bdsk://citekey (see description here) does by default anyway.

@lervag
Copy link
Owner

lervag commented Apr 2, 2024

Just for completeness, could you give one or more examples of wiki text with citekeys?

As a very simple, first step, I've added a handler for bdsk: schemes. Thus, if you write a link like bdsk:citekey, then I believe it should work as expected already.

@alexandreroberts
Copy link
Author

Just for completeness, could you give one or more examples of wiki text with citekeys?

Here is an example: See @ei2 and @BS. (The cite keys are ei2 and BS, respectively. Note that final dots do not count as part of the citekey, as we determined here.)

As a very simple, first step, I've added a handler for bdsk: schemes. Thus, if you write a link like bdsk:citekey, then I believe it should work as expected already.

I've just tested it and can confirm that it works: when I type <CR> while the cursor is over the text bdsk:ei2 in a wiki file, BibDesk opens and displays the ei2 entry.

@lervag
Copy link
Owner

lervag commented Apr 2, 2024

Ok, so what is missing now is to connect @... with bdsk:.... Or, is it? In fact, it is not. You can change it with:

let g:wiki_link_default_schemes = { 'cite': 'bdsk' }

Can you test this and see if it is actually a sufficient solution here?

@alexandreroberts
Copy link
Author

That did it! Once I added this line to my nvim configuration, it worked perfectly: with cursor over the @, e, i, or 2 in @ei2., pressing <CR> brought opened the ei2 entry in BibDesk.

As I tested it further, I noticed a "bug" related to that wiki-ft.vim query of mine from a year ago: if the citekey contains :, then wiki-ft.vim and wiki.vim treat it as if the citekey ended before the :, i.e., both in how it is highlighted and what citekey string wiki.vim passes to BibDesk. Many of my citekeys use the character :.

I think the solution to that "bug" would be the same as for .: count : as part of the citekey unless it is the very last permissible character of a citekey.

@alexandreroberts
Copy link
Author

Ditto for +, which I also use in citekeys!

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

That did it! Once I added this line to my nvim configuration, it worked perfectly: with cursor over the @, e, i, or 2 in @ei2., pressing <CR> brought opened the ei2 entry in BibDesk.

Great, glad to hear it!

As I tested it further, I noticed a "bug" related to that wiki-ft.vim query of mine from a year ago: if the citekey contains :, then wiki-ft.vim and wiki.vim treat it as if the citekey ended before the :, i.e., both in how it is highlighted and what citekey string wiki.vim passes to BibDesk. Many of my citekeys use the character :.

I think the solution to that "bug" would be the same as for .: count : as part of the citekey unless it is the very last permissible character of a citekey.

Could you give a couple of examples of this? And, just for the sake of clarity, is this a bug in wiki.vim or in wiki-ft.vim? Or both?

lervag added a commit that referenced this issue Apr 4, 2024
@lervag
Copy link
Owner

lervag commented Apr 4, 2024

Nevermind, I think I figured out what you want and I think my latest commit fixes it. Please update and test.

@alexandreroberts
Copy link
Author

Thanks for the fix! I've just tested it now, and in the case of + it works perfectly (both wiki-ft.vim, i.e., the highlighting and wiki.vim, i.e., the link to BibDesk).

In the case of : the highlighting is right, but when I type <CR> while the cursor is on a citekey that includes :, nothing happens at all.

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

Huh, strange. Can you type <leader>wl on that link and post the information you get here?

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

Also, can you give me an example of how that link looks like?

@alexandreroberts
Copy link
Author

The citekey is @john.skylitzes:histories:thurn1973. This is what wiki.vim returns:

 Type:          url
 Match:         skylitzes:histories:thurn1973
 URL:           skylitzes:histories:thurn1973
 Description:   N/A
                
 Resolved URL object: 
   url:         skylitzes:histories:thurn1973
   stripped:    histories:thurn1973
   origin:      /Users/robe941/Documents/wikiNotepad/index.wiki
   scheme:      skylitzes

So it looks like . and : don't work together in the same citekey.

Here is a screenshot showing that this citekey is nevertheless correctly highlighted:

Screenshot 2024-04-04 at 9 00 51 PM

@alexandreroberts
Copy link
Author

Ah, but curiously when I put my cursor over the john part, this is what I get instead:

 Type:          cite
 Match:         @john.skylitzes:histories:thurn1973
 URL:           bdsk:john.skylitzes:histories:thurn1973
 URL (raw):     john.skylitzes:histories:thurn1973
 Description:   N/A
                
 Resolved URL object: 
   url:         bdsk:john.skylitzes:histories:thurn1973
   stripped:    john.skylitzes:histories:thurn1973
   origin:      /Users/robe941/Documents/wikiNotepad/index.wiki
   scheme:      bdsk

But even then, <CR> does nothing.

@alexandreroberts
Copy link
Author

This makes me wonder whether there are two problems:

  1. wiki.vim isn't parsing it quite right
  2. even when it does parse it right, maybe bdsk: links that include : don't work. Maybe the colons need to be somehow escaped in the URL?

lervag added a commit that referenced this issue Apr 4, 2024
@lervag
Copy link
Owner

lervag commented Apr 4, 2024

I pushed another commit that at least fixes one of these issues. That is, the type should now be cite.

However, the next problem is probably a bit harder. One thing we can try is to see if url encoding works here. You could try something like this:

function! ResolverBdsk(url) abort
  let a:url.stripped = wiki#url#utils#url_encode(a:url.stripped)
  return a:url
endfunction

" Change the wiki scheme resolver
let g:wiki_link_schemes = {
      \ 'bdsk': {
      \   'resolver': function('MyWikiResolver'),
      \ }
      \}

Or, simply just try this to use this link: <bdsk:john.skylitzes%3Ahistories%3Athurn1973>. The %3A is the url encoding for a colon.

@alexandreroberts
Copy link
Author

alexandreroberts commented Apr 4, 2024

The simple link works!

The function to generalize this solution returns an error message for me:
Screenshot 2024-04-04 at 9 47 27 PM

I also get an error when simply opening my wiki in nvim. Line 18 is the line in the relevant config file that reads let g:wiki_link_schemes = {:

Screenshot 2024-04-04 at 9 47 45 PM

This is the beginning of that config file (plugin/wiki.vim):

" Wiki.vim setup
let g:wiki_root = '~/Documents/wikiNotepad/' 
let g:wiki_filetypes = ['wiki']
let g:wiki_link_target_type = 'wiki'
let g:wiki_link_extension = ''
"let g:wiki_select_method = 'fzf'

" citekeys link to BibDesk
let g:wiki_link_default_schemes = { 'cite': 'bdsk' }

" deal with colons in citekeys
function! ResolverBdsk(url) abort
  let a:url.stripped = wiki#url#utils#url_encode(a:url.stripped)
  return a:url
endfunction

" tell wiki.vim to create links using function to deal with colons
let g:wiki_link_schemes = {
      \ 'bdsk': {
      \   'resolver': function('MyWikiResolver'),
      \ }
      \}

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

Sorry, my mistake: Notice the name mismatch: MyWikiResolver should be ResolverBdsk.

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

I could add this url encoding as a default built-in behaviour here, but if so, I should first check if it works with Zotero.

@alexandreroberts
Copy link
Author

That fixed it! Now the last link (the one with the colon) works perfectly.

I do think it would make sense to make this the default built-in behavior, assuming it doesn't cause any problems for Zotero. Maybe it could be used only in the case that the BibDesk option is set?

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

Yes. However, I believe it does make sense to do this at the url level. That is, if I did url encoding only for the cite links, then it won't apply the url encoding for e.g. [[bdsk:LINK]] or <bdsk:...> or similar, only for @my:citation.

And as such, I think the pragmatic choice for now is to just add this as the default behaviour for bdsk url's, and then consider this for Zotero if anyone should want it/ask for it.

@alexandreroberts
Copy link
Author

alexandreroberts commented Apr 4, 2024 via email

lervag added a commit that referenced this issue Apr 4, 2024
@lervag
Copy link
Owner

lervag commented Apr 4, 2024

No problem; I pushed the change now, so you can remove the latest update to your config. Let me know if it works :)

@alexandreroberts
Copy link
Author

I just updated it. This is now the error that I get:

Screenshot 2024-04-04 at 10 10 45 PM

@alexandreroberts
Copy link
Author

(I also removed the additional code from my config.)

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

Sorry! I'll fix that asap.

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

There...

lervag added a commit that referenced this issue Apr 4, 2024
@alexandreroberts
Copy link
Author

It works now, thank you!

@lervag
Copy link
Owner

lervag commented Apr 4, 2024

Great, glad to hear it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants