migrating to v3.0

This applies to projects and files used with Xilize 2.0.

features pending

ErrorList plugin dependency

The ErrorList plugin is required now. The Xilize parser generates errors and warning to the ErrorList window where you can click to jump to the relevant file and line. You may find it convenient to turn on all the options in The ErrorList plugin's options panel.

(I see handling errors and warnings this way as a great benefit. Feedback appreciated.)

new mode file

Use Plugins > Xilize > options to install the mode file. You will then get propper syntax highlighting (to the extent possible with jEdit and Xilize markup) for the new signatures.

project identification

Previous projects where identified by the location of a *.xilize file (or the existence of a *.xilize file that contained information about the location of the project root directory.) That restriction has been removed.

At the beginning of translation, Xilize now looks up the directory tree for a root.xilconfig file. If found its directory is used as the project root directory. If not, it looks up the tree again, this time for a dir.xilconfig file — stopping as soon as one is located — and takes that as the project root. If neither of these files is found, the current directory is used as the root. See the section below. (From the command line this is achieved with the --find-root option.)

So if you Xilize a single file and the search for a root fails you get a near equivalent to the old "classic mode" translation. The benefit is you generally don't have to be concerned one way or the other.

one mode

Xilize2 introduced "natural" mode and used the term "classic" to distinguish it from the way the orginal Xilize worked. Both modes were supported. That distinction is no longer necessary and has been removed without loss of functionality.

legacy "classic" mode support

To get Xilize 3.0 to simulate the "classic" mode of 2.0, use

define. _Natural_ false

The easiest way to do this depends on your use of Xilize, however, if you put this line in root.xilconfig at the top of a directory tree it will apply to the whole tree. It can also go in a dir.xilconfig to apply to a subtree.

configuration files

A new per-directory configuration file has been introduced: dir.xilconfig and symbol definitions there (e.g. define, defadd, signature) apply to all files in that directory and its subdirectories and to only those files.

*.xilize, the old project configuration file is now root.xilconfig. Much of what is there might better go in a dir.xilconfig file. Rename *.xilize to root.xilconfig.

common.xilinc is honored, but there are advantages to using the new dir.xilconfig instead.

file system browser

*.{xil*,css,js,bsh} is a handy filter in jEdit's File System Browser.

using defadd

Previous versions gave special handling of style and script keys. When the define directive was used with either of these new values was appended to the existing one. That special handling has been removed and an additional directive — defadd — has generalized the behavior. If you have been using this feature replace define with defadd for style and script keys.

"looks like a signature"

A paragraph beginning with a single word sentence may generate a warning looks like a signature. To turn the warning off use

define. NoWarnOnLooksLikeSig true

Put this in the *.xil or *.xilinc file that is generating the warning. It is very useful to leave it enabled.

text that looks like a macro

Any occurance of &{ ... } will be interpreted as a macro. To avoid that interpretation use &{ ... }.

command line use

See command line use in Xilize by Example.

system properties

On startup Xilize loads the system properties — as returned by System.getProperties() — into its environment. (Thanks for the suggestion, Tiago.)

${java.version} 1.6.0_01
${java.vendor} Sun Microsystems Inc.
${java.vendor.url} http://java.sun.com/
${java.home} /home/andy/wdev/bin/jdk1.6.0_01/jre
${java.vm.specification.version} 1.0
${java.vm.specification.vendor} Sun Microsystems Inc.
${java.vm.specification.name} Java Virtual Machine Specification
${java.vm.version} 1.6.0_01-b06
${java.vm.vendor} Sun Microsystems Inc.
${java.vm.name} Java HotSpot™ Client VM
${java.specification.version} 1.6
${java.specification.vendor} Sun Microsystems Inc.
${java.specification.name} Java Platform API Specification
${java.class.version} 50.0
${java.class.path} /home/andy/jedit/4.3pre9/jedit.jar
${java.io.tmpdir} /tmp
${java.compiler} ${java.compiler}
${java.ext.dirs} /home/andy/wdev/bin/jdk1.6.0_01/jre/lib/ext:/usr/java/packages/lib/ext
${os.name} Linux
${os.arch} i386
${os.version} 2.6.8-2-386
${file.separator} /
${path.separator} :
${user.name} andy
${user.home} /home/andy
${user.dir} /home/andy


Tables with column specifiers, like this one:

table(cer). {{columns:
|{background:LemonChiffon;}. 70
|{background:LavenderBlush;}. 70
|=. 15
|{background:wheat;}=. 280
|{background:LemonChiffon}. *
_| CER | NER | display | description | charsets
| & | & | & | ampersand |  |

must be altered like this:

table(cer). &{columns:
|{background:LemonChiffon;}. 70
|{background:LavenderBlush;}. 70
|=. 15
|{background:wheat;}=. 280
|{background:LemonChiffon}. *
} >>> note single '}'
_| CER | NER | display | description | charsets
| & | & | & | ampersand |  |

to conform to the new syntax for macros.

special heading (h1, h2, etc) markup for table of contents entries

What was {{toc:xxx}} and {{tocEntry:xxx}} is now &{toc:xxx} and &{tocEntry:xxx} to match the macro syntax.

footnote div element

A group of consecutive footnotes fnN is no longer automatically placed in a <div>. Use the div signature to achieve the same effect.