Date math with template tokens

[Liquidmantis]

This is only a partially formed idea as I'm still mulling over the use cases, but being able to do simple day- and week-based math operations against the template tokens could be useful.

For example in a daily template maybe you a templated navigation bar:

---
title: {{title}}
---

{{date-1d}} | {{date}} | {{date+1d}} 

or even with helper tokens:

{{yesterday}} |  {{date}} | {{tomorrow}}

This next one might be a little trickier depending on when you generate your weekly, but something similar for weeklies that automatically links to the dailies for the days of that week would be awesome.

---
title: {{title}}
week: {{week}}
---

{{week-1w}} | {{week}} | {{week+1w}}

{{sunday}}
{{monday}}
{{tuesday}}
{{wednesday}}
{{thursday}}
{{friday}}
{{saturday}}

Maybe I'll take a look at the source code this weekend to see if I've got the chops to put together a PR.

[renerocksai]

I like the idea. That would be an improvement for my weekly template as well. Let's think about it. At the moment, I think addition and subtraction seem enough when applied to dates, days, weeks.

[Liquidmantis]

@renerocksai Okay, I couldn't leave this be and created PR #34. I simplified the original proposal as I realized any more complicated date calculations are out of scope for templates. That said, given a need it would be straightforward to build this out as a parameterized function if you want to build a robust templating scheme.

I mainly started the PR as a proposal for discussion. It's not merge-ready because it doesn't currently handle the edge cases of week rollovers, for example lastweek when current week is 01 or nextweek when current week is 52.

As a possible solution, I'd propose the breaking change of changing the string format for week to be in a namespaced format, rather than the unqualified week integer. For example, rather than 49, how about 2021.49 to make it unique? Then we can easily support the wrapping week offsets with the same method of string conversion of adjusted seconds from epoch.

[Liquidmantis]

Ha! We apparently keep opposite relative time schedules 😆

How is the current scheme handling name collisions after a year of weekly notes? 46.md could be this year, last year, or five years ago. I guess the expectation is for the user to qualify it through whatever scheme they desire? For example either naming the notes with a "yearspace" or creating yearly directories?

One solution for a non-breaking change would be setting years as a scope boundary (new year, new leaf!) and not wrapping on the edges. WK01 doesn't have a prior week, WK52 doesn't have a next week. What to return when evaluating those bounding limit cases though?

[renerocksai]

I wish! Currently, I have given up scheduling my time 😄 as there's no point when inspiration calls. 😄

See here:

Currently, the following things are hardcoded:

• the file naming format for daily note files: YYYY-MM-DD.ext (e.g. 2021-11-21.md)
• the file naming format for weekly note files: YYYY-Www.ext (e.g. 2021-W46.md)
• the file naming format for pasted images: pasted_img_YYYYMMDDhhmmss.png (e.g. pasted_img_20211126041108.png)

No collisions.

There is a difference between what we figure is the current date and what the calendar passes to us - versus the file naming convention.

Getting the week right should not be a problem, even with calculated dates: os.date("%V") does the magic. So without having thought about it in depth yet, I see no show stoppers for calculated dates and convenience placeholders like yesterday and next week.

We would need to come up with a syntax for that, probably a scoped one. Like {yesterday.day}, yesterday.week, yesterday.hdate, etc.

[Liquidmantis]

Ack! Sorry! I need to go read through the documentation and make sure I really grok it before making pointless comments. Again you're catching me out on getting caught up in the theoretical rather than the practical.

For now I'll hack on getting the relative days of the week for a given week (calculating the sun-sat for the current week, regardless of when evaluated.)

Maybe after my coffee kicks in I'll get a better handle on the week stuff.

[renerocksai]

I take it, the following might help.

Since you do:

os.date(week_format, os.time() + oneweek)

Getting the week for a calculated point in time could look like this:

os.date("%V", os.time() + oneweek)

And the relative day index is just a lookup from the string version (which os.date will return to you) to the numerical day index: string to int. Like the reverse of daymap[weekday]. After getting the int, apply the -1 and monday sunday swap based on the config option calendar_monday.

[Liquidmantis]

Getting the week for a calculated point in time could look like this:

os.date("%V", os.time() + oneweek)

