The initial thought of file specific preferences was to enable eskil to handle files that need a kind of decoding to be able to be compared. Lets assume there is a Excel or libre-Office calc file. An eskil plugin should be able to extract the contents - maybe as csv - and then compare the files.

At the moment this would be a plugin just like any other. So you select this plugin and eskil runs it. However maybe it may be sensible to distinguish between a file decoder and a preprocessor plugin. With the Excel file example from above it would be advantageous to chain a file decoder and a preprocessor plugin. This way eskil could first decode the Excel file and then sort the contents based on some parameter the user could specify.

Currently eskil already has the info field in the plugin window to pass an argument to the plugin. But using this mechanism when chaining plugins would not be easy to use. To enhance this the plugin could tell eskil that it provides parameters. This could be done just the same way eskil detects a valid plugin, ie. in the header of the plugin file there is a definition of a parameter. Eskil would show an entry field in the plugin dialog which the user can fill in. Eskil would also save the contents of this field when saving the preferences.