On startup, jEdit runs any BeanShell scripts located in the
startup
subdirectory of the jEdit installation and
user settings directories (see the section called “The jEdit Settings Directory”).
As with macros, the scripts must have a .bsh
file
name extension. Startup scripts are run near the end of the startup
sequence, after plugins, properties and such have been initialized, but
before the first view is opened.
Startup scripts can perform initialization tasks that cannot be
handled by command line options or ordinary configuration options, such
as customizing jEdit's user interface by changing entries in the Java
platform's UIManager
class.
Startup scripts have an additional feature lacking in ordinary macros that can help you further customize jEdit. Variables and methods defined in a startup script are available in all instances of the BeanShell interpreter created in jEdit. This allows you to create a personal library of methods and objects that can be accessed at any time during the editing session in another macro, the BeanShell shell of the Console plugin, or menu items such as
> > .The startup script routine will run script files in the installation directory first, followed by scripts in the user settings directory. In each case, scripts will be executed in alphabetical order, applied without regard to whether the file name contains upper or lower case characters.
If a startup script throws an exception (because, for example, it
attempts to call a method on a null
object). jEdit
will show an error dialog box and move on to the next startup script. If
script bugs are causing jEdit to crash or hang on startup, you can use
the -nostartupscripts
command line option to
disable them for that editing session.
Another important difference between startup scripts and ordinary
macros is that startup scripts cannot use the pre-defined variables
view
, textArea
,
editPane
and buffer
. This is
because they are executed before the initial view is created.
If you are writing a method in a startup script and wish to use one of the above variables, pass parameters of the appropriate type to the method, so that a macro calling them after startup can supply the appropriate values. For example, a startup script could include a method
void doSomethingWithView(View v, String s) { ... }
so that during the editing session another macro can call the method using
doSomethingWithView(view, "something");