Re: Normalize PicoLisp Wiki Syntax
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
content.
> 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.
--
cheers,
Thorsten
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Normalize PicoLisp Wiki Syntax
Hi Thorsten 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. 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? I don't think that its necessarily ugly, though. Symmetric markup might make it easier for the _human_ to read. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Normalize PicoLisp Wiki Syntax
José Romero writes: > It's not an improvement, and not worth it, imo. The current wiki syntax > is pretty much a lightweight variant of TeX, Emacs can fontify TeX just > fine, so the issue is in the emacs mode, not the syntax. It does look pretty ugly, I agree, and I wasn't sure myself if it would be such a good idea. It would make some things easier, but these things are not impossible with the current syntax either. Thanks for the feedback, I think you are right. -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Normalize PicoLisp Wiki Syntax
On Sat, 24 Nov 2012 17:29:13 +0100
Thorsten Jolitz wrote:
>
> Hi List,
>
> when writing the picolisp-wiki-mode for Emacs, I began to understand
> why 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.
>
> The PicoLisp Wiki Syntax does not follow this convention:
>
>,---
>| 3{Heading} Heading (level 3)
>|Levels 1 .. 6 are allowed
>|
>| &{3} Insert 3 line breaks
>| &{-3} Insert 3 line breaks, clear float
> style |
>| /{italic} Italic font
>| !{bold}Bold font
>| _{underline} Underlined font [...]
>`---
>
> Considering the possible nesting of elements (e.g. a bold word inside
> a link inside a list item), it becomes very difficult to construct
> regexp that reliably identify elements (necesary for fontification)
> because there are so many closing braces '}' around (and there might
> even be closing braces in the text itself).
>
> What about changing the syntax to this:
>
>,---
>| 3{Heading}3 Heading (level 3)
>|Levels 1 .. 6 are allowed
>|
>| &{3}& Insert 3 line breaks
>| &{-3}& Insert 3 line breaks, clear float
> style |
>| /{italic}/ Italic font
>| !{bold}!Bold font
>| _{underline}_ Underlined font [...]
>`---
>
> I know, its one more char to type (not when you use the
> picolisp-wiki-mode for Emacs) and looks ugly, but would make things a
> bit more 'standard' and easier to deal with. Its not really a big
> issue, since the picolisp-wiki-mode works fine even if fontification
> is a bit random. Don't know if it would be an improvement and worth
> the pain.
>
It's not an improvement, and not worth it, imo. The current wiki syntax
is pretty much a lightweight variant of TeX, Emacs can fontify TeX just
fine, so the issue is in the emacs mode, not the syntax.
-Jose
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Normalize PicoLisp Wiki Syntax
Hi List,
when writing the picolisp-wiki-mode for Emacs, I began to understand why
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.
The PicoLisp Wiki Syntax does not follow this convention:
,---
| 3{Heading} Heading (level 3)
|Levels 1 .. 6 are allowed
|
| &{3} Insert 3 line breaks
| &{-3} Insert 3 line breaks, clear float style
|
| /{italic} Italic font
| !{bold}Bold font
| _{underline} Underlined font [...]
`---
Considering the possible nesting of elements (e.g. a bold word inside a link
inside a list item), it becomes very difficult to construct regexp that
reliably identify elements (necesary for fontification) because there
are so many closing braces '}' around (and there might even be closing
braces in the text itself).
What about changing the syntax to this:
,---
| 3{Heading}3 Heading (level 3)
|Levels 1 .. 6 are allowed
|
| &{3}& Insert 3 line breaks
| &{-3}& Insert 3 line breaks, clear float style
|
| /{italic}/ Italic font
| !{bold}!Bold font
| _{underline}_ Underlined font [...]
`---
I know, its one more char to type (not when you use the
picolisp-wiki-mode for Emacs) and looks ugly, but would make things a
bit more 'standard' and easier to deal with. Its not really a big issue,
since the picolisp-wiki-mode works fine even if fontification is a bit
random. Don't know if it would be an improvement and worth the pain.
--
cheers,
Thorsten
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