Yeah, that's the starting point in my head, but that alone only returns a two-digit integer, it doesn't provide the context. So cases of 52 will just return 01, and vice-versa, unless the token resolves with an accompanying year representation to signify the week is from the prior or next year.

As another proposal, what about a non-breaking addition of a qualified token? I don't like this name very much, but maybe something like {{isoweek}} that resolves to the ISO format 2021-W49, then we have {{isolastweek}} and {{isonextweek}} week. In that case we could remove the {{lastweek}} and {{nextweek}}, or for flexibility leave them as is and let the user determine if they want to do anything for the bounding limit weeks.

[renerocksai]

print(os.date('%Y-%m-%V', os.time() + 3 * 7 * 24 * 60 * 60))
2022-01-52

print(os.date('%Y-%m-%V', os.time() + 3 * 7 * 24 * 60 * 60 - 24 * 60 * 60))
2021-12-52

Gives you everything you need to know: if it's week 52 but the month is 01, so it's up to you if you want to re-frame it as week 1 of 2022 - which would probably be incorrect (see calendar below). The signifier you're looking for is implicit: match month against week number and you'll see when they disagree like in the example above.

But I think os.date does the right thing:

So today in 3 weeks is in fact week 52 (of 2021) even though the date is Jan 1st, 2022. So in calendar week number theory, week 52 can span 2 years, apparently 😄

I don't see how renaming {{week}} to {{isoweek}} improves anything? If you look at the calendar above: week 52 applies to both 2021 and 2022. So the week part of {{isoweek}} is identical to {{week}}. So there is nothing gained in comparison to {{year}}-W{{week}}.

The week consists of 7 days and if you take the first day of the week as reference for {{week}}, you'll end up in 2021. If you take the last one, you'll end up in 2022. If you take 'today', it will depend - which might just be what you want. The week remains constant, it's only a question of the year. Currently, the plugin implicitly takes today's year and the week.

[Liquidmantis]

Oh, and sorry about the formatting. Looks like my stylua wiring didn't do what it's supposed to do.

[renerocksai]

You're welcome. You were just unstoppable. There wouldn't have been a point of me doing it 😄. And in a way, it was quite a cool experience. Trying to explain things is something valuable to all parties. Mr. Feynman would definitely agree! 😄

And don't worry about the styling. It's not like you put TABs all over the place 😁 . But if you are inclined, have a look. There are .luacheckrc and a .stylua.toml files in the root dir.

I have the following in my init.vim:

Plugin 'ckipp01/stylua-nvim'

" ...

" lua nvim coding
autocmd filetype lua setlocal makeprg=luacheck
autocmd filetype lua command! Check make --no-color .
autocmd filetype lua command! Format lua require("stylua-nvim").format_file()
autocmd filetype lua command! FormatLua lua require("stylua-nvim").format_file()

So when I want to check, I issue a :Check command. For styling, I do :Format. No fancy pantsy LSP integration needed
for that.

I am very new to lua and neovim hacking myself, just plunged in trying to write this plugin. So you'll find more proper
setups among the telescope authors.

[lambtho12]

A nice plugin to handle formatting (and many other things) automatically is null-ls. It automatically formats everything on save according to a style definition (.stylua) in the the root of the repo or a default one (it supports stylua and luacheck).

nls.setup({
  sources = {
    fmt.trim_whitespace.with({
      filetypes = { "text", "sh", "zsh", "yaml", "toml", "make", "conf" },
    }),
    fmt.black,
    fmt.stylua,
    fmt.markdownlint.with({
      filetypes = { "md", "markdown", "vimwiki", "telekasten" },
    }),
    fmt.bean_format.with({ args = { "-c 61" } }),
    dia.yamllint,
  },
  on_attach = function(client)
    if client.resolved_capabilities.document_formatting then
      vim.cmd("autocmd BufWritePre <buffer> lua vim.lsp.buf.formatting_sync()")
    end
  end,
})

I do not use luacheck personally, but I have the lsp setup with sumneko_lua server so it outputs diagnostics in real time.

[renerocksai]

