Plugin Howto

This is a guide that shall help you to develop pida plugins.

Types of Plugins

There are two different types of plugins. More or less. They are actually the same, but we distinguish LanguagePlugins? from normal Plugins because they target a different purpose. Both have the same power, but LanguagePlugins? are designed for a more sepecific purpose — provide support for languages (means programming language, but not only). As plugins are quite cheap, in fact, most of pida are just plugins that always run, known as services. If you have two different things you want to implement, it‘s better to make two different plugins, so the user can choose alternatives. This is a little bit different for LanguagePlugins?. Pida provides a powerful selection mechanism for LanguagePlugins? that allows the user to select which Plugin should provide which functionality. For example: python and python_lint provide a validator for python sources, the user can select in the language priorities window which of those he want to use if both plugins are loaded. LanguagePlugins? can also implement everything a plugin can do, it is just easier to implement language support.

Language Plugin Features

The language framework currently provides support for the following features:

• Completer — Provides autocompleter suggestions
• Outliner — Structure browser of the document
• Validator — Display of Errors, Warnings, Codingstyle mistakes etc.
• Definer — Search for the definition of the current word/symbol
• Documentator — Returns the documentation of the current word/symbol to be displayed as editor overlay
• LanguageInfo? — General information collection about a document type like brackets, member access etc

A LanguagePlugin? can provide 1 or many of the services above for n doctypes or for all as a generic one.

Each of this interfaces only yields a specific object defined in pida.utils.languages and each of the instances returned should not carry unnecessary ballast. This is important for the External interface.

LanguagePlugins? also provide another, very powerful mechanism called External. If your plugin does a lot of work in python, the GIL would slow down the Pida GUI a lot. The External interface does following: It spawns additional python interpreters and the actual work of your class is done there. Currently it uses multiprocessing to do this. See python or the python_lint how to use it. If your plugin just runs a external program like ctags and you interpret the output using External would be overkill or even slower. If multiprocessing is not available or disabled, your code will run in the normal pida loop.

There is one restriction in the default interface for multiprocessing support. The Outliner yields OutlinerItem? (sub)classes that have a parent reference. You can't do that. You have to give each element an id attribute and set the parent_id to this. Thats all :-)

Start a new plugin

Follow GettingStartedWithHackingPida to get the pida sources and to get a working copy.

The easiest way to start a plugin is to use the creator script:

./tools/creator.py

It asks for necessary informations so you can just delete what you don't need.

Tips for development

• If you use External, tracebacks do not contain the actual code filenames and lines due the nature of how multiprocessing works. Development is better done with starting pida with the --disable-multiprocessing parameter. Multiprocessing is also disabled on machines with one CPU core, but can be forced with --force-multiprocessing.