Lua configuration breaking due to weirdness

trev-dev commented 1 year ago

This is not a real issue, just more a point of discussion. Quite frankly I don't know why I do this to myself. I have a perfectly good working vim9script configuration and a Neovim config where I just slap legacy vimscript into a vim.cmd.

But NO. I have to figure out the maximalist Lua way of doing things because what's the point of a super fast Jit compiled language if you're not going to use it, right?

Note that I choose to open an "issue" (discussion) here purely for context. I am also using lazy.nvim in Neovim for packages, and the built in package management for vim9.

I have the following vim9script configuration:

The vim9script way

## Wiki.vim {{{
g:wiki_root = "~/Wiki"
g:wiki_filetypes = ["md"]
g:wiki_link_extension = ".md"
g:wiki_link_target_type = "md"

def FrontmatterTagParser(str: string): list<string>
  return str
    -> substitute('"\|''', '', 'g')
    -> matchstr('^tags:\s*\[\zs.*\ze]')
    -> split('[ , ]\+')
enddef

# parse tags in lines that match "tags: keyword1, keyword2" in addition to the default parser:
g:wiki_tag_parsers = [
  {
    'match': (x) => x =~ '^tags: \?[',
    'parse': (x) => FrontmatterTagParser(x)
  }
]

def FormatJournalTitle(isodate: string, path: string): string
  const time = strptime("%Y-%m-%d", isodate)
  return strftime("%b %d", time) .. ": " .. wiki#toc#get_page_title(path)
enddef

def FormatJournalLink(path: string): string
  return wiki#paths#relative(wiki#get_root() .. path, expand('#:p:h'))
enddef

g:wiki_journal_index = {
  'link_text_parser': (_basename, date, path) => FormatJournalTitle(date, path),
  'link_url_parser': (_basename, _date, path) => FormatJournalLink(path)
}

nmap <silent> <leader>fwp :WikiFzfPages<CR>
nmap <silent> <leader>fwt :WikiFzfTags<CR>
# }}}

An (unfinished) attempt at a Lua translation

I ran my vim9script through T.J. Devries' vim9jit and found enough clues to put this together:

local g = vim.g

-- This plugin won't load properly without an init
local init_func = function()
  g.wiki_root = "/home/trev/Wiki/"
  g.wiki_filetypes = {"md"}
  g.wiki_link_extension = ".md"
  g.wiki_link_target_type = "md"
end

local function splitOnCommas(str)
  return vim.fn.split(str, '[ , ]\\+')
end

local function stripQuotes(str)
  return vim.fn.substitute(str, '"\\|\'', '', 'g')
end

local function extractTags(str)
  return vim.fn.matchstr(str, '^tags:\\s*\\[\\zs.*\\ze]')
end

local function frontMatterTagParser(str)
  return splitOnCommas(stripQuotes(extractTags(str)))
end

g.wiki_tag_parsers = {
  match = function(x) return not not vim.regex('^tags: \\+\\['):match_str(x) end,
  parse = frontMatterTagParser
}

vim.keymap.set("n", "<leader>fwp", ":WikiPages<CR>")
vim.keymap.set("n", "<leader>fwt", ":WikiTags<CR>")

return {
  init = init_func
}

With this everything works until I go :WikiTagReload. I get the following error:

Error detected while processing function wiki#tags#reload[1]..32[3]..33[16]..<lambda>306[1]..34:  
line   10:
E1098: String, List or Blob required

I guess my parse/match function is returning some garbage. What's up there?

I :echo g:wiki_tag_parsers and get {'parse': function('<lambda>1'), 'match': function('<lambda>2')}. That doesn't look bad.

So let's try calling these.

:echo call('<lambda>2', ['tags: [''cat'', ''hat'']']) outputs a boolean of v:true
:echo call('<lambda>1', ['tags: [''cat'', ''hat'']']) outputs a List of ['cat', 'hat']

Great, okay, these work...but what happens if I try to get the funcref by name? Both of these lambda functions fail in this manner: :echo function('<lambda>2') outputs:

