Posts tagged 'plugin'

Smarter tag search in Vim

published on November 01, 2017.

As part of my Vim setup for PHP development, I use the vim-php-namespace plugin to add use statements in my PHP code.

vim-php-namespace uses the tags file to find the class and the namespace it belongs to, and then adds it to the rest of the use statements.

It all works great, but there are times when it shows too much possibilities.

For example, when I want to import the namespace for the Transaction class, it finds the correct Transaction class, but it also finds functions called transaction in my codebase, and then gives me a choice what I want to import:

See? One class (kind c), and two functions (kind f).

I could exclude functions from being generated in tag files, but that’s not really an option because there are times when I need the functions tags.

I dove into the vim-php-namespace source code, determined to get rid of this “functionality”.

Turns out the plugin actually uses a Vim command, called ptjump, to search the tags file and show the preview window, so the user can pick out the correct tag in case there’s more than one.

Of course there’s an option for that

Then I started reading the help pages for tags in more detail, and after a while I found the answer: tagcase.

To quote the help file:

This option specifies how case is handled when searching the tags file.

And it has the following options:

  • followic Follow the ‘ignorecase’ option
  • followscs Follow the ‘smartcase’ and ‘ignorecase’ options
  • ignore Ignore case
  • match Match case
  • smart Ignore case unless an upper case letter is used

I’ve set it to smart and, well, now it does what I want it to do:

set tagcase=smart

It correctly finds only one match for the Transaction class and the plugin inserts the use statement for it. Yey!

Happy hackin’!

Tags: namespace, php, plugin, tags, vim.
Categories: Development, Software.

Import custom Python modules in Vim plugins

published on June 16, 2016.

This took me a while to figure out so I’m writing it down for future self and anyone else who needs it.

I started writing a new Vim plugin that will use the Python interface as most of the work will be done there, mostly to keep my sanity.

Having a plugin layout such as:

├── lib
│   └── mypymodule
│       └──
└── plugin
    └── my-vim-plugin.vim

I want to be able to do a

from mypymodule import ham

from within the my-vim-plugin.vim file.

For that to happen the <sfile> command line special comes to rescue. It is the file name of the sourced file in Vim, that is, the file name of the Vim plugin. Using the :p and :h file name modifiers it gives us the full path to the plugin directory of our plugin.

" This will give something like
" /home/robert/projects/my-vim-plugin/plugin
let g:plugin_path = expand('<sfile>:p:h')

And here comes the kicker: the <sfile> needs to be expanded outside of our Vim function where it is used, otherwise the <sfile> points to the path of the file that called the Vim function.

In code, getting the path to the sourced file from within the Vim function would be incorrect:

" ./plugin/my-vim-plugin.vim
function! MyVimPlugin()
python << endpython

import vim