Okay! I opened a new PR with the changes you proposed, using a feature branch. In my testing I encountered a corner case regarding partial weeks at year transitions. I tried to document it well, so let me know if you have any issues. In my testing this provides intuitive values for the first and last weeks. I checked other calendars, and consistently the week number is based on the partial week with the most days. My approach awards the days from the losing year to the weekly note of the winner.

Without this workaround, 2022-W52 would contain:

• 2022-01-01
• 2022-01-02
• 2022-12-27
• 2022-12-28
• 2022-12-29
• 2022-12-30
• 2022-12-31

I have to re-visit this 😊! I am currently doing a bit of refactoring to support a few more (requested) use-cases. I
am now at a point where I can determine if a link goes to a non-existing daily note. Parsing the date and handing it
over to calculate_dates() should do the trick to support template expansion with correct values for all the
{{isolastweek}} magic you added. Thanks again for this, at this point.

Now, here is where it gets tricky: What when we encounter a [[2021-W52]]link. I can parse the year and week number
out of it - butcalculate_dates() needs a concrete date to work (with os.time(date)). So I need a way to convert a
week into a date representing it. That got me thinking about the whole week 52 and at what week does a year start issue.
So I looked at howcalendar.nvim does it. And I found a very interesting comment there:

    if exists('g:calendar_weeknm')
      " if given g:calendar_weeknm, show week number(ref:ISO8601)

So I looked into ISO8601 - there actually is a standard for this and calendar.nvim seems to implement it correctly.
So the week number we get from it, I assume, is always correct. It also shows us how to convert a date into an ISO week.
It looks clumsy and complicated, but I guess this is more the fault of vimscript and the nature of the problem.

However, I am going to dig into the standard - there is a nice Wikipedia page regarding the week problem: here. Just for the sake of scientific rigor 😊, I am also going to check if your heuristic based on the partial week with the most days holds true according to the standard, which I think it does, because of Thursdays playing such an important role in the standard. And a week containing a Thursday is always longer than the remainder of the week in the next year.

So I want to put this all into some lua code that always calculates the correct date of a week and maybe vice versa
should the heuristic with the longer partial week not hold true for some edge case. I don't know if one ever wants to
create notes for historic weeks - but if they do, they should get the correct {{monday}}s 😂!

This is just to let you know that the date saga continues...

[renerocksai]

I eventually incorporated luadate (link in source) because the wikipedia (and referencing material) suggested isoweek -> date algo didn't cover all edge cases that I had tried. We can now auto-create dailies and weeklies by following links to them. This is very handy if you have {{monday}}s etc in a weekly template - and follow a link to a day in the future.

Will update readme with new config options new_note_location and template_handling soon.

[renerocksai]

Thanks for the info! I use coc so I never thought of using null-ls until I switch to the builtin LSP client. But this makes me reconsider.

[renerocksai]

Hmmm. I use / started using coc because it was available, seemed mature enough, had support for everything, was as feature-rich as the vscode stuff - and then: had to install node and keep it up-to-date, etc. I am seriously asking myself what it is about coc that I really need. It comes with so much stuff that I hardly use so I don't even remember the key mappings for them. So I don't actually use any of the fancy stuff because I forget how to do them - and if I look them up, they don't work in the specific language that I am dealing with. 😄 - so on the one hand a very smooth experience ":CocInstall coc-lua", on the other hand, probably too bloated for my needs.

I will probably give the builtin LSP a go pretty soon. Oh f*ck it, I'll try it now 😄

It will be your fault if my whole setup breaks because you two made me do it 😄

[renerocksai]

Wow! I got it to work: python, zig, lua, markdown (null-ls).

But it was a bit of work and it still doesn't continue completing paths. When I enter / it starts suggesting /home, for instance, and doesn't continue suggesting subdirectories after that - which is a bit of a disappointment.

I also need to find a good replacement for coc-explorer. But that should be easy. I hardly ever use it but sometimes it's nice. Nicer than netrw...

It really blew up my init.vim:

" lua and lsp stuff
Plugin 'neovim/nvim-lspconfig' " Collection of configurations for built-in LSP client
Plugin 'tjdevries/nlua.nvim'  " TJ's magic stuff