E129: Function name required                                                                    
E475: Invalid argument: <lambda>2
0

This must be what is breaking my Lua config, right? I'm not sure how to Lua my way out of this one. Anyone have any ideas?

trev-dev commented 1 year ago

I have spent about as much time on this as I am willing to at this point. I think vimscript lambdas are still a bit of a puzzle. If anyone else ends up curious about it, this may still be around.

lervag commented 1 year ago

But NO. I have to figure out the maximalist Lua way of doing things because what's the point of a super fast Jit compiled language if you're not going to use it, right?

Heh, welcome to the club :)

Note that I choose to open an "issue" (discussion) here purely for context. I am also using lazy.nvim in Neovim for packages, and the built in package management for vim9.

If I understand correctly, the contents of the lua snippet is somehow used as input to lazy? wiki.vim requires some options defined before you load the plugin. To make easy, I therefore suggest you load all wiki.vim options during the lazy.nvim init block.

Here's another attempt at your lua config:

local g = vim.g

local function splitOnCommas(str)
  return vim.fn.split(str, '[ , ]\\+')
end

local function stripQuotes(str)
  return vim.fn.substitute(str, '"\\|\'', '', 'g')
end

local function extractTags(str)
  return vim.fn.matchstr(str, '^tags:\\s*\\[\\zs.*\\ze]')
end

local function frontMatterTagParser(str)
  return splitOnCommas(stripQuotes(extractTags(str)))
end

return {
  init = function()
    g.wiki_root = "/home/trev/Wiki/"
    g.wiki_filetypes = {"md"}
    g.wiki_link_extension = ".md"
    g.wiki_link_target_type = "md"

    g.wiki_tag_parsers = {
      {
        match = function(x)
          return not vim.regex('^tags: \\+\\['):match_str(x)
        end,
        parse = frontMatterTagParser
      },
    }

    vim.keymap.set("n", "<leader>fwp", ":WikiPages<CR>")
    vim.keymap.set("n", "<leader>fwt", ":WikiTags<CR>")
  end
}

A couple of things:

You had not not in your match function. Did you mean to use double negation here?
Also, wiki_tag_parsers is a list of parsers. You missed the outer brackets.
I moved more stuff into the init function. I think that should be better, as it is more aligned with lazy.nvim where the relevant init stuff goes into the init function. But I'm not quite sure how this is actually put together on your side, so I'm just guessing here.

With this everything works until I go :WikiTagReload. I get the following error:
Error detected while processing function wiki#tags#reload[1]..32[3]..33[16]..<lambda>306[1]..34:  
line   10:
E1098: String, List or Blob required
Great, okay, these work...but what happens if I try to get the funcref by name? …

This must be what is breaking my Lua config, right? I'm not sure how to Lua my way out of this one. Anyone have any ideas?

No, I don't think so. If it was, then that should be the error message you got, right?

lervag commented 1 year ago

The problem seems to be the missing outer brackets. The wiki_tag_parsers should be a list of parsers.

By the way, to properly implement a parser that has all features, you should also define the make function. See :help wiki_tag_parsers for more info.

trev-dev commented 1 year ago

Heh, welcome to the club :)

Yes hello, here is my "Incorrigible Tinkerer's Club" card. May I sample the lager?

To make easy, I therefore suggest you load all wiki.vim options during the lazy.nvim init block.

Everything seems to work OK with just the markdown options set prior to loading wiki for myself but I'll take your advice on this one regardless.

The problem seems to be the missing outer brackets. The wiki_tag_parsers should be a list of parsers.

Well frigg, that's a subtle but silly mistake. Nice catch! The thing works now, I'm glad I asked my question inside of this domain. It now works!

trev-dev commented 1 year ago

P.S What do you think of the vim9 config?

lervag commented 1 year ago

Heh, welcome to the club :)

Yes hello, here is my "Incorrigible Tinkerer's Club" card. May I sample the lager?

:cheers:

