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 ---
According to `:h hasmapto()` if we don't pass the mode as an argument
then only normal, visual and operator-pending modes are checked.
Lets pass the mode explicitly to allow overwriting insert mode mappings.
Refaction:
- Add g:vimwiki_syntax_list to set syntaxlocal variables
- Delete: syntax/vimwiki_markdown.vim and friends
- Change: vimwiki_syntax_variables -> vimwiki_syntaxlocal_vars for consistency
- Include: some doc in design notes
See: https://github.github.com/gfm/#emphasis-and-strong-emphasis
`A single * character can open emphasis iff (if and only if) it is part of a left-flanking delimiter run.`
Tim Pope default is too permissive (leads to too much emphasis openener): `\S\@<=_\|_\S\@=` -> `_\S\@=`
Add normalize anchor and unnormalize to get markdown anchor github
compliant. For respectively follow_link and VimwikiTOC
TODO: Treat the potential -12 suffix in anchor-links: ex:
[got to second link](same-link-2)
- Less code, Easyer to maintain, to add a markup language
- Faster to load, and to highlight
- Support multiline tags: #847
- Support nested tags
- Support intraword tags: this<b>bold</b>type #640
Basically unixify all before workingm then transofom in function os os
Util: Add function sort_len that a list of string according to the lenght of its content
Fix: VimwikiRenameLink doesn't update links in diary #90
Test: VimwikiRenameLink with nested directories
Prettify comments in autoload/path + remove antipattern
Define osxify function helper to solve windows Vs Unix : see #478
Path: remove useless temporary fix convertion before calling relpath (redundant) : see #478
Test: Fix typo
Path corrected (Thanks to test)
Two non-stylistic errors were also fixed:
1. Removed duplicate function with invalid argument usage
2. Added missing quotes to a function call argument
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.
The changes made with #686 did not ensure the ftplugin mappings were
specific to the buffer containing a Vimwiki file. This resulted in
undesired keymappings with no defined behavior since the <Plug>
definition was buffer specific.
All key mappings have the option of being disabled but the <Plug>
definitions are still available for user customization. Key sequences
are no longer overwritten if a mapping already exists. Fixes#671,
fixes#425.
This options allow third party plugins to register and enable additonal
functionality by setting the filetype to vimwiki.other_ft.other_ft2 etc.
This option should be used with care since vimwiki functionality can be
overwritten by other plugins. See Issue #461 for an example use case.