Hi James

I think I miss some things because there's no clear specification.
I still feel like your regexp could be lighter, or porbably split in several.

On Sat, Nov 1, 2008 at 1:13 AM, james jwm-art net <[EMAIL PROTECTED]> wrote:
> Hi Clemos,
>
> On 31/10/2008, "clemos" <[EMAIL PROTECTED]> wrote:
>>this looks cool.
>>did you experiment things like Markdown
>>(http://daringfireball.net/projects/markdown/) or such text to html
>>converters ?
>
> No I've not heard of Markdown before. (nor have I experimented with any
> other text to html converters). Just now took a quick look, it's quite
> interesting, but has slightly different goals:
>
> (i'm not completely sure, the area's a bit blurred)
>
> it wants maximum readability of the _text_it_translates_ and is more
> xtxexxxtx prose orientated
>
> mine is (perhaps) more layout orientated. i want it to be easy to display
> things which look like markup, and things which look like code, such as
> odd sequences of characters. and i want it to be easy to display images
> or links to other pages (ie main=image=ride-03, ilink=page_name,
> xlink=url), so have two + two characters as delimiters for embeding
> things is ok, and the @= and =@ characters are uncommon combinations.

To me, the best idea in Markdown is to use shorter delimiters for
simplest/most common tags (like * * for bold, ** ** for italic, # for
title) : quicker to write, clearer to read (no big markup in simple
text blocks).
Images and links are both supported, as well as embedding raw HTML.

About the ilink / xlink functions, my approach would be to have only
one function for handling links, and use a custom href syntax. For
example : link=url would link to an absolute url, and link=p:page_name
would link to the named page. Like this, you can more easily extend
the syntax (img:image_name to link an image, file:file_name for files,
youtube:youtube_id, whatever). Btw, using a "protocol:" prefix makes
it look more like standard urls.
The goal (once again) is to split the regexp to have one for
retrieving tags, and then other regexps for interpreting them. Like
this, the regexps will likely be simpler, faster, and easier to
extend.
In general, using several simple regexp is better than using a single
big one, IMHO.

>>my suggestion for a lighter regexp (untested) :
>>$pattern = "[EMAIL PROTECTED]([^=]*)=([^=]*)[EMAIL PROTECTED]";
>>$replaces = array();
>>if(preg_match_all($pattern,$str,$matches)){
>>  for($i=0;$i<count($matches[0]);$i++){
>>    $full_tag = $matches[0][$i];
>>    $command = $matches[1][$i];
>>    $argument = $matches[2][$i];
>>    $replaces[$full_tag] = my_html_generator($command,$argument);
>>  }
>>  $output = strtr($str,$replaces); // there's probably a faster way by
>>using PREG_OFFSET_CAPTURE
>>}
>>
>
> quick test of your regex:
> http://www.jwm-art.net/test2.php
>
> doesn't look like it works enough for what i want:
>
> @=b=bold text=@ is determined as an at-tag
> @= and =@  is not an at-tag, just printable
> <p>will display '<p>' ( &lt;p&gt; ), not create the <p> element
>
> @=b=bold text with @=i=italic=@ also=@
> splits as:
>    1 an at tag: @=b=bold text with @=i=italic=@
>    2 just text: also=@
>
> correct form:
> @[EMAIL PROTECTED] syntax for bold, @=i=embedding italic=@ within [EMAIL 
> PROTECTED]@
>
> (ie no recursive tag detection - shudder)

You're right I didn't get you could nest tags like this, or have @=b=@ tags.
Once again I think you should write a clear specification so that
you're sure you don't get conflicts or inconsistencies later, and you
know exactly what is an expected behaviour and what is a bug.

> @=br=@ creates <br> element
> @=raw=whatever raw html you want=@
> @[EMAIL PROTECTED]@
>  ( ie @=\= is like an escape sequence for preserving at-tag as text )
>
>
>
> my previous test.php script now displays my at-tags splitting function
> code. if you want a quick look, scroll down to bottom of page:
> http://www.jwm-art.net/test.php
>
>>Regexp are so cool. I remember when I discovered that, I found myself
>>very powerful...
>
> They're something I've been putting off for a long time, but with a
> good tutorial they're not as intimidating as they appear :-)
>
> http://www.regular-expressions.info

