From d2fbde0e814d873017ccc7d71eb585b9391dff9a Mon Sep 17 00:00:00 2001 From: Javier Rojas Date: Sun, 12 Sep 2010 19:25:38 -0500 Subject: new version of the ikiwiki vim plugin. docs upgraded. new forum post --- doc/forum/ikiwiki_vim_integration.mdwn | 17 +++++++++++++++++ doc/forum/link_autocompletion_in_vim.mdwn | 7 ++++++- doc/plugins/contrib/headinganchors.mdwn | 1 + doc/tips/vim_and_ikiwiki.mdwn | 28 ++++++++++++++++++++++++++++ doc/tips/vim_syntax_highlighting.mdwn | 5 +++++ 5 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 doc/forum/ikiwiki_vim_integration.mdwn create mode 100644 doc/tips/vim_and_ikiwiki.mdwn diff --git a/doc/forum/ikiwiki_vim_integration.mdwn b/doc/forum/ikiwiki_vim_integration.mdwn new file mode 100644 index 000000000..4724807e8 --- /dev/null +++ b/doc/forum/ikiwiki_vim_integration.mdwn @@ -0,0 +1,17 @@ +Hi all. I upgraded the [ikiwiki-nav plugin](http://www.vim.org/scripts/script.php?script_id=2968) +so that now it supports: + + * Jumping to the file corresponding to the wikilink under the cursor. + * Creating the file corresponding to the wikilink under the cursor (including + directories if necessary.) + * Jumping to the previous/next wikilink in the current file. + * Autocomplete link names. + +Download it from [here](http://www.vim.org/scripts/script.php?script_id=2968) + +I've also created a new page unifying all the hints available here to use vim +with ikiwiki files, in [[tips/vim_and_ikiwiki]] + + +--[[jerojasro]] + diff --git a/doc/forum/link_autocompletion_in_vim.mdwn b/doc/forum/link_autocompletion_in_vim.mdwn index 7d3ed8b02..a46c7e4c1 100644 --- a/doc/forum/link_autocompletion_in_vim.mdwn +++ b/doc/forum/link_autocompletion_in_vim.mdwn @@ -1,5 +1,10 @@ +This page is deprecated. See [[tips/vim_and_ikiwiki]] for the most up to date +content. + +------ + I extended the functionality of the [ikiwiki-nav plugin](http://www.vim.org/scripts/script.php?script_id=2968) -(see [[here|tips/follow_wikilinks_from_inside_vim]]) to allow completion of +(see [[here|tips/vim_ikiwiki_ftplugin]]) to allow completion of wikilinks from inside vim, through the omnicompletion mechanism. It still has some bugs, but is usable, and will not destroy your data. It can diff --git a/doc/plugins/contrib/headinganchors.mdwn b/doc/plugins/contrib/headinganchors.mdwn index becbf89a5..5ef054bce 100644 --- a/doc/plugins/contrib/headinganchors.mdwn +++ b/doc/plugins/contrib/headinganchors.mdwn @@ -1,4 +1,5 @@ [[!template id=plugin name=headinganchors author="[[PaulWise]]"]] +[[ikiwiki/directive/cosa]] This is a simple plugin to add ids (which will serve as [[anchor]]s) to all headings, based on their text. It works as a postprocessing filter, allowing it to work on mdwn, wiki, html, diff --git a/doc/tips/vim_and_ikiwiki.mdwn b/doc/tips/vim_and_ikiwiki.mdwn new file mode 100644 index 000000000..eb22e353a --- /dev/null +++ b/doc/tips/vim_and_ikiwiki.mdwn @@ -0,0 +1,28 @@ +# Vim and ikiwiki + +## Syntax highlighting + +[ikiwiki-syntax](http://www.vim.org/scripts/script.php?script_id=3156) is a vim +syntax highlighting file for ikiwiki [[ikiwiki/markdown]] files. It highlights +directives and wikilinks. It only supports prefixed directives, i.e., +\[[!directive foo=bar baz]], not the old format with spaces. + +------ + +The previous syntax definition for ikiwiki links is at [[ikiwiki.vim]]; however, +it seems to not be [[maintained +anymore|forum/navigation_of_wiki_pages_on_local_filesystem_with_vim#syn-maintenance]], +and it has some [[issues|forum/ikiwiki_vim_syntaxfile]]. + +## Page creation and navigation + +The [ikiwiki-nav](http://www.vim.org/scripts/script.php?script_id=2968) package +is a vim plugin that enables you to do the following from inside vim: + + * Jumping to the file corresponding to the wikilink under the cursor. + * Creating the file corresponding to the wikilink under the cursor (including + directories if necessary.) + * Jumping to the previous/next wikilink in the current file. + * Autocomplete link names. + +Download it from [here](http://www.vim.org/scripts/script.php?script_id=2968) diff --git a/doc/tips/vim_syntax_highlighting.mdwn b/doc/tips/vim_syntax_highlighting.mdwn index bf7104aec..8f2fdc1f0 100644 --- a/doc/tips/vim_syntax_highlighting.mdwn +++ b/doc/tips/vim_syntax_highlighting.mdwn @@ -1,3 +1,8 @@ +This page is deprecated. See [[tips/vim_and_ikiwiki]] for the most up to date +content + +-------- + [ikiwiki-syntax](http://www.vim.org/scripts/script.php?script_id=3156) is a vim syntax highlighting file for ikiwiki [[ikiwiki/markdown]] files. It highlights directives and wikilinks. It only supports prefixed directives, i.e., -- cgit v1.2.3 From 4c74a6c0925f16de1583e28fe11833ee0a93fdc9 Mon Sep 17 00:00:00 2001 From: Javier Rojas Date: Sun, 12 Sep 2010 19:27:44 -0500 Subject: reverted typo --- doc/plugins/contrib/headinganchors.mdwn | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/plugins/contrib/headinganchors.mdwn b/doc/plugins/contrib/headinganchors.mdwn index 5ef054bce..becbf89a5 100644 --- a/doc/plugins/contrib/headinganchors.mdwn +++ b/doc/plugins/contrib/headinganchors.mdwn @@ -1,5 +1,4 @@ [[!template id=plugin name=headinganchors author="[[PaulWise]]"]] -[[ikiwiki/directive/cosa]] This is a simple plugin to add ids (which will serve as [[anchor]]s) to all headings, based on their text. It works as a postprocessing filter, allowing it to work on mdwn, wiki, html, -- cgit v1.2.3 From bed67815fb34ed8210e8cf9c53017f902e7439c5 Mon Sep 17 00:00:00 2001 From: blipvert Date: Mon, 13 Sep 2010 01:44:37 +0000 Subject: --- doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn index bf68350e3..5b7be1187 100644 --- a/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn +++ b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn @@ -7,3 +7,5 @@ Pruning remote branches can be done automatically with the --prune option to "gi > I'll need more information than that before I add extra processing > work to the current git commands it uses. I don't see any errors here > from obsolete remote branches. --[[Joey]] + +Suppose a remote repository contains a branch named "foo", and you fetch from it. Then, someone renames that branch to "foo/bar". The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches). Pruning gets around the problem. It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resource (any commits they point to cannot be garbage collected). -- cgit v1.2.3 From c647e12c92fe635e07734946e815db41ec44ddfd Mon Sep 17 00:00:00 2001 From: blipvert Date: Mon, 13 Sep 2010 01:45:13 +0000 Subject: --- doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn index 5b7be1187..4c1e461e3 100644 --- a/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn +++ b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn @@ -8,4 +8,4 @@ Pruning remote branches can be done automatically with the --prune option to "gi > work to the current git commands it uses. I don't see any errors here > from obsolete remote branches. --[[Joey]] -Suppose a remote repository contains a branch named "foo", and you fetch from it. Then, someone renames that branch to "foo/bar". The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches). Pruning gets around the problem. It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resource (any commits they point to cannot be garbage collected). +Suppose a remote repository contains a branch named "foo", and you fetch from it. Then, someone renames that branch to "foo/bar". The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches). Pruning gets around the problem. It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resource (any commits they point to cannot be garbage collected). --[[blipvert]] -- cgit v1.2.3 From 0586d52f1f8978e53e90df32a21ebd346eabaa1b Mon Sep 17 00:00:00 2001 From: blipvert Date: Mon, 13 Sep 2010 01:46:22 +0000 Subject: fix typo --- doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn index 4c1e461e3..01f3d1a28 100644 --- a/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn +++ b/doc/bugs/git.pm_should_prune_remote_branches_when_fetching.mdwn @@ -8,4 +8,4 @@ Pruning remote branches can be done automatically with the --prune option to "gi > work to the current git commands it uses. I don't see any errors here > from obsolete remote branches. --[[Joey]] -Suppose a remote repository contains a branch named "foo", and you fetch from it. Then, someone renames that branch to "foo/bar". The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches). Pruning gets around the problem. It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resource (any commits they point to cannot be garbage collected). --[[blipvert]] +Suppose a remote repository contains a branch named "foo", and you fetch from it. Then, someone renames that branch to "foo/bar". The next time you fetch from that repository, you will get an error because the obsolete branch "foo" is blocking the branch "foo/bar" from being created (due to the way git stores refs for branches). Pruning gets around the problem. It doesn't really add much overhead to the fetch, and in fact it can *save* overhead since obsolete branches do consume resources (any commits they point to cannot be garbage collected). --[[blipvert]] -- cgit v1.2.3