When calling VimwikiMakeYesterdayDiary (or Tomorrow) the wiki_nr is
looked up by vimwiki#diary#diary_date_link without access to the passed
count, which would result in the creation of the file in the correct
place, but with the diary_frequency of another wiki. Modify
vimwiki#diary#diary_date_link to take a possible third argument as the
wiki_nr+1 and modify the commands to pass <count> as the third argument.
Fixes: #1365
Previously vimwiki#tbl#get_cells() would act on `line` as a normal
string (i.e. using `[idx]` and strpart()). This breaks when the column
separator (s:s_rep() or rxTableSep) is a multibyte character like the
vertical box drawing character │. In that case the separator is never
found and only one empty cell is returned. This also affects
vimwiki#tbl#format() which in turn clears the whole table each time the
insert mode is left.
Fix this issue by initially splitting the line into a list of the
characters. Getting the elements with `[idx]` now returns each character
instead of a byte. In addition len() is used in place of strlen() as
well as slicing together with join() instead of strpart().
Fixes: #1297 ("Table formatting breaks on multibyte separator")
If a user is happy with the default vimwiki location, they may not set
the g:vimwiki_list global variable. In this case, the
len(g:vimwiki_list) vimwiki#diary#calendar_sign function throws an
error every time it is called. This function is called for every day
displayed in the calendar which is very noisy. Checking if the variable
exists before doing the length check prevents the error and the rest of
the function works fine if the variable is not set.
Intended to address #1267 - "get_diary_files() takes very long to
execute on Windows - this leads to very slow link-creation using the
Enter key".
In theory, this should be a performance improvement for link creation on
systems with very slow filesystem access (this came up under Windows, but
ought to be a general optimization). It does nothing for generating the
entire list of diary files, which by nature has to get the whole list
anyway.
- Uses a filereadable() call against a path instead of checking the
results of get_diary_files() for most calls.
- Introduces is_among_diary_files() for the case where you want to
check against a get_diary_files() list.
- is_diary_file() will pass through to is_among_diary_files() if it gets
invoked with a second parameter, to retain backwards compatibility on
the off chance anyone has scripted against this behavior. I'm not sure
this is necessary, but trying to be cautious with the implicit API
here.
- Includes a test/api_base_is_diary_file.vader
My original version of this change assumed that input would be in the
form of "2023-01-01", instead of a fully-qualifed filename. As it is,
it expects a full path to the file, in keeping with the list returned by
vimwiki#diary#get_diary_files().
Bug: #1267
Problem:
The loading of a .md file was slow due to multiple nested lookback.
It is advised in vim help to prefer \zs, see :h /\@<
Anyway, it is useless to nest them.
089.080 000.085 000.085: sourcing /home/mtourneb/.vim/after/syntax/vimwiki.vim
089.264 005.184: opening buffers
089.322 000.058: BufEnter autocommands
089.323 000.001: editing files in windows
089.414 000.091: VimEnter autocommands
089.415 000.001: before starting main loop
303.698 214.283: first screen update
303.700 000.002: --- VIM STARTED ---
Solution:
Remove the function s:expand_delimiter in vars.vim.
It was doing a duplicate job with vimwiki#u#hi_expand_regex
And ... well avoid lookback as much as possible
091.784 000.087 000.087: sourcing /home/mtourneb/.vim/after/syntax/vimwiki.vim
091.991 006.034: opening buffers
092.050 000.059: BufEnter autocommands
092.052 000.002: editing files in windows
092.172 000.120: VimEnter autocommands
092.173 000.001: before starting main loop
112.574 020.401: first screen update
112.578 000.004: --- VIM STARTED ---
Brennen Bearnes
Charles Schimmelpfennig
Tinmarino
Bence Ferdinandy
Justin McIntyre
Aarón Fas
Jiaming Chen
Julian Prein
Alex Claman
nolleh7707
Joe Planisky
Luke Atkinson
R. David Dunphy