sexy.

regards
++++++++
Clément

> Cheers,
> James.
>
>
>
>>On Fri, Oct 31, 2008 at 1:46 AM, james jwm-art net <[EMAIL PROTECTED]> wrote:
>>> working toward open-sourcing jwm-art.net
>>> text-file-based content (*)management system...
>>>
>>>    *maybe mis-management
>>>
>>> some lines that might be found in a text file
>>> for a page on jwm-art.net:
>>>
>>>    main=text=a line of text with a link to the @=ilink=test=@ page.
>>>    [EMAIL PROTECTED]<<ENDTEXTLINE=@
>>>    at-tags allow links and other HTML elements to be embedded
>>>    within a paragraph of text. text as presented in the text
>>>    file for a page is strictly formatted to @=b=prevent=@
>>>    characters used in HTML from being interpretted as such.
>>>    ENDTEXTLINE
>>>    main=image=ride-03@:image from ride-03 page.
>>>
>>> testing a regular expression for detection of
>>> 'at-tags' - jwm-art.net-style delimiters for
>>> embedding HTML elements within text.
>>>
>>>    (took eight hours to learn how to use regular)
>>>    (expressions to arrive at what i thought)
>>>    (worked in all cases but did not)
>>>
>>> http://www.jwm-art.net/test.php
>>>
>>> test:    $pat='/((?:@=[a-z]+)(?:=@|=[\S ]+?(?==@)))/';
>>> actual:  $pat='/((?:@=[!a-z\\/\\\]+)(?:=@|=[\S \n]+?(?==@)))/';
>>> for use: $res=preg_split($pat,$str,-1,PREG_SPLIT_DELIM_CAPTURE);
>>> (((allows things like @=b=bold\nbold\nstill bold=@ (where line split in
>>> file)
>>> (((and @=\=display-at-tag=@ @=/=html comment=@ etc
>>> (((and @=!=some kind of conditional ICROH used mainly by journal =@
>>>
>>> more:
>>>    http://www.jwm-art.net/light.php?p=test
>>>
>>> more splitting out of functions for these things...
>>>
>>> keywords page displays the first few lines from the info section of
>>> a page. look here (notice links):
>>>
>>> http://www.jwm-art.net/light.php?p=str-frag-1.0
>>>
>>> then look at the same information in the keywords listing for that
>>>
>>> http://www.jwm-art.net/light.php?p=keywords&k=chaos
>>>
>>> (( code now less confuse so link never made
>>> (( as link never made, never get format
>>> (( so link element never dis-splayed, like old.
>>>
>>> ----------
>>>
>>> steps to open source
>>>
>>> 1) further study of my code and thinking ways to improve it
>>> 2) removing content from potential src package
>>> 3) creating documentation for usage of src as content
>>>
>>> 4) remember that we(i) were(was) going to help people out
>>>   by closing open tags (ie for bold text, italic etc)
>>>   span anyone? hmmmm, exists, but, but, maybe we have to
>>>   be crawl to be kined?
>>>
>>> 5) remember to investigate keyword functioning for potential
>>>   code efficiency improvements(ie is it possible to avoid:
>>>      grep key1 | grep key2 | grep key3 in favour of regular
>>>   expression? can more advanced regexps help in keyword
>>>   functioning?
>>>
>>> 6) stop blabbling so much
>>>
>>> _______________________________________________
>>> NetBehaviour mailing list
>>> NetBehaviour@netbehaviour.org
>>> http://www.netbehaviour.org/mailman/listinfo/netbehaviour
>>>
>>
>>_______________________________________________
>>NetBehaviour mailing list
>>NetBehaviour@netbehaviour.org
>>http://www.netbehaviour.org/mailman/listinfo/netbehaviour
>>
>
> _______________________________________________
> NetBehaviour mailing list
> NetBehaviour@netbehaviour.org
> http://www.netbehaviour.org/mailman/listinfo/netbehaviour
>

_______________________________________________
NetBehaviour mailing list
NetBehaviour@netbehaviour.org
http://www.netbehaviour.org/mailman/listinfo/netbehaviour

Reply via email to