developer.xml

developer-informationdeveloper
Developer information

Contents

  1. Writing documentation
    1. Help tags
  2. Generating documentation
  3. Writing plugins
    1. Plugin documentation

writing-docsdocumentation
Writing documentation

In order for any user-visible change to be accepted into the mainline, it must be accompanied by accurate documentation. The docs are written in an XML dialect similar to XHTML, with a few tags specific to our documentation. For example:

<item> <tags>&lt;F1> :help :h help</tags> <spec>:h<oa>elp</oa> <oa>subject</oa></spec> <spec>&lt;F1></spec> <description> <p> Open the help page. The default page, as specified by <o>helpfile</o> is shown unless <oa>subject</oa> is specified. If you need help for a specific topic, try <ex>:help overview</ex>. </p> </description> </item>

creates a new help section for the command :help and for the related key binding, <F1>. It also creates help tags for the command, its shortcuts, the key binding, and the general topic, ‘help’. These tags enable linking to this section from other mentions of the topic and from the :help command.

help-tagshelp-xml
Help tags

The following is a list of the more common XML tags used in help pages, along with their highlight groups.

Layout
p
A paragraph (HelpParagraph)
h1
A first-level heading (HelpHead1)
h2
A second-level heading (HelpHead2)
h3
A third-level heading (HelpHead3)
h4
A fourth-level heading (HelpHead4)
code
A pre-formatted code block. (HelpCode)
note

Note: A note paragraph. (HelpNote)

strut
A horizontal strut which prevents any previous floating elements from appearing below it.
warning

Warning: A warning paragraph. (HelpWarning)

Generic
link
A generic link. (HelpLink)
   @topic
The topic of the link. Either a help topic or a fully-qualified URI.
em
Emphasized text. (HelpEm)
str
A string, with its contents wrapped in quotes. (HelpString)
logo
Pentadactyl's logo. (Logo)
Items
item
A help entry (HelpItem)
   tags
See the 'Tagging' section (HelpTags)
   spec
The specification for this item, such as an example command line. (HelpSpec)
   strut
A horizontal formatting strut which ensures that all previous <tags> and <spec> elements appear above the ones that follow.
   type
For options, the type of the option. number, boolean, string, stringlist, or charlist. (HelpType)
   default
For options, the default value. (HelpDefault)
   description
The description of this help item. (HelpDescription)
      @short
Indicates that this is a short description which should appear between the specs and tags.
a
Required {argument}. (HelpArg)
oa
Optional [argument]. (HelpOptionalArg)
Tagging
tags
Space-separated list of strings to tag. Displayed right-aligned, and used for cross-linking. (HelpTags)
@tag
The tag attribute. Applied to any element, generates a <tags> element for the given tags. (HelpTag)
Linking
o
Link to an option. (HelpOpt)
ex
Link to an Ex command. (HelpEx)
k
Link to a key. (HelpKey)
   @name
The name attribute to <k>. When provided, <{value}> is prepended to the element's contents, i.e., <k name="Tab"/> becomes <Tab>.
   @mode
The mode attribute to <k>. Some keys have different functions in different modes. You can use this attribute to specify which of the modes (other than Normal) a key pertains to. The <{value}> is prepended to the element's contents, i.e., <k name="C-i" mode="I"/> becomes I_<C-i>, and <k mode="t">i</k> becomes t_i.
t
Links to an arbitrary help topic. (HelpTopic)
Plugins
@lang
When applied to any element under <plugin>, that element is only visible for a specific locale.
plugin
The container tag used for describing a plugin.
   @name
The name of the plugin. Used as the plugin's help tag.
   @version
The plugin's version number.
   @href
The plugin's home page.
   @summary
A short description of the plugin, shown in its section head.
info
An element with the same attributes as plugin, which may override the latter for specific locales
project
The project for which this plugin was intended.
   @name
The name of the project (i.e., Pentadactyl)
   @min-version
The minimum version of the project for which this plugin is intended to work.
   @max-version
The maximum version of the project for which this plugin is intended to work.
author
The plugin's author. May appear more than once.
   @href
The author's home page.
   @email
The author's email address.
license
The plugin's license. May appear more than once.
   @href
The URI of a page which shows or explains the license.

generating-docs
Generating documentation

You can also autogenerate most of the XML help after you have written a new command, mapping or option.

:echo dactyl.generateHelp(commands.get(addons), <p>Extra text</p>)

writing-plugins
Writing plugins

Writing Pentadactyl plugins is incredibly simple. Plugins are simply JavaScript files which run with full chrome privileges and have full access to the Pentadactyl and Firefox APIs. Each plugin has its own global object, which means that the variables and functions that you create won't pollute the global window or private dactyl namespaces. This means that there's no need to wrap your plugin in a closure, as is often the practice in JavaScript development. Furthermore, any plugin which is installed in your 'runtimepath'/plugins directory will find its context stored in plugins.<pluginName>, which is often invaluable during development and testing.

Plugins are always initialized after the main window is loaded, so there is no need to write load event handlers. Beyond that, what you may do with your plugins is practically limitless. Plugins have full access to all of the chrome resources that ordinary Firefox does, along with the entire power of the Pentadactyl API. If you need a starting point, have a look at some existing plugins or extensions, especially the Pentadactyl source.

plugin-documentation
Plugin documentation

Plugins should provide inline documentation, which will appear on the :help plugins page. The markup for help entries is the same as the above, along with a few extra plugin-specific entries. Here is an example from the popular flashblock extension:

use strict; XML.ignoreWhitespace = false; XML.prettyPrinting = false; var INFO = <plugin nameflashblock version1.0 hrefhttp://dactyl.sf.net/pentadactyl/plugins#flashblock-plugin summaryFlash Blocker xmlns{NS}> <author emailmaglione.k@gmail.com>Kris Maglione</author> <license hrefhttp://opensource.org/licenses/mit-license.php>MIT</license> <project namePentadactyl min-version1.0/> <p> This plugin provides the same features as the ever popular FlashBlock Firefox addon. Flash animations are substituted with place holders which play the original animation when clicked. Additionally, this plugin provides options to control which sites can play animations without restrictions, and triggers to toggle the playing of animation on the current page. </p> <item> <tags>'fb' 'flashblock'</tags> <spec>'flashblock' 'fb'</spec> <type>boolean</type> <default>true</default> <description> <p> Controls the blocking of flash animations. When true, place holders are substituted for flash animations on untrusted sites. </p> </description> </item> [...] </plugin>;

The inline XML is made possible by E4X. It is important that the documentation be assigned to the INFO variable, or Pentadactyl will not be able to find it. The XML property changes are not compulsory, but they do prevent certain formatting problems that may occur otherwise. Beginning your file with use strict, while not required, helps to prevent a lot of common errors.

The documentation that you provide behaves exactly as other Pentadactyl documentation, which means that the tags you provide are available via :help with full tag completion and cross-referencing support. Although documentation is not required, we strongly recommend that all plugin authors provide at least basic documentation of the functionality of their plugins and of each of the options, commands, and especially mappings that they provide.