Updated syntax (removed many useless and bad <div> tags).

Use definition list as well in wikitext syntax.

git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1659 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/trunk/eiffelstudio/Tutorials/appendix-writing-documentation-filters-eff-eiffel-filter-format.wiki

@@ -9,14 +9,14 @@ We saw in the [[PRODUCING AND EXPORTING DOCUMENTATION|section on documentation]]
 * Producing documentation that purposely omit some parts of Eiffel texts, in line with the ideas applied by the Contract and Flat Contract forms.
 
 This appendix describes EFF and its conventions, enabling you to write filters. Note that in practice the best way to write an EFF filter is usually not from scratch, but by copying an existing filter -- one that seems closest to your needs -- and adapting the copy.
-<div> 
+
 ==Where to put filters==
 
 When you choose to generate documentation, EiffelStudio will ask you to select a filter from a list it obtains by looking up the files of extension <span>.</span> <code>fil</code> in the directory 
 <code>$ISE_EIFFEL/studio/filters</code>
 
 To make a new filter available to yourself and other users of this installation, just add the corresponding file <code>name</code> <span>.</span> <code>fil</code> to this directory. Make sure to choose the appropriate <code>name</code>, since this is what the menu of available filters will display. 
-</div><div> 
+
 ==Filter basics==
 
 An EFF filter follows a very simple structure. As with all other Eiffel-related notations (such as Eiffel itself and Lace, the control language for Eiffel systems), any line or part of a line beginning with two consecutive dashes <code>--</code> is a comment, except if it immediately follows a percent sign since, as will be seen below, <code>- %-</code> is used to denote an Eiffel comment in the class text. Blank lines are also permitted. Comments and blank lines carry no semantic value. 
@@ -27,7 +27,7 @@ Except for comments and blank lines, a filter is a sequence of entries, all of t
 where: <code>Construct</code> is one of a set of possible strings, most of which correspond to Eiffel constructs such as <code>Class_declaration</code> or Eiffel keywords such as <code>class</code> ; and <code>Replacement</code> is a string indicating how to format specimens of the <code>Construct</code> that appear in a class text. 
 
 For readability, there may be any number of blanks or tabs between the <code>Construct</code> and the vertical bar <code>|</code>, so that you can align all the bars if you wish. On the right of the bar, however, all characters including blanks and tabs are significant, since they are part of the replacement for the <code>Construct</code>. 
-</div><div> 
+
 ==The asterisk==
 
 In the <code>Replacement</code> part, you may use the symbol <code>*</code> (asterisk) to denote the construct specimen itself. So for example the entry 
@@ -42,7 +42,7 @@ means that the Eiffel keyword <code>external</code> must appear in the filtered
 <code>Keyword |<B> * </B></code>
 
 which, thanks to the asterisk, will govern all construct specimens of the <code>Keyword</code> category. You can still override this specification for an individual keyword by including a specific entry for it. 
-</div><div> 
+
 ==Constructs==
 
 The following general syntactic constructs may appear as the left-hand side, <code>Construct</code>, of an entry: 
@@ -79,13 +79,13 @@ The constructs corresponding to syntactic constructs are self-explanatory. The o
 *  <code>Symbol</code>, denoting any of the Eiffel symbols listed in the corresponding appendix of <span> [[Eiffel: The Language]] </span>. 
 *  <code>Escape</code>, to protect special characters of the external tool, as explained below. 
 *  <code>Tab</code>, denoting any tab character appearing in the class text. 
-<div> 
+
 ==Keywords==
 
 A <code>Construct</code> part may consist of the name of an Eiffel keyword. To see the complete list of possible keywords, look at the <code>template</code> filter, file <code>format.fil-template</code> in the default filter directory <code>$ISE_EIFFEL/studio/filters</code>, which includes all of them with a single asterisk <code>*</code> as the <code>Replacement</code> part. 
 
 If entries are present for both the <code>Keyword</code> construct and individual keywords, the individual keyword entries will override the general entry for the keywords listed; the general entry will apply to all other keywords. This makes it possible to have both a general convention for keywords and a special convention for some of them. 
-</div>
+
 ==Symbol==
 
 A <code>Construct</code> part may consist of an Eiffel symbol, such as <code>:=</code>, <code>/=</code> and many others. Again, you may see the complete list by looking at <code>format.fil-template</code>. Note the following conventions: 
@@ -93,7 +93,7 @@ A <code>Construct</code> part may consist of an Eiffel symbol, such as <code>:=<
 * Similarly, the Eiffel comment symbol appears as <code>- %-</code>, since just writing <code>- -</code> would introduce a comment in the EFF filter itself. 
 
 As with keywords, you may specify a general convention for symbols, defined by an entry for the construct <code>Symbol</code>, and special conventions for certain individual symbols. Specific symbol entries will override the general <code>Symbol</code> convention. 
-</div>
+
 ==Escape characters==
 
 A text processing system or other external tool may attach a special role to characters that may normally appear in Eiffel texts. For example, the braces <code>{</code> and <code>}</code>, used in Eiffel's Export clauses, have a special meaning for TEX. Including them without precaution in TEX input will cause trouble. Similarly, many text processing formats attach a special meaning to the backslash character <code>\</code> which, although not special for Eiffel, may appear in an Eiffel string. 

documentation/trunk/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki

@@ -33,12 +33,12 @@ The syntax is pretty simple when you understand what you need to export a featur
 ROOT_CLASS (make): foo @ 4 Alias my_foo call_type __stdcall</code>
 
 ===Constraints===
-* on the class: <div>The class cannot be deferred or generic.</div>
-* on the feature: <div>It could be any feature except an attribute, an external feature or a deferred feature.</div>
-* on the creation procedure: <div>It must have zero argument, and no return type.</div>
-* on the alias name: <div>It must be a valid name for a C function.</div>
-* on the index: <div>It must be strictly positive.</div>
-* on the call type: <div>It must be a valid call type for the targeted platform (useful for Windows only). For Visual C++, the valid calling conventions are __stdcall, __cdecl and __fastcall.</div>
+; on the class: The class cannot be deferred or generic.
+; on the feature: It could be any feature except an attribute, an external feature or a deferred feature.
+; on the creation procedure: It must have zero argument, and no return type.
+; on the alias name: It must be a valid name for a C function.
+; on the index: It must be strictly positive.
+; on the call type: It must be a valid call type for the targeted platform (useful for Windows only). For Visual C++, the valid calling conventions are __stdcall, __cdecl and __fastcall.
 
 For each feature the required fields are the '''class''', the '''creation procedure''', and of course the '''feature''' itself. 
 * If the feature is a creation procedure then do not specify any creation, it will use the feature as creation. For example '''ROOT_CLASS: make'''. 
@@ -60,4 +60,5 @@ BAR (make_a) : print_bar
 -- Here the feature is also a creation
 ROOT_CLASS : make
 ROOT_CLASS (make) : foo
-ROOT_CLASS (make) : test_bar</code>
+ROOT_CLASS (make) : test_bar
+</code>