vim.command("let a:plugin_path = expand('<sfile>:p:h')
plugin_path = vim.eval("a:plugin_path")
print plugin_path


because it would end up printing the current working directory from where the MyVimPlugin function is called.

The correct way to do is to get the path to the sourced file outside of the Vim function:

" ./plugin/my-vim-plugin.vim
let g:plugin_path = expand('<sfile>:p:h')

function! MyVimPlugin()
python << endpython

import vim

vim.command("let a:plugin_path = expand('<sfile>:p:h')
plugin_path = vim.eval("a:plugin_path")
print plugin_path


This way the path is set at the time the plugin is sourced and not at the time when function is called.

Finally, to be able to import the mypymodule from the lib, we need to point to the lib directory and add it to the system paths. Complete example:

" ./plugin/my-vim-plugin.vim
let g:plugin_path = expand('<sfile>:p:h')

function! MyVimPlugin()
python << endpython

import os
import sys
import vim

" Get the Vim variable to Python
plugin_path = vim.eval("g:plugin_path")
" Get the absolute path to the lib directory
python_module_path = os.path.abspath('%s/../lib' % (plugin_path))
" Append it to the system paths

" And import!
from mypymodule import ham


By the way, here’s the documentation for the Vim Python module.

Happy hackin’!

Tags: plugin, python, vim.
Categories: Development, Programming.

Vim Hugo helper

published on March 25, 2016.

I think I just wrote my first Vim plugin. OK, it’s more a bunch of Vim functions slapped together than an actual plugin, but gotta start somewhere, right?

Last week I converted this blog to a static web site and I’m using Hugo as the static website engine. Writing posts is a lot easier now, plus it’s written in Go, which I started learning a few weeks ago.

Vim Hugo helper is a plugin, collection of Vim functions that help me while writing posts. It will hopefully speed up a few recurring tasks such as drafting and undrafting posts, inserting code highlight blocks, etc. I guess I’ll be adding more to it in the future, but for now it has a total of 5 functions.

Front matter reorder

Hugo posts have a front matter which is basically meta data for the content. Hugo will create the front matter out of an archetype which is a template of sorts for the front matter. One thing I don’t like is that when a new post is created, the meta data is sorted alphabetically so the HugoHelperFrontMatterReorder function reorders it in the way that I do like.

Drafting/undrafting posts

The HugoHelperDraft and HugoHelperUndraft functions simply draft and undraft posts by setting the draft meta data in the front matter to either true or false.

Code highlight blocks

The HugoHelperHighlight(‘language’) function inserts the highlight shortcode that comes built-in with Hugo and sets the language of the highlight block.

Setting the date of the post

Finally, the HugoHelperDateIsNow function sets the date meta data of the post to the current date and time.

It’s not much, definitely has room for improvements, but I used it even when writing this very post, so I guess this helper is helpful.

Tags: hugo, plugin, vim.
Categories: Development, Programming.

Loading custom module plugins

published on July 20, 2010.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

OK, here’s a quicky one from the office :P

I was trying to load a Front Controller plugin which resides in app/modules/my_module/controllers/plugins/ and not in the “usual” lib/My_App/Plugin/. I want this plugin to be called in every request and I want the plugin file to be under it’s “parent” module.

Here’s what I did: added the path to the plugin and it’s namespace to the Zend_Application_Module_Autoloader as a new resource type and then just register the plugin in the front controller in an other _init method.

Code is better, here’s some:

class News_Bootstrap extends Zend_Application_Module_Bootstrap
     * Autoloader for the "news" module
     * @return Zend_Application_Module_Autoloader
    public function _initNewsAutoload()
        $moduleLoader = new Zend_Application_Module_Autoloader(
                                    'namespace' => 'News',
                                    'basePath' => APPLICATION_PATH . '/modules/news'

        // adding model resources to the autoloader
                    'plugins' => array(
                        'path' => 'controllers/plugins',
                        'namespace' => 'Controller_Plugin'

        return $moduleLoader;

    public function _initPlugins()
        $fc = $this->getResource('frontcontroller');

        $fc->registerPlugin(new News_Controller_Plugin_Scheduler());

If anyone knows a better way for doing this, please do share it with me.

Now back to work. Cheerio.


published on February 04, 2010.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

At the office we’re starting out on a new project, which will require (thanks to our designer) a lot off divs and images and whatnot to slide up and down. All these elements will of course have it’s own ID’s and classes, so writing one function to slide/toggle them all is impossible, plus the design of these elements is so weird that the built-in animation effects are of no use. So I hacked together my first! jQuery plugin which will hopefully help us with this task.

As I was more inspired to write code, than to come up with names, I called this little fella toggler, a jQuery plugin for togglering elements around…

What it does is actually calling .animate() on the height the top of the element that is to be togglered.

Setting it up is easy: include the jquery-toggler.js script, call the toggler() function on any clickable element and set the rel attribute of that element to match the ID of the element which is to be togglered (clearly, if you look in the source of the example, you’ll understand that better than my jibberish).

The default height when the element is closed (togglered up) is 0px, when the element is open (togglered down) is 200px and the default speed of this magical animation is set to 1000 (1 second). You can of course change these by passing them to the toggler({speed:500}) function.

toggler is available at GitHub:

Example is here:

toggler yourself out.

Edit Februray 6th: Apparently I completely misunderstood the designer what kind of effect he wants, thus now I changed the code. The new code is pushed to github and the example is updated.

Tags: jquery, plugin, toggler.
Categories: Development, Programming.
Robert Basic

Robert Basic

Software engineer, consultant, open source contributor.

Let's work together!

If you require outsourcing or consulting help on your projects, I'm available!

Robert Basic © 2008 — 2018
Get the feed