Alexander Burger <> writes:

Hi Alex and José,

> in addition what you have already discussed:
>> mark-up syntax is usually symmetric, i.e. the end-tag looks like a
>> 180° mapping of the start-tag (e.g. the JSP Scriplet <% ... %>). 
>> This makes parsing the file and constructing regexp much easier, because
>> its always clear which end-tag belongs to which start-tag. 
> I don't agree that it makes parsing easier.
> The parsing itself only involves the start pattern. Then the parsed data
> extends till the closing '}'. A regular expression with all its overhead
> is neither needed nor used in the wiki. The stream can simply and
> efficiently be read on a character-by-character basis.

But in Emacs Lisp I have to use regexp for the fontification mechanism.
And even if the Wiki syntax is similar to LaTeX the regexp's for the
picolisp-wiki-mode are much more difficult, since in LaTeX frequently
only the commands and some args are inside the braces:

| \begin{description}
| \item[Variable] text text text text text ...

while in the picolisp wiki syntax it does not look like this

| *begin{list}
|   list with :{code} examples
| *end{list}

but rather like this

| *{
|    -{:{'lst} is used instead of :{'num}, i.e. instead of incrementing
|    a counter :{N} until upper limit :{'num} is reached, :{sym} is
|    subsequently bound to the elements of :{'lst}.}
|    -{instead of a single :{sym}, a cons pair or dotted pair :{(sym2
|    . sym)} can be used. }
| }

i.e. bigger elements include their whole content and all sub-elements
(and sub-sub-elements etc) inside their braces. Now try to figure out a
regexp that allows you to put all the :{...} in code-font and the plain
text part inside -{...} in list-font and the :{} and *{} and -{} itself
in keyword-font or so. Taking account of all possible nestings and
combinations. I found that quite hard (and did not make it yet). 

> Having to parse two characters at the end make things more complicated,
> especially to decide what to do with the second character. It can be
> used only for error checks (markup balance), but what to do upon an
> error? Where to print the error message? Into the generated document?

But its Elisp and I have to use regexp's, so it would actually be easier
to describe 'text between *{ and }*' in a regexp than 'text between *{
and one of the countless following } (the right one)'. I guess, even
with symmetric markup this would not be easy for big elements with much

> I don't think that its necessarily ugly, though. Symmetric markup might
> make it easier for the _human_ to read.

But anyway, its not worth the effort to change anything, and it helps
already a lot that the picolisp wiki syntax itself (e.g. :{} and *{} and
-{}) is correctly fontificated in the picolisp-wiki-mode. Maybe it would
not even be a good thing to have so much colors in the buffer. 

The mode is working fine for writing articles, and the coloring is
really just optional fancy stuff and a matter of taste, I'm not even
sure if I would like a buffer full of colors better.



Reply via email to