Plugin 'hrsh7th/cmp-buffer'
Plugin 'hrsh7th/cmp-path'
Plugin 'hrsh7th/cmp-cmdline'
Plugin 'hrsh7th/nvim-cmp' " Autocompletion plugin
Plugin 'hrsh7th/cmp-nvim-lsp' " LSP source for nvim-cmp
Plugin 'saadparwaiz1/cmp_luasnip' " Snippets source for nvim-cmp
Plugin 'L3MON4D3/LuaSnip' " Snippets plugin

Plugin 'jose-elias-alvarez/null-ls.nvim'

" ...

""" lsp stuffs
lua << EOF
local nvim_lsp = require('lspconfig')

-- Use an on_attach function to only map the following keys
-- after the language server attaches to the current buffer
local on_attach = function(client, bufnr)
  local function buf_set_keymap(...) vim.api.nvim_buf_set_keymap(bufnr, ...) end
  local function buf_set_option(...) vim.api.nvim_buf_set_option(bufnr, ...) end

  -- Enable completion triggered by <c-x><c-o>
  buf_set_option('omnifunc', 'v:lua.vim.lsp.omnifunc')

  -- Mappings.
  local opts = { noremap=true, silent=true }

  -- See `:help vim.lsp.*` for documentation on any of the below functions
  buf_set_keymap('n', 'gD', '<cmd>lua vim.lsp.buf.declaration()<CR>', opts)
  buf_set_keymap('n', 'gd', '<cmd>lua vim.lsp.buf.definition()<CR>', opts)
  buf_set_keymap('n', 'K', '<cmd>lua vim.lsp.buf.hover()<CR>', opts)
  buf_set_keymap('n', 'gi', '<cmd>lua vim.lsp.buf.implementation()<CR>', opts)
  buf_set_keymap('n', '<C-k>', '<cmd>lua vim.lsp.buf.signature_help()<CR>', opts)
  buf_set_keymap('n', '<space>wa', '<cmd>lua vim.lsp.buf.add_workspace_folder()<CR>', opts)
  buf_set_keymap('n', '<space>wr', '<cmd>lua vim.lsp.buf.remove_workspace_folder()<CR>', opts)
  buf_set_keymap('n', '<space>wl', '<cmd>lua print(vim.inspect(vim.lsp.buf.list_workspace_folders()))<CR>', opts)
  buf_set_keymap('n', '<space>D', '<cmd>lua vim.lsp.buf.type_definition()<CR>', opts)
  buf_set_keymap('n', '<space>rn', '<cmd>lua vim.lsp.buf.rename()<CR>', opts)
  buf_set_keymap('n', '<space>ca', '<cmd>lua vim.lsp.buf.code_action()<CR>', opts)
  buf_set_keymap('n', 'gr', '<cmd>lua vim.lsp.buf.references()<CR>', opts)
  buf_set_keymap('n', '<space>e', '<cmd>lua vim.diagnostic.open_float()<CR>', opts)
  buf_set_keymap('n', '[d', '<cmd>lua vim.diagnostic.goto_prev()<CR>', opts)
  buf_set_keymap('n', ']d', '<cmd>lua vim.diagnostic.goto_next()<CR>', opts)
  buf_set_keymap('n', '<space>q', '<cmd>lua vim.diagnostic.setloclist()<CR>', opts)
  buf_set_keymap('n', '<space>f', '<cmd>lua vim.lsp.buf.formatting()<CR>', opts)

end

local lspconfig = require('lspconfig')



-- Set completeopt to have a better completion experience
vim.o.completeopt = 'menuone,noselect'

local has_words_before = function()
  local line, col = unpack(vim.api.nvim_win_get_cursor(0))
  return col ~= 0 and vim.api.nvim_buf_get_lines(0, line - 1, line, true)[1]:sub(col, col):match("%s") == nil
end

-- luasnip setup
local luasnip = require 'luasnip'

-- nvim-cmp setup
local cmp = require 'cmp'
cmp.setup ({
  snippet = {
    expand = function(args)
      require('luasnip').lsp_expand(args.body)
    end,
  },
  mapping = {
    ['<C-p>'] = cmp.mapping.select_prev_item(),
    ['<C-n>'] = cmp.mapping.select_next_item(),
    ['<C-d>'] = cmp.mapping.scroll_docs(-4),
    ['<C-f>'] = cmp.mapping.scroll_docs(4),
    ['<C-Space>'] = cmp.mapping(cmp.mapping.complete(), {'i', 'c'}),
    ['<C-e>'] = cmp.mapping({
        i = cmp.mapping.abort(),
        c = cmp.mapping.close(),
        }),
    ['<CR>'] = cmp.mapping.confirm {
      behavior = cmp.ConfirmBehavior.Replace,
      select = true,
    },
    ["<Tab>"] = cmp.mapping(function(fallback)
      if cmp.visible() then
        cmp.select_next_item()
      elseif luasnip.expand_or_jumpable() then
        luasnip.expand_or_jump()
      elseif has_words_before() then
        cmp.complete()
      else
        fallback()
      end
    end, { "i", "s" }),

    ["<S-Tab>"] = cmp.mapping(function(fallback)
      if cmp.visible() then
        cmp.select_prev_item()
      elseif luasnip.jumpable(-1) then
        luasnip.jump(-1)
      else
        fallback()
      end
    end, { "i", "s" }),
  },
  sources = cmp.config.sources({
    { name = 'nvim_lsp' },
    { name = 'luasnip' },
      { name = 'path' },
  }, {
  { name = 'buffer' },
  })
})

-- Use buffer source for `/` (if you enabled `native_menu`, this won't work anymore).
cmp.setup.cmdline('/', {
    sources = {
        { name = buffer }
    }
})
 -- Use cmdline & path source for ':' (if you enabled `native_menu`, this won't work anymore).
  cmp.setup.cmdline(':', {
    sources = cmp.config.sources({
      { name = 'path' }
    }, {
      { name = 'cmdline' }
    })
  })

-- Add additional capabilities supported by nvim-cmp
local capabilities = vim.lsp.protocol.make_client_capabilities()
capabilities = require('cmp_nvim_lsp').update_capabilities(capabilities)

-- Use a loop to conveniently call 'setup' on multiple servers and
-- map buffer local keybindings when the language server attaches
local servers = { 'pylsp' }

-- Enable some language servers with the additional completion capabilities offered by nvim-cmp
for _, lsp in ipairs(servers) do
  lspconfig[lsp].setup {
    on_attach = on_attach,
    capabilities = capabilities,
    flags = {
      debounce_text_changes = 150,
    }
  }
end

-- now do the same with nlua
require('nlua.lsp.nvim').setup(lspconfig, {
    on_attach = on_attach,

    globals = {
        -- extra globals would go here
    }
})

-- now comes zls
nvim_lsp.zls.setup({
    default_config = {
        cmd = {"/home/rs/bin/zls"},
        filetypes = {"zig"},
        root_dir = lspconfig.util.root_pattern("build.zig", ".git"),
        },
    docs = {
        description = [[ ]];
        default_config = {
             root_dir = [[root_pattern("build.zig", ".git")]];
        }
    },
    on_attach = on_attach,
})

-- null-ls
local null_ls = require('null-ls')
local fmt = null_ls.builtins.formatting

null_ls.setup({
  sources = {
    fmt.trim_whitespace.with({
      filetypes = { "text", "sh", "zsh", "yaml", "toml", "make", "conf", "lua" },
    }),
    fmt.black,
    fmt.stylua,
    fmt.markdownlint.with({
      filetypes = { "md", "markdown", "vimwiki", "telekasten" },
    }),
  },
  on_attach = function(client)
    if client.resolved_capabilities.document_formatting then
      vim.cmd("autocmd BufWritePre <buffer> lua vim.lsp.buf.formatting_sync()")
    end
  end,
})

EOF

[Liquidmantis]

Coc-Explorer is hard to replace, but I couldn't justify CoC just for it. For people that are going down the lua rabbit hole, nvim-tree seems to be the most popular choice. I haven't evaluated ChadTree, though. And right now I'm working on integrating Ranger through rnvimr to see how that feels.

[renerocksai]

I just switched for similar reasons. And the setup bloat doesn't bother me, it is readable. And: now I'm part of the in-crowd 😆

Wow! both nvim-tree and Chadtree look really good!

[renerocksai]

luatree it is 😄