<<snip>> . . >> To get Vim help file syntax highlighting in your notes files, you would >> need simply to set ft=help. You could do this either in a modeline, or >> using autocommands based upon the file extension. If you want additional >> highlighting capabilities, beyond those provided by Vim's help syntax, >> you can set 'filetype' to a dot-separated list of filetypes. For >> example... >> ft=help.txtfmt >> ...would allow you to create rich text style highlighting regions to >> complement the fixed-format Vim help markup regions. >> >> http://www.vim.org/scripts/script.php?script_id=2208 >> >> Another point to note is that your notes files can be located anywhere >> (recursively) within a directory structure, which may contain other >> types of files (e.g,. source files), which will also be processed by >> ctags according to their own language definitions. So, for example, you >> could keep notes files documenting a large C/C++ project within the >> subdirectories containing the source files they document. >> >> Finally, note that you don't give up any search capabilities, as Vim >> provides many useful mappings and commands for working with tags: e.g., >> CTRL-], CTRL-T, :ta, :ts, etc... Tag completion (e.g.,<Tab>,<CTRL-D>, >> etc...) and the ability to specify tags as regexes ensure that you don't >> have to know the full name of the tag you're trying to find. Of course, >> Vim's builtin :help command provides this as well, but as you pointed >> out, your tags are added to the global Vim help "namespace", so you may >> find yourself adding unnecessary prefixes to your tags names, not to >> mention searching a much larger namespace than necessary. Of course, the >> performance penalty is generally very small, and probably not even >> noticed, so this may be more of an aesthetic than a practical issue. >> >> Brett Stahlman > > IIUC, what adds the tags to the Vim help space is not the fact of > running :helptags (which you could do in any directory) but of having > the *.txt and tags files in a /doc/ subdirectory of some directory named > in 'runtimepath' (or, if different, in the same directory as the file > named by the 'helpfile' option). IMO, adding custom files to the Vim > help (e.g. in ~/.vim/doc on Unix, ~/vimfiles/doc on Windows) could be an > advantage if they aren't too many or too heavy and you want them to > appear as possible completions of the ":help" command, and to be opened > in the help window. OTOH, IIUC you could still use *.txt, ft=help (or > variations such as ft=help.foo.bar.baz) and :helptags, but _outside_ of > the 'runtimepath' trees, to use them with "tag" commands, including > Ctrl-] and Ctrl-T, but not ":help {subject}", so that you won't need > anymore to avoid name clashes with existing help tags. But in this case, > invoking the tags won't put the file containing them in a help window > but in the current window, which means that if the tag is not in the > current file and the latter is 'modified', the tag command will fail > unless you have either 'autowrite' (or 'autowriteall') set, or use a > bang! in the :tag command to force |abandon|ing the changes to the > current file (see ":help tag-!"). > > Best regards, > Tony.
Good point. You can use :helptags (instead of the custom ctags invocation in the previous post) to generate tags files you have no intention of using with the :help command. That is probably the simplest and best approach when you don't need to extend the tag syntax beyond what is supported by :helptags. Brett Stahlman --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