To make easy, I therefore suggest you load all wiki.vim options during the lazy.nvim init block.

Everything seems to work OK with just the markdown options set prior to loading wiki for myself but I'll take your advice on this one regardless.

I guess the main point here is that wiki.vim ensures default values for all options. This is done while loading the plugin initially. It is cheap - on my end it adds 2.6 ms to startuptime. I'm fine with that.

However, it is important to be aware of these things, because if you don't ensure your configuration is specified before defaults are set, you will miss the merging of dictionary options (i.e., if you specify one key in a dict option, wiki.vim will ensure defaults for the remaining keys). Also, global commands depend on the options, so if you were to specify your options (e.g. g:wiki_root) too late, then :WikiIndex would not work as expected.

So, it is easier to just ask everyone to ensure that all options are specified during the main init.lua load time.

The problem seems to be the missing outer brackets. The wiki_tag_parsers should be a list of parsers.

Well frigg, that's a subtle but silly mistake. Nice catch! The thing works now, I'm glad I asked my question inside of this domain. It now works!

Subtle, silly mistakes are the worst sort. It's usually easier to spot other peoples subtle mistakes than our own. :)

P.S What do you think of the vim9 config?

Well, it looks decent enough. But: (rant incoming)

To be honest, I have not spent any time on vim9. I decided quite early on to avoid it. I've already left Vim behind and I only use neovim these days. Of course, I have a minimal Vim configuration that I keep around, but it is plain old vimscript - it works for me.

I don't mind vimscript. Perhaps its like a Stockholm syndrome, but I find it has a lot of merit. I do mind that the new vimscript is not backwards compatible and that it is never going to work with neovim, though. IMHO, vim9 was a big mistake. As a plugin writer, I will never bother to learn it. In the future, I will probably write more Lua and less vimscript and I will probably stop supporting Vim. I think that this is sad, but I don't quite see how to avoid this.

trev-dev commented 1 year ago

As a plugin writer, I will never bother to learn it. In the future, I will probably write more Lua and less vimscript and I will probably stop supporting Vim. I think that this is sad, but I don't quite see how to avoid this.

Ironic that vim9script was designed for you: the plugin writer, don't you think?

I dislike Lua only slightly less than I dislike legacy vimscript. I like vim9script more than both. It's terse and gets right down to the editor API in a way more simple, easy to learn DSL should. I agree wholeheartedly about the lack of Neovim compatibility though.

Alas: I have finished my wiki.vim lua config and it it's snappy.

lervag commented 1 year ago

As a plugin writer, I will never bother to learn it. In the future, I will probably write more Lua and less vimscript and I will probably stop supporting Vim. I think that this is sad, but I don't quite see how to avoid this.

Ironic that vim9script was designed for you: the plugin writer, don't you think?

Yes, definitely. But my time is severely limited, and I won't have time to learn and use a language that does not really benefit me at all. If I don't use Vim, there is clearly little motivation to learn vim9script.

I dislike Lua only slightly less than I dislike legacy vimscript. I like vim9script more than both. It's terse and gets right down to the editor API in a way more simple, easy to learn DSL should. I agree wholeheartedly about the lack of Neovim compatibility though.

If neovim would also "agree" on vim9script and implement it as a substitute for vimscript, then I would have a much stronger reason to learn it and rewrite my plugins in vim9script instead of vimscript. But this is not going to happen, as far as I understand.

Alas: I have finished my wiki.vim lua config and it it's snappy.

Glad to hear it!

trev-dev commented 1 year ago

If neovim would also "agree" on vim9script and implement it as a substitute for vimscript, then I would have a much stronger reason to learn it and rewrite my plugins in vim9script instead of vimscript. But this is not going to happen, as far as I understand.

Yes this is also my understanding. It's more likely "anything important enough will just be re-written in Lua" will be the lasting sentiment.

lervag / wiki.vim

Lua configuration breaking due to weirdness #283

The vim9script way

An (unfinished) attempt at a Lua translation