populate_extra_markdown_vars() contained uses of the file-extension via vimwiki#vars#get_wikilocal. Since the first is syntax-wide and the second is wikilocal and no wiki is specified or open at the moment of the call, the file extension of the first markdown wiki will be used for all markdown wikis. Further problems will occur when adding new wikilocal options, that depend on the syntax.
This commit is working towards separating wiki and syntax, which is needed for several feature requests.
The following commands have been renamed to better describe their
function and avoid confusion.
:VimwikiDeleteLink → :VimwikiDeletePage
:VimwikiRenameLink → :VimwikiRenamePage
:VimwikiGenerateTags → :VimwikiGenerateTagLinks (was already renamed in 3b5537f)
Calling the old commands still works but displays a warning message.
This change reverts the original regex and simply adds a second regex
which is called on the result. '/\./' is one literal forward slash, one
literal fullstop (escaped with a leading backslash), and one literal
forward slash. In plain text, `/./` will be replaced with `/`.
When generating links, we first check that the file is not a diary file
as we don't want to include those in the list. That work is delegated to
the `is_diary_file` function. Prior to this change, the function always
returned true if the file was in the diary directory.
This approach gives false positives for a wiki which has a flat structure
and the wiki files and diary files share a directory. eg:
let wiki.diary_rel_path = './'
This change reuses existing diary functions from the diary.vim module to
get an exact list of diary files to check against.
Fixes#90
__Problem__: VimwikiRenameLink does not rename dir1/toto url in dir2/tata
because the dirs (dir2 and .) were well crossed but badly inspected.
__Solution__: `blob(.ext*)` -> `glob(**/*.ext)` + find the relative URL
* Fasten: VimwikiRenameLink goes faster with cache
More: To compute old_url regex, use a cache dict because it is the same
for files in the same directories
* Util DeleteHiddenBuffer -> do not delete Vader buffer
* Test: Prettify: Util: teardown delete defined function
* Remove unnecessary trailing spaces
Note: list_VimwikiReturn.vader has some necessary trailing spaces
Two non-stylistic errors were also fixed:
1. Removed duplicate function with invalid argument usage
2. Added missing quotes to a function call argument
Problem: Could not complete when the user argument was not the begining
of the filepath
Solution: use custom smartcase filter and customlist instead of custom
Closes#769.
Also fixes an error when adding missing '.' to mapped extensions. The
previous behavior tried to access a value after it was removed from the
dictionary.
Prior to this fix a file with tags present before any header would
result in vim errors. Now a single Vimwiki message is printed to alert
the user of the issue.
PR #634, PR #635, and PR #636 introduced new features that broke
compatibility with older version of Vim. This modifies those changes to
ensure compatibility. Closes#781.
Removes usage of funcref(), closure. Fixes filter() call.
Made globpath calls not use the list argument.
Unlet a variable that is reused (sticky type checking)
v7.4.1989 modified filter() to accept a Funcref
v7.4.2120 Added function "closure" argument
v7.4.2137 add funcref()
Previously if a code block was part of a list and o or O was used a new
list marker would be inserted. Also moved the is_codeblock check
function to utils file for use elsewhere.
- Create function wrapper around lvimgrep for input checking, pattern
quoting, and error handling.
- Add Vader tests for VimwikiSearch.
- Change syntax loading from try/catch to explicit file check (to
prevent Vader test bug).
- Update doc/vimwiki.txt for changes.
- Change test script to run Vader tests separately
Previously a new list marker would get added when working within a code
block that was part of a list. This change excludes code blocks from
list marker creation.
