subject:"\[tw\] Re\: TiddlyWiki Development News"

>> Great, that looks right. I think you'll need to add the shadow tiddler
>> support from App.js as well at some point.
>
>
> What for? The usual HTML rendering for Tiddly{Web,Space} ignores
> shadow tiddlers as artifacts of TiddlyWiki, not tiddlers in general.

Right; some TiddlyWiki content assumes the existence of the shadow
tiddlers by doing things like transcluding TabAll, or rendering
WindowTitle to get the page title. It's good if you've not been
running into cases where that matters.

Best wishes

Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News


On Tue, 31 Jan 2012, Jeremy Ruston wrote:


Great, that looks right. I think you'll need to add the shadow tiddler
support from App.js as well at some point.


What for? The usual HTML rendering for Tiddly{Web,Space} ignores
shadow tiddlers as artifacts of TiddlyWiki, not tiddlers in general.


You may also be interested in the new disableHtmlWrapperNodes option
for the WikiStore constructor; it suppresses the DIVs that are
otherwise inserted to help the refresh mechanism. In your environment
you probably won't want them.


Oh yes, that sounds useful.

--
Chris Dent   http://burningchrome.com/
[...]

--
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

Great, that looks right. I think you'll need to add the shadow tiddler
support from App.js as well at some point.

You may also be interested in the new disableHtmlWrapperNodes option
for the WikiStore constructor; it suppresses the DIVs that are
otherwise inserted to help the refresh mechanism. In your environment
you probably won't want them.

Best wishes

Jeremy

On Tue, Jan 31, 2012 at 11:36 AM,   wrote:
> On Tue, 31 Jan 2012, Jeremy Ruston wrote:
>
>>> That sound about right?
>>
>>
>> Bang on, yes.
>
>
> https://github.com/cdent/cook.js/commit/961713675461c93668b385e731ede015622b5360
>
> Has a very simple prove to myself that I get it.
>
>
> --
> Chris Dent                                   http://burningchrome.com/
>                                [...]
>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To post to this group, send email to tiddlywiki@googlegroups.com.
> To unsubscribe from this group, send email to
> tiddlywiki+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/tiddlywiki?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News


On Tue, 31 Jan 2012, Jeremy Ruston wrote:


That sound about right?


Bang on, yes.


https://github.com/cdent/cook.js/commit/961713675461c93668b385e731ede015622b5360

Has a very simple prove to myself that I get it.

--
Chris Dent   http://burningchrome.com/
[...]

--
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

>> Do you have many tests for twikifier? It'd be cool for TW5 to be able
>> to adopt/adapt them.
>
>
> Sadly no. I was in such a rush and flailing around with such ignorance
> when I was making twikifier that I was mostly just throwing code and
> hoping. The irony is that that's a great time to write tests, but you
> know...

TW5 has a very crude test rig that could be adapted to test over
twikifier, I think. It's just a folder of *.tid files alongside the
.html and .txt files that they wikify to:

https://github.com/Jermolene/cook.js/tree/master/test/wikitests

Best wishes

Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News


On Tue, 31 Jan 2012, Jeremy Ruston wrote:


Do you have many tests for twikifier? It'd be cool for TW5 to be able
to adopt/adapt them.


Sadly no. I was in such a rush and flailing around with such ignorance
when I was making twikifier that I was mostly just throwing code and
hoping. The irony is that that's a great time to write tests, but you
know...

--
Chris Dent   http://burningchrome.com/
[...]

--
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

> Thanks for the detailed info. I shall attempt to dig. Some comments
> within.
>
>
>> - Error handling is probably a bit inadequate
>
>
> I don't know about you but I've found effective error trapping and
> (especially) awareness quite challenging with node.

Yes, quite. I've settled on using the callback(err) pattern, and only
throw exceptions right up in the command line handling of
tiddlywiki.js.

A particularly troublesome issue is making sure that errors in
compiled (ie eval-ed) code are both properly trapped and helpfully
reported.

> The finally implementation of twikifier has just one cache: it caches
> (in memcache) the (skinny) JSON that is uses to makes its pseudo store
> (see below).

Cool. That would still be useful, and you could consider caching the
WikiStore and tiddler objects perhaps later.

> The part of your description that is most interesting is the
> dependency resolution.

Yes, it makes a big difference, and is very easy to do once one has
the parse tree lying around.

> so:
>
> * make a store
> * register parsers
> * What are tiddlerInput and tiddlerOutput?

(they handle deserialisation and serialisation of tiddlers; just a
pile of static functions, and I imagine you won't need them)

> * install macros
> * addTiddler
> * get its dependencies
> ** if null: load all tiddlers into store
> ** if list: load each of those tiddlers into store
> * renderTiddler
>
> That sound about right?

Bang on, yes.

Do you have many tests for twikifier? It'd be cool for TW5 to be able
to adopt/adapt them.

Best wishes

Jeremy


> --
> Chris Dent                                   http://burningchrome.com/
>                                [...]
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To post to this group, send email to tiddlywiki@googlegroups.com.
> To unsubscribe from this group, send email to
> tiddlywiki+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/tiddlywiki?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News


On Fri, 27 Jan 2012, Jeremy Ruston wrote:


Hey Jeremy, what's the status of your wikifier. It's it play-with-able
in a standalone kind of way? If so where and how?


With some caveats I think this is probably a good time to start
investigating. I think the code is capable of what you need, but it's
still rather in flux, and so can be changed in response to your
requirements.


Thanks for the detailed info. I shall attempt to dig. Some comments
within.


- Error handling is probably a bit inadequate


I don't know about you but I've found effective error trapping and
(especially) awareness quite challenging with node.


So, I've tried to arrive at an implementation that supports both
approaches. One of the hallmarks of the design is the aggressive use
of caching to support efficient selective updating of the DOM. I think
a big area of discussion around this integration is how we can ensure
that our respective caching strategies work well together.


The finally implementation of twikifier has just one cache: it caches
(in memcache) the (skinny) JSON that is uses to makes its pseudo store
(see below).


Using the existing implementation, an asynchronous function to wikify
a tiddler goes like this:

- Initialise a WikiStore object
- Asynchronously load the tiddler into the wikistore
- When it's loaded, parse the tiddler to obtain a list of its
dependencies (this is a synchronous operation)
- Loop back to recursively load the dependent tiddlers
- Call the store.renderTiddler() function to obtain an HTML rendering
of the tiddler, which is also a synchronous operation


This is quite similar to what twikifier does, the differences coming
about mainly because twikifier is accepting requests for rendering over
a unix domain socket:

* on the socket accept a string which is
** the current collection (bag or recipe in which the tiddler lives)
** the text of that tiddler
** the cookie of the current user (in case the bag or recipe needs
   auth to access the collection)
* if the text has a macro, load the skinny JSON 
** make a store with tiddlers without text (supporting timeline

   style macros, <> type transclusion is done afterwards,
   recursively from the other side of the socket)
* call wikify on the text faking in a dom thing from jsdom

The part of your description that is most interesting is the
dependency resolution.


The WikiStore object is the equivalent of the TiddlyWiki() object in
the old code; it's a collection of tiddlers. The Tiddler object is
intentionally simple: just an immutable collection of fields. The
WikiStore also needs be configured with the parsers and macros that
you want to use. I'm currently using a module called App.js to
centralise the WikiStore configuration steps for both browser and
node.js configurations of the code:

https://github.com/Jermolene/cook.js/blob/master/js/App.js


so:

* make a store
* register parsers
* What are tiddlerInput and tiddlerOutput?
* install macros
* addTiddler
* get its dependencies
** if null: load all tiddlers into store
** if list: load each of those tiddlers into store
* renderTiddler

That sound about right?

--
Chris Dent   http://burningchrome.com/
[...]

--
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

Congratulations on the babies. You'll soon be teaching your toddlers
about tiddlers.

For interchange of richly structured documents, a JSON format would be
quite useful, so I'd be interested to understand Pandoc's support
better.

Lots of people love Python, I think it makes a good choice.

Best wishes

Jeremy

On Tue, Jan 31, 2012 at 10:14 AM, HansBKK  wrote:
>> On Tuesday, January 31, 2012 4:43:56 PM UTC+7, Jeremy Ruston wrote:
>>
>> > I thought I remember coming across a TW plugin that handled hard return
>> > issues, doesn't that make use of  tags?
>>
>> As I've said before, I do plan to explore "fixing" the standard
>> TiddlyWiki wikifier in TW5 so that it does emit the expected  tags.
>
> I was just recalling an "in the meantime" fix - I'm sure we'll find many
> users will be using "old-school" TWs for quite some time even after TW5
> ships a stable release. . .
>
>>
>> > The absolute ideal IMO would be a core TW architecture that allowed for
>> > user
>> > choice of internally-stored syntax, with or without appropriate
>> > rendering
>> > and input assistance. Zim's author is intending to head down that road
>> > in
>> > future.
>>
>> I think that's where TW5 is. You can store tiddlers in what ever type
>> you like. The system looks for a parser that can convert each
>> particular MIME type into HTML. So, you'll be able to, for instance,
>> whip up a MarkDown parser (perhaps based on ShowDown), and then store
>
> excellent!
>
>>
>> > Second best is export capability to one or more "standard" syntaxes
>> > to support Txt2tags and/or Pandoc - I'm now leaning toward the latter,
>> > so leading candidates are extended markdown or reST/Sphinx.
>>
>> For general, interoperable export I was thinking that HTML would be
>> useful.
>
> For structured output, say DocBook as an extreme example, but anywhere you
> might want things like standardized footnotes, bibliographic citations,
> multiple end-matter hierarchical indexes etc. HTML just doesn't offer
> semantically rich enough features.
>
> You'd have to create rigid SOP rules for users to follow for the HTML to be
> consistent enough to be "upgrade converted" to the more structured formats
> like AsciiDoc or Sphinx. Everything outputs *to* HTML, that's the easy part,
> but going the other way is very difficult if you're dealing with anything
> more than a flat "sea of tiddlers".
>
> Pandoc will work equally well with markdown+its own extensions and the
> relevant subset of reST. It also uses json-based structures internally, and
> can accept these directly as input, but I believe they're not fully
> documented.
>
>>
>> > Worst case is adding a "reader" for TW-specific syntax to Pandoc, which
>> > will then be able to output to any of its dozen+ target output formats. In
>> > which case a Pandoc "writer" for txt2tags and/or Asciidoc (which I believe
>> > is in the dev version) would make things pretty complete.
>>
>> I imagine it might be useful if Pandoc were able to support TW5 wikitext.
>
> Definitely, especially if there were standardized representations for those
> features that map to the meta-structures discussed above.
>
>>
>> > My understanding is that these wouldn't be too hard for an experienced
>> > programmer. If I need to learn to program, I'm not sure if Haskell's the
>> > language to start with but they say most important is a relevant
>> > real-world
>> > project to motivate you. 8-)
>>
>> On those grounds it might be reasonable to learn JavaScript?
>
>  I've read that because of its flexibility, JS isn't the best choice as a
> first language, I was thinking Python?
>
> But to be honest I'll probably still be wishing I had the money
> (=freedom/time) to go "back to school" on my deathbed, I'm over 50 and just
> started a new family, two lovely babies. . .
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2012-01-31 Thread HansBKK


>
> On Tuesday, January 31, 2012 4:43:56 PM UTC+7, Jeremy Ruston wrote:
>
> I thought I remember coming across a TW plugin that handled hard return
> > issues, doesn't that make use of  tags?
>
> As I've said before, I do plan to explore "fixing" the standard
> TiddlyWiki wikifier in TW5 so that it does emit the expected  tags.
>
I was just recalling an "in the meantime" fix - I'm sure we'll find many 
users will be using "old-school" TWs for quite some time even after TW5 
ships a stable release. . .
 

> > The absolute ideal IMO would be a core TW architecture that allowed for 
> user
> > choice of internally-stored syntax, with or without appropriate rendering
> > and input assistance. Zim's author is intending to head down that road in
> > future.
>
> I think that's where TW5 is. You can store tiddlers in what ever type
> you like. The system looks for a parser that can convert each
> particular MIME type into HTML. So, you'll be able to, for instance,
> whip up a MarkDown parser (perhaps based on ShowDown), and then store
>
excellent!
 

> > Second best is export capability to one or more "standard" syntaxes 
> to support Txt2tags and/or Pandoc - I'm now leaning toward the latter, 
> so leading candidates are extended markdown or reST/Sphinx.
>
> For general, interoperable export I was thinking that HTML would be useful.
>
For structured output, say DocBook as an extreme example, but anywhere you 
might want things like standardized footnotes, bibliographic citations, 
multiple end-matter hierarchical indexes etc. HTML just doesn't offer 
semantically rich enough features.

You'd have to create rigid SOP rules for users to follow for the HTML to be 
consistent enough to be "upgrade converted" to the more structured formats 
like AsciiDoc or Sphinx. Everything outputs *to* HTML, that's the easy 
part, but going the other way is very difficult if you're dealing with 
anything more than a flat "sea of tiddlers".

Pandoc will work equally well with markdown+its own extensions and the 
relevant subset of reST. It also uses json-based structures internally, and 
can accept these directly as input, but I believe they're not fully 
documented.
 

> > Worst case is adding a "reader" for TW-specific syntax to Pandoc, which 
> will then be able to output to any of its dozen+ target output formats. In 
> which case a Pandoc "writer" for txt2tags and/or Asciidoc (which I believe 
> is in the dev version) would make things pretty complete.
>
> I imagine it might be useful if Pandoc were able to support TW5 wikitext.
>
Definitely, especially if there were standardized representations for those 
features that map to the meta-structures discussed above.
 

> > My understanding is that these wouldn't be too hard for an experienced
> > programmer. If I need to learn to program, I'm not sure if Haskell's the
> > language to start with but they say most important is a relevant 
> real-world
> > project to motivate you. 8-)
>
> On those grounds it might be reasonable to learn JavaScript?
>
 I've read that because of its flexibility, JS isn't the best choice as a 
first language, I was thinking Python?

But to be honest I'll probably still be wishing I had the money 
(=freedom/time) to go "back to school" on my deathbed, I'm over 50 and just 
started a new family, two lovely babies. . .

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/tiddlywiki/-/GmIvrdzDRy8J.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

> I thought I remember coming across a TW plugin that handled hard return
> issues, doesn't that make use of  tags?

As I've said before, I do plan to explore "fixing" the standard
TiddlyWiki wikifier in TW5 so that it does emit the expected  tags.

> The absolute ideal IMO would be a core TW architecture that allowed for user
> choice of internally-stored syntax, with or without appropriate rendering
> and input assistance. Zim's author is intending to head down that road in
> future.

I think that's where TW5 is. You can store tiddlers in what ever type
you like. The system looks for a parser that can convert each
particular MIME type into HTML. So, you'll be able to, for instance,
whip up a MarkDown parser (perhaps based on ShowDown), and then store
all your stuff in "text/x-web-markdown" (if that is the right mime
type; it seems contentious). Of course, MarkDown would need to have
macros added somehow.

> Second best is export capability to one or more "standard" syntaxes to
> support Txt2tags and/or Pandoc - I'm now leaning toward the latter, so
> leading candidates are extended markdown or reST/Sphinx.

For general, interoperable export I was thinking that HTML would be useful.

> Worst case is adding a "reader" for TW-specific syntax to Pandoc, which will
> then be able to output to any of its dozen+ target output formats. In which
> case a Pandoc "writer" for txt2tags and/or Asciidoc (which I believe is in
> the dev version) would make things pretty complete.

I imagine it might be useful if Pandoc were able to support TW5 wikitext.

> My understanding is that these wouldn't be too hard for an experienced
> programmer. If I need to learn to program, I'm not sure if Haskell's the
> language to start with but they say most important is a relevant real-world
> project to motivate you. 8-)

On those grounds it might be reasonable to learn JavaScript?

best wishes

Jeremy

>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/tiddlywiki/-/XXVlyMY7oAIJ.
>
> To post to this group, send email to tiddlywiki@googlegroups.com.
> To unsubscribe from this group, send email to
> tiddlywiki+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/tiddlywiki?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2012-01-30 Thread HansBKK

On Tuesday, January 31, 2012 6:59:59 AM UTC+7, PMario wrote:
>
> I did test pandoc some time ago. FND posted some usefull links [1]. I 
> didn't want to use it with markdown, but with TW syntax. So I needed to 
> render HTML output (using TiddlySpace twikifyer) and feed it to pandoc. The 
> problem is that there are no paragraph  tags in TW HTML output, which 
> makes stuff complicated for propper PDF generation. 
>
> So I stopped testing. 
>

I thought I remember coming across a TW plugin that handled hard return 
issues, doesn't that make use of  tags?

The absolute ideal IMO would be a core TW architecture that allowed for 
user choice of internally-stored syntax, with or without appropriate 
rendering and input assistance. Zim's author is intending to head down that 
road in future.

Second best is export capability to one or more "standard" syntaxes to 
support Txt2tags and/or Pandoc - I'm now leaning toward the latter, so 
leading candidates are extended markdown or reST/Sphinx.

Worst case is adding a "reader" for TW-specific syntax to Pandoc, which 
will then be able to output to any of its dozen+ target output formats. In 
which case a Pandoc "writer" for txt2tags and/or Asciidoc (which I believe 
is in the dev version) would make things pretty complete.

My understanding is that these wouldn't be too hard for an experienced 
programmer. If I need to learn to program, I'm not sure if Haskell's the 
language to start with but they say most important is a relevant real-world 
project to motivate you. 8-) 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/tiddlywiki/-/XXVlyMY7oAIJ.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2012-01-30 Thread PMario

I did test pandoc some time ago. FND posted some usefull links [1]. I
didn't want to use it with markdown, but with TW syntax. So I needed
to render HTML output (using TiddlySpace twikifyer) and feed it to
pandoc. The problem is that there are no paragraph  tags in TW HTML
output, which makes stuff complicated for propper PDF generation.

So I stopped testing.

[1] 
http://fnd.tiddlyspace.com/#3283b3cf0e9782f4d707825a80224086%2068ecefe7437c53003d5a8045bd812940

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2012-01-30 Thread HansBKK

On Monday, January 30, 2012 9:51:07 PM UTC+7, Jeremy Ruston wrote:
>
> Pandoc is very interesting, thanks for pointing it out.
>
> The big difference I notice with these tools is that they are usually
> designed for batch processing. With TiddlyWiki, a big part of the
> challenge of rendering wikitext to HTML is to be able to efficiently
> selectively update the DOM nodes that need regenerating when an
> underlying data item changes. 
>

Keep in mind the syntax aspect is separate from any software that may 
leverage it, so although the Pandoc software may be written in Haskell, if 
Zim ends up supporting that (markdown+pandoc) syntax, Jaap will be writing 
code from scratch in Python to do so.

The author of Pandoc has also written Gitit , an 
interactive wiki that can use multiple DVCS's as the storage back-end, but 
it's the syntax of the plain-text "sea of nodes" that gives it the ability 
to be transformed into a website, ebook, pretty PDF or dead-trees via 
LaTeX. . .

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/tiddlywiki/-/ktb3vfJS5kcJ.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2012-01-30 Thread Jeremy Ruston

Pandoc is very interesting, thanks for pointing it out.

The big difference I notice with these tools is that they are usually
designed for batch processing. With TiddlyWiki, a big part of the
challenge of rendering wikitext to HTML is to be able to efficiently
selectively update the DOM nodes that need regenerating when an
underlying data item changes. This is necessary for the familiar
interactive features to work properly (eg, an italicised link to a
missing tiddler automatically changing to a bold, non-italic link when
the tiddler is created). With TW5 I'm hoping I've been able to do that
in a way that will still be familiar to people who've worked on other
text processing systems.

Cheers

Jeremy

On Sat, Jan 28, 2012 at 6:28 AM, HansBKK  wrote:
> On Saturday, January 28, 2012 10:57:59 AM UTC+7, dave wrote:
>>
>> Yeah, that implements a txt2tags formatter in tiddly form. If you need
>> javascript code, that contains a mess of regex's to implement txt2tags.
>>  There are a few gaps in the syntax, and it borrows some tiddlywiki syntax
>> (I copied the <> syntax as txt2tags has no concept of that feature).
>> I've coincidentally been fixing some bugs and am posting an update over the
>> weekend.
>>
>> > http://wiki.txt2tags.org/index.php/Main/TiddlywikiPlugin
>
>
> And may be wildly irrelevant at this point, but note that the developer of
> Zim (desktop wiki + some calendar+to-do) has set a goal of transitioning
> from supporting only its proprietary syntax (very close to DokuWiki's) to
> the Pandoc flavor of extended Markdown. To start with he's writing an export
> routine, but plans to support it internally in the future, perhaps with
> other more open syntax choices as well.
>
> I've found that Pandoc is *extremely* actively developed, much more so than
> txt2tags, and another big advantage is that it supports two-way transforms
> for many of its supported formats, whereas your plugin is the *only* example
> I've come across of anything going *to* txt2tags syntax.
>
> For those interested in this stuff, I'm maintaining a pivot-table matrix in
> gDocs
>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/tiddlywiki/-/HFphD2Rv1poJ.
>
> To post to this group, send email to tiddlywiki@googlegroups.com.
> To unsubscribe from this group, send email to
> tiddlywiki+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/tiddlywiki?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2012-01-27 Thread HansBKK

On Saturday, January 28, 2012 10:57:59 AM UTC+7, dave wrote:
>
> Yeah, that implements a txt2tags formatter in tiddly form. If you need 
> javascript code, that contains a mess of regex's to implement txt2tags. 
>  There are a few gaps in the syntax, and it borrows some tiddlywiki syntax 
> (I copied the <> syntax as txt2tags has no concept of that feature). 
> I've coincidentally been fixing some bugs and am posting an update over the 
> weekend. 
>
> > http://wiki.txt2tags.org/index.php/Main/TiddlywikiPlugin

And may be wildly irrelevant at this point, but note that the developer of Zim 
(desktop wiki + some calendar+to-do) has set a goal 
of transitioning from supporting only its proprietary syntax (very close to 
DokuWiki's) to the Pandoc flavor of 
extended Markdown. To start with he's writing an export routine, but plans 
to support it internally in the future, perhaps with other more open syntax 
choices as well.

I've found that Pandoc is *extremely* actively developed, much more so than 
txt2tags, and another big advantage is that it supports two-way transforms 
for many of its supported formats, whereas your plugin is the *only* 
example I've come across of anything going *to* txt2tags syntax.

For those interested in this stuff, I'm maintaining a pivot-table matrix in 
gDocs

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/tiddlywiki/-/HFphD2Rv1poJ.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2012-01-27 Thread dave

Yeah, that implements a txt2tags formatter in tiddly form. If you need
javascript code, that contains a mess of regex's to implement
txt2tags.  There are a few gaps in the syntax, and it borrows some
tiddlywiki syntax (I copied the <> syntax as txt2tags has no
concept of that feature). I've coincidentally been fixing some bugs
and am posting an update over the weekend.

On Dec 23 2011, 9:37 pm, HansBKK  wrote:
> I realize the core group may not be interested, but I (re-)discovered this
> in my wanderings, so posted here to help future googlers
>
> http://wiki.txt2tags.org/index.php/Main/TiddlywikiPlugin

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2012-01-27 Thread Jeremy Ruston

> Hey Jeremy, what's the status of your wikifier. It's it play-with-able
> in a standalone kind of way? If so where and how?

With some caveats I think this is probably a good time to start
investigating. I think the code is capable of what you need, but it's
still rather in flux, and so can be changed in response to your
requirements.

The code is still in the wrong repo:

https://github.com/Jermolene/cook.js

The main issues that might affect the decision about timing adoption:

- The new code doesn't currently implement all of the core TiddlyWiki
macros. I've focussed on the structural ones (like view, story, and
tiddler) so far. I don't see any particular obstacles to hoiking the
remainder in.
- The new code doesn't yet properly sanitise HTML and JavaScript
content within tiddlers. In the case of JavaScript, it gets halfway
there: evaluated macro parameters are parsed and recompiled, giving an
opportunity to check for e.g. access to dangerous globals, but this
doesn't happen at the moment
- There is not yet support for sections and slices. This is next on my
list, and I think probably necessary
- There's probably other limitations; I've been focussing on getting a
solid architecture for the representation transformation engine at the
heart of TiddlyWiki
- Error handling is probably a bit inadequate

> The twikifier code used with TiddlySpace is proving to be a bit heavy
> (cpu-use-wise) and it would be useful to experiment with something a
> bit more modern and hopefully more responsive to tweaking, inspection
> and improvement.

Throughout the development I've kept in mind your comment last year
that you'd like wikification to be exposed as an asynchronous
function, presumably with a signature something like this:

store.wikify(tiddler,callback)

And then have the callback invoked with an error code and the HTML
representation of the tiddler.

It turns out that that style interface isn't ideal for the client
code. In the browser, the asynchronicity is around async events
triggering changes to the values of tiddlers which trigger highly
selective changes to the DOM. The actual wikification process is
synchronous; in the client if we're waiting for a tiddler to load from
the server we'd generally want attempts to transclude that tiddler to
succeed, but to render a spinner. The eventual arrival of the tiddler
automatically triggers the DOM processing to refresh the tiddler that
did the transcluding.

So, I've tried to arrive at an implementation that supports both
approaches. One of the hallmarks of the design is the aggressive use
of caching to support efficient selective updating of the DOM. I think
a big area of discussion around this integration is how we can ensure
that our respective caching strategies work well together.

Using the existing implementation, an asynchronous function to wikify
a tiddler goes like this:

- Initialise a WikiStore object
- Asynchronously load the tiddler into the wikistore
- When it's loaded, parse the tiddler to obtain a list of its
dependencies (this is a synchronous operation)
- Loop back to recursively load the dependent tiddlers
- Call the store.renderTiddler() function to obtain an HTML rendering
of the tiddler, which is also a synchronous operation

The WikiStore object is the equivalent of the TiddlyWiki() object in
the old code; it's a collection of tiddlers. The Tiddler object is
intentionally simple: just an immutable collection of fields. The
WikiStore also needs be configured with the parsers and macros that
you want to use. I'm currently using a module called App.js to
centralise the WikiStore configuration steps for both browser and
node.js configurations of the code:

https://github.com/Jermolene/cook.js/blob/master/js/App.js

You'd basically need to do everything that isn't in one of the
if(isBrowser) conditionals.

Loading a new tiddler into the store is easy:

store.addTiddler(new Tiddler({title: "HelloThere", text: "Some text",
type: "text/x-tiddlywiki"}));

Getting the list of dependencies for a tiddler is:

store.parseTiddler(title).dependencies

It will either be an array of tiddler title strings, or the special
value null. This means that the tiddler is dependent on all the other
tiddlers it can get it's hands one - for example, using <>
within a tiddler will set the dependencies to null. Another issue we
might need to look at is that there is currently no distinction
between being dependent on a tiddler because we transclude it, or just
because we link to it. You might prefer to avoid loading tiddlers that
are only linked.

Rendering the tiddler in HTML is:

store.renderTiddler("text/html",title);

You can also render the specified tiddler as though it were another
one; this is useful for rendering tiddlers as templates. For example:

store.renderTiddler("text/html","MyTemplate","HelloThere");

This example would render the tiddler HelloThere using the tiddler
MyTemplate as a template. So things like <> within
MyTemplate would render the tiddler

[tw] Re: TiddlyWiki Development News

2012-01-26 Thread cdent

On Dec 14 2011, 12:10 pm, cdent  wrote:
> > The reason why this is a big deal is that it brings all the TiddlyWiki
> > developments together. We've got a build tool that can uniformly build
> > old and new TiddlyWikis. We've got a single wikifier code base that
> > can be used on the server, in the browser and as a command line tool.
>
> Very curious to see the wikifier in action. The twikifier code works
> relatively well, but is not ideal, and is fairly inscrutable.

Hey Jeremy, what's the status of your wikifier. It's it play-with-able
in a standalone kind of way? If so where and how?

The twikifier code used with TiddlySpace is proving to be a bit heavy
(cpu-use-wise) and it would be useful to experiment with something a
bit more modern and hopefully more responsive to tweaking, inspection
and improvement.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2011-12-23 Thread HansBKK

I realize the core group may not be interested, but I (re-)discovered this 
in my wanderings, so posted here to help future googlers

http://wiki.txt2tags.org/index.php/Main/TiddlywikiPlugin

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/tiddlywiki/-/-CNVNFCAuYIJ.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2011-12-22 Thread Martin Budden

Given Jeremy's statement "I'd be interested in trying to make
TiddlyWiki5's format compatible with WikiCreole, but only if it can be
done without substantially impacting existing texts."

I've started a new discussion on this topic. I think it is certainly
possible to make TW more compatible with WikiCreole.

Martin

On 17 December 2011 21:07, rakugo  wrote:
> I too would like to see adoption of a standard format.
>
> I'd assume that like existing TiddlyWiki one could swap in/out
> syntaxes (but probably even more easily) so I could imagine supporting
> a plugin to help with this transition.
>
> I would assume it would be easy to convert from one format to another,
> since TiddlyWiki markup can be converted to html then from that into
> WikiCreole. I could imagine a transition tool that takes an old
> TiddlyWiki and converts it into a new TiddlyWiki.
>
> On Dec 17, 5:21 am, HansBKK  wrote:
>> On Friday, December 16, 2011 9:55:25 PM UTC+7, Jeremy Ruston wrote:
>>
>> > WikiCreole is interesting. I hadn't seen the amendments section. I'd be
>> > interested in trying to make TiddlyWiki5's format compatible with
>> > WikiCreole, but only if it can be done without substantially impacting
>> > existing texts.
>>
>> IMO **Any** standardized syntax would be better than keeping TW's unique.
>> That way at least there's a way to get plugged into a toolchain down the
>> road without having to write a specific converter template/parser for TW.
>>
>> Converting to or from the "standardX" markup used by TW is then more than
>> likely to be supported by converter/parser engines like Pandocs and
>> docutils as they continue to evolve, or at least if a new
>> "tangler/template" whatever needs to be written for it that's useful to the
>> whole ecosystem, not just the one community, and therefore more likely to
>> be supported and maintained over time.
>>
>>  The primary area where backwards compatibility is a concern is the> 
>> handling of paragraphs. TiddlyWiki's use of  tags is just plain wrong,
>> > and I think it's worth taking a minor compatibility hit in order to gain
>> > the advantage of producing semantically proper HTML, which is generally
>> > much more useful.
>>
>> > The reason that I'm so keen on backwards compatibility is that there is a
>> > lot of text out there in TiddlyWiki format; much of it on
>> > people's hard drives. I like the idea of enhancing the value of that
>> > existing investment by making it super easy for existing users to take
>> > advantage of the new features of the new software.
>>
>> That goal is of course essential, but I would think it wouldn't be that
>> hard (easy for me to say not having a clue about programming) for the TW
>> code at the point where a tiddler is first being created to parse the data,
>> recognize it's TW4syntax (by the paragraph mark?) and do a one-time
>> conversion to the TW5syntax.
>>
>> If you're fixing the paragraph syntax you'll have to do something like that
>> to accomplish the above goal anyway.
>>
>> On Thursday, December 15, 2011 4:22:51 PM UTC+7, Jeremy Ruston wrote:
>> > I've been doing a lot of research and playing around in the "tools that
>> > transform markup" space recently, and would **implore** you to consider
>> > choosing one of the more mainstream cross-platform syntaxes rather than
>> > re-implementing a proprietary TWmarkup, even if it may be "based on" one of
>> > them.
>>
>> Sorry for the use of the word "proprietary", very rude in the FOSS world I
>> know - how about "unique" syntax?
>>
>> > the idea of pluggable parsers and renderers, so that it is possible to
>> > adopt other formats, and intermingle them and so on. If you can find a
>> > JavaScript parser for it, then hopefully you'll be able to use it.
>>
>> I think this would only work from a user's POV if the option of using the
>> other syntax were available right out of the gate, just flip a switch in
>> the config and bang it works with "standardX" markup. Just making the
>> architecture theoretically available for future plug-in authors is better
>> than not having that but. . .
>>
>> >> Adopting MarkDown in its entirety is a bit troublesome from my
>>
>> perspective; it's not very formally defined
>>
>> I don't like it myself, but sometimes defacto standards offering a lot of
>> cross-program interoperability are better than perfect implementations that
>> remain on the shelf like museum displays.
>>
>> > I need JavaScript code, obviously. There may be bits and pieces worth
>> > taking from those projects, but a brief glance shows that they take in
>> > concerns that don't entirely match TiddlyWiki, so I don't see a way to
>> > wholesale adopt those syntaxes.
>>
>> I don't understand this - the specification for a syntax is one thing, a
>> given bit of code that uses that syntax to do convert/render from the
>> plaintext to whatever can/should be in whatever language is used by the
>> tool.
>>
>> The whole point I'm getting at is to be able to keep our data in a
>> canonical

[tw] Re: TiddlyWiki Development News

2011-12-17 Thread rakugo

I too would like to see adoption of a standard format.

I'd assume that like existing TiddlyWiki one could swap in/out
syntaxes (but probably even more easily) so I could imagine supporting
a plugin to help with this transition.

I would assume it would be easy to convert from one format to another,
since TiddlyWiki markup can be converted to html then from that into
WikiCreole. I could imagine a transition tool that takes an old
TiddlyWiki and converts it into a new TiddlyWiki.

On Dec 17, 5:21 am, HansBKK  wrote:
> On Friday, December 16, 2011 9:55:25 PM UTC+7, Jeremy Ruston wrote:
>
> > WikiCreole is interesting. I hadn't seen the amendments section. I'd be
> > interested in trying to make TiddlyWiki5's format compatible with
> > WikiCreole, but only if it can be done without substantially impacting
> > existing texts.
>
> IMO **Any** standardized syntax would be better than keeping TW's unique.
> That way at least there's a way to get plugged into a toolchain down the
> road without having to write a specific converter template/parser for TW.
>
> Converting to or from the "standardX" markup used by TW is then more than
> likely to be supported by converter/parser engines like Pandocs and
> docutils as they continue to evolve, or at least if a new
> "tangler/template" whatever needs to be written for it that's useful to the
> whole ecosystem, not just the one community, and therefore more likely to
> be supported and maintained over time.
>
>  The primary area where backwards compatibility is a concern is the> handling 
> of paragraphs. TiddlyWiki's use of  tags is just plain wrong,
> > and I think it's worth taking a minor compatibility hit in order to gain
> > the advantage of producing semantically proper HTML, which is generally
> > much more useful.
>
> > The reason that I'm so keen on backwards compatibility is that there is a
> > lot of text out there in TiddlyWiki format; much of it on
> > people's hard drives. I like the idea of enhancing the value of that
> > existing investment by making it super easy for existing users to take
> > advantage of the new features of the new software.
>
> That goal is of course essential, but I would think it wouldn't be that
> hard (easy for me to say not having a clue about programming) for the TW
> code at the point where a tiddler is first being created to parse the data,
> recognize it's TW4syntax (by the paragraph mark?) and do a one-time
> conversion to the TW5syntax.
>
> If you're fixing the paragraph syntax you'll have to do something like that
> to accomplish the above goal anyway.
>
> On Thursday, December 15, 2011 4:22:51 PM UTC+7, Jeremy Ruston wrote:
> > I've been doing a lot of research and playing around in the "tools that
> > transform markup" space recently, and would **implore** you to consider
> > choosing one of the more mainstream cross-platform syntaxes rather than
> > re-implementing a proprietary TWmarkup, even if it may be "based on" one of
> > them.
>
> Sorry for the use of the word "proprietary", very rude in the FOSS world I
> know - how about "unique" syntax?
>
> > the idea of pluggable parsers and renderers, so that it is possible to
> > adopt other formats, and intermingle them and so on. If you can find a
> > JavaScript parser for it, then hopefully you'll be able to use it.
>
> I think this would only work from a user's POV if the option of using the
> other syntax were available right out of the gate, just flip a switch in
> the config and bang it works with "standardX" markup. Just making the
> architecture theoretically available for future plug-in authors is better
> than not having that but. . .
>
> >> Adopting MarkDown in its entirety is a bit troublesome from my
>
> perspective; it's not very formally defined
>
> I don't like it myself, but sometimes defacto standards offering a lot of
> cross-program interoperability are better than perfect implementations that
> remain on the shelf like museum displays.
>
> > I need JavaScript code, obviously. There may be bits and pieces worth
> > taking from those projects, but a brief glance shows that they take in
> > concerns that don't entirely match TiddlyWiki, so I don't see a way to
> > wholesale adopt those syntaxes.
>
> I don't understand this - the specification for a syntax is one thing, a
> given bit of code that uses that syntax to do convert/render from the
> plaintext to whatever can/should be in whatever language is used by the
> tool.
>
> The whole point I'm getting at is to be able to keep our data in a
> canonical format as plain text, for transfer to whatever "container", files
> in folders on whatever storage medium, database, CMS, wiki, and easily get
> it out there as EPUB, static HTML, DocBook whatever. Obviously there isn't
> currently such a beast with parsers/converters/renderers etc implemented in
> every mainstream language, or everyone would be using it. I'm just doing my
> bit to advocate that one of the cool tools I use help move in that
> desirable dir

Re: [tw] Re: TiddlyWiki Development News

2011-12-16 Thread HansBKK

On Friday, December 16, 2011 9:55:25 PM UTC+7, Jeremy Ruston wrote: 
>
>
> WikiCreole is interesting. I hadn't seen the amendments section. I'd be 
> interested in trying to make TiddlyWiki5's format compatible with 
> WikiCreole, but only if it can be done without substantially impacting 
> existing texts.
>

IMO **Any** standardized syntax would be better than keeping TW's unique. 
That way at least there's a way to get plugged into a toolchain down the 
road without having to write a specific converter template/parser for TW.

Converting to or from the "standardX" markup used by TW is then more than 
likely to be supported by converter/parser engines like Pandocs and 
docutils as they continue to evolve, or at least if a new 
"tangler/template" whatever needs to be written for it that's useful to the 
whole ecosystem, not just the one community, and therefore more likely to 
be supported and maintained over time.

 The primary area where backwards compatibility is a concern is the 
> handling of paragraphs. TiddlyWiki's use of  tags is just plain wrong, 
> and I think it's worth taking a minor compatibility hit in order to gain 
> the advantage of producing semantically proper HTML, which is generally 
> much more useful.
>
> The reason that I'm so keen on backwards compatibility is that there is a 
> lot of text out there in TiddlyWiki format; much of it on
> people's hard drives. I like the idea of enhancing the value of that 
> existing investment by making it super easy for existing users to take 
> advantage of the new features of the new software.
>
That goal is of course essential, but I would think it wouldn't be that 
hard (easy for me to say not having a clue about programming) for the TW 
code at the point where a tiddler is first being created to parse the data, 
recognize it's TW4syntax (by the paragraph mark?) and do a one-time 
conversion to the TW5syntax.

If you're fixing the paragraph syntax you'll have to do something like that 
to accomplish the above goal anyway.

On Thursday, December 15, 2011 4:22:51 PM UTC+7, Jeremy Ruston wrote:

> I've been doing a lot of research and playing around in the "tools that 
> transform markup" space recently, and would **implore** you to consider 
> choosing one of the more mainstream cross-platform syntaxes rather than 
> re-implementing a proprietary TWmarkup, even if it may be "based on" one of 
> them.

Sorry for the use of the word "proprietary", very rude in the FOSS world I 
know - how about "unique" syntax? 

> the idea of pluggable parsers and renderers, so that it is possible to 
> adopt other formats, and intermingle them and so on. If you can find a
> JavaScript parser for it, then hopefully you'll be able to use it.
>
I think this would only work from a user's POV if the option of using the 
other syntax were available right out of the gate, just flip a switch in 
the config and bang it works with "standardX" markup. Just making the 
architecture theoretically available for future plug-in authors is better 
than not having that but. . .

>> Adopting MarkDown in its entirety is a bit troublesome from my 
perspective; it's not very formally defined

I don't like it myself, but sometimes defacto standards offering a lot of 
cross-program interoperability are better than perfect implementations that 
remain on the shelf like museum displays.

> I need JavaScript code, obviously. There may be bits and pieces worth 
> taking from those projects, but a brief glance shows that they take in 
> concerns that don't entirely match TiddlyWiki, so I don't see a way to 
> wholesale adopt those syntaxes.
>
I don't understand this - the specification for a syntax is one thing, a 
given bit of code that uses that syntax to do convert/render from the 
plaintext to whatever can/should be in whatever language is used by the 
tool. 

The whole point I'm getting at is to be able to keep our data in a 
canonical format as plain text, for transfer to whatever "container", files 
in folders on whatever storage medium, database, CMS, wiki, and easily get 
it out there as EPUB, static HTML, DocBook whatever. Obviously there isn't 
currently such a beast with parsers/converters/renderers etc implemented in 
every mainstream language, or everyone would be using it. I'm just doing my 
bit to advocate that one of the cool tools I use help move in that 
desirable direction.

If TiddlyWiki can help facilitate that goal it's that much more valuable as 
one of those platform choices, whether used as a source-file editor or 
target publishing format for output from other parts of the toolchain.

> IMO the key is to **not** pick and choose bits and pieces, but to take on 
> an entire **syntax spec as a whole**.
>

As I say, the ability to have pluggable parsers and renderers should give 
> you the capabilities you want. For you, the native TiddlyWiki format might 
> just be what gets used for the application plumbing, with all your content 
> being in other formats.

[tw] Re: TiddlyWiki Development News

2011-12-16 Thread David Gifford

Thanks for the reassurance, Jeremy!

Dave

On Dec 16, 8:55 am, Jeremy Ruston  wrote:
> There will be a native wiki text processor in TiddlyWiki 5, and my
> plan is that it should be as compatible as possible with existing
> TiddlyWiki wikitext. I do want to take the opportunity to extend the
> format, though, which I think can mostly be done without breaking
> backwards compatibility.
>
> WikiCreole is interesting. I hadn't seen the amendments section. I'd
> be interested in trying to make TiddlyWiki5's format compatible with
> WikiCreole, but only if it can be done without substantially impacting
> existing texts.
>
> The primary area where backwards compatibility is a concern is the
> handling of paragraphs. TiddlyWiki's use of  tags is just plain
> wrong, and I think it's worth taking a minor compatibility hit in
> order to gain the advantage of producing semantically proper HTML,
> which is generally much more useful.
>
> The reason that I'm so keen on backwards compatibility is that there
> is a lot of text out there in TiddlyWiki format; much of it on
> people's hard drives. I like the idea of enhancing the value of that
> existing investment by making it super easy for existing users to take
> advantage of the new features of the new software.
>
> Best wishes
>
> Jeremy
>
>
>
>
>
>
>
> On Fri, Dec 16, 2011 at 2:23 PM, David Gifford  wrote:
> > Now I am afraid to do anything with TiddlyWiki until the new version
> > comes along, to see whether you all are going to change the wikitext
> > to some other format...
>
> > Kudos to you, Jeremy, for taking time to fiddle with the tiddlers
> > again. I will be looking forward to what comes of the cooks and nodes.
>
> > Dave
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "TiddlyWiki" group.
> > To post to this group, send email to tiddlywiki@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > tiddlywiki+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/tiddlywiki?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2011-12-16 Thread Ben Gillies

On Fri, Dec 16, 2011 at 2:23 PM, David Gifford  wrote:
> Now I am afraid to do anything with TiddlyWiki until the new version
> comes along, to see whether you all are going to change the wikitext
> to some other format...

I don't see why we can't support both a new and an old wikitext syntax
(along with others), as Jeremy suggests.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2011-12-16 Thread Jeremy Ruston

There will be a native wiki text processor in TiddlyWiki 5, and my
plan is that it should be as compatible as possible with existing
TiddlyWiki wikitext. I do want to take the opportunity to extend the
format, though, which I think can mostly be done without breaking
backwards compatibility.

WikiCreole is interesting. I hadn't seen the amendments section. I'd
be interested in trying to make TiddlyWiki5's format compatible with
WikiCreole, but only if it can be done without substantially impacting
existing texts.

The primary area where backwards compatibility is a concern is the
handling of paragraphs. TiddlyWiki's use of  tags is just plain
wrong, and I think it's worth taking a minor compatibility hit in
order to gain the advantage of producing semantically proper HTML,
which is generally much more useful.

The reason that I'm so keen on backwards compatibility is that there
is a lot of text out there in TiddlyWiki format; much of it on
people's hard drives. I like the idea of enhancing the value of that
existing investment by making it super easy for existing users to take
advantage of the new features of the new software.

Best wishes

Jeremy

On Fri, Dec 16, 2011 at 2:23 PM, David Gifford  wrote:
> Now I am afraid to do anything with TiddlyWiki until the new version
> comes along, to see whether you all are going to change the wikitext
> to some other format...
>
> Kudos to you, Jeremy, for taking time to fiddle with the tiddlers
> again. I will be looking forward to what comes of the cooks and nodes.
>
> Dave
>
> --
> You received this message because you are subscribed to the Google Groups 
> "TiddlyWiki" group.
> To post to this group, send email to tiddlywiki@googlegroups.com.
> To unsubscribe from this group, send email to 
> tiddlywiki+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/tiddlywiki?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2011-12-16 Thread David Gifford

Now I am afraid to do anything with TiddlyWiki until the new version
comes along, to see whether you all are going to change the wikitext
to some other format...

Kudos to you, Jeremy, for taking time to fiddle with the tiddlers
again. I will be looking forward to what comes of the cooks and nodes.

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2011-12-15 Thread PMario

Hi folks,

I did re/search a bit for nicely documented wikitext grammers lately.
I only found one for wiki creole. The good thing is, that it imo is a
good "subset" of the TW grammar.

There is a short article from:
> Authors: Martin Junghans, Dirk Riehle, Rama Gurram, Matthias Kaiser, Mário
> Lopes, Umit Yalcinalp
at: http://dirkriehle.com/2008/07/19/a-grammar-for-standardized-wiki-markup/

that links to: (see "available as a PDF file")
http://dirkriehle.com/wp-content/uploads/2008/07/ws2008-wiki-creole-grammar-final-for-web.pdf

which talks about there intentions.
=

Searching Dirk Riehle's site a bit more I found:
http://dirkriehle.com/publications/2008-2/wiki-creole/
and
http://dirkriehle.com/wp-content/uploads/2008/01/creole10_with_extension.g

Which is a full EBNF grammar description for wiki Creole. (using some
ANTLR specific commands).

Since the source (see: creole10_with_extension.g link) is copyrighted,
I did contact Mr. Riehle to get a less restrictive license (just to be
sure). Since the creole project is CreativeCommons, I did get an
emailed permission to use the most open CC-BY -
http://creativecommons.org/licenses/by/3.0/
license to use with TW.

@Jeremy
Just linking some resources, that may be usefull.

-m

--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2011-12-15 Thread Julio

Hello all,

' hope everyone is having a good day.

Although much of this thread goes over my head, I am glad that Jeremy
is again working on Tiddliwiki. As a regular Joe, however, I would
like to state that if indeed one were to go with a syntax change I
would concur with Martin above. I would definitely be able to adapt to
the Creole syntax for the same reason he stated...it's very similar to
Tiddlywiki.

I do have a question:

* If indeed this were to be the case, can one adapt Creole yet keep
some syntax that would be "unique" to Tiddlywiki without the use of
plugins or converters?
* Or would that be too much work for development? Just trying to
educate myself here.

This probably should be discussion for another thread.
I thought I'd just throw the question out there while it's still fresh
in my mind.


Thanks all,

Julio


On Dec 15, 6:15 am, Martin Budden  wrote:
> I concur with HansBKK that you should adopt a standard wiki markup for
> TW 5. I differ from in that I think you should adopt WikiCreole see:
>
> http://www.wikicreole.org/wiki/Creole1.0
> andhttp://www.wikicreole.org/wiki/CreoleAdditions
>
> The main reason for this recommendation is the WikiCreole markup is
> *very* similar to TW markup. The main differences being the handling
> of bold, headings and links. WikiCreole even recommends using double
> angle brackets for plugins.
>
> Since TW 5 is going to break compatibility, then I think it should
> also take the opportunity to move to a standard wiki format. I know
> text compatibility and code compatibility are different things, but
> nevertheless I believe this is the correct way forward.
>
> Note TW 5 could support standard TW wikiformat using a plugin, and
> also could provide a converter so that people can easily move their
> text from TW format to WikiCreole format. Since the formats are so
> similar, conversion would be fairly straightforward.
>
> Martin
>
> On 15 December 2011 09:22, Jeremy Ruston  wrote:
>
>
>
>
>
>
>
> >> I've been doing a lot of research and playing around in the "tools
> >> that transform markup" space recently, and would **implore** you to
> >> consider choosing one of the more mainstream cross-platform syntaxes
> >> rather than re-implementing a proprietary TWmarkup, even if it may be
> >> "based on" one of them.
>
> > The primary constraint I am embracing is to retain compatibility as
> > far as possible with existing TiddlyWIki markup. I think that that
> > rules out the wholesale adoption of a standard format - for instance,
> > TiddlyWiki gets [[pretty|links]] the wrong way round from most wikis.
>
> > To get around the limitations imposed by that constraint, we have the
> > idea of pluggable parsers and renderers, so that it is possible to
> > adopt other formats, and intermingle them and so on. If you can find a
> > JavaScript parser for it, then hopefully you'll be able to use it.
>
> >> Markdown is a popular choice, lots of active development in the
> >> Pandocs project - their "extensions" may be a bit proprietary, but
> >> since the focus of the whole project is interoperability, it's for a
> >> good cause.
>
> > Adopting MarkDown in its entirety is a bit troublesome from my
> > perspective; it's not very formally defined, and the only
> > implementations that I've seen are even hairier balls of regexps than
> > the old TiddlyWIki wikifier. It also lacks what I'd have thought of as
> > basic features, like tables, arguing that users should write HTML tags
> > for them.
>
> >> Other candidates are txt2tags and reST/Sphinx, with the former having
> >> the edge in a huge number of output formats currently supported. Both
> >> of these are implemented in Python, while Pandocs is Haskell, if that
> >> means anything.
>
> > I need JavaScript code, obviously. There may be bits and pieces worth
> > taking from those projects, but a brief glance shows that they take in
> > concerns that don't entirely match TiddlyWiki, so I don't see a way to
> > wholesale adopt those syntaxes.
>
> >> IMO the key is to **not** pick and choose bits and pieces, but to take
> >> on an entire **syntax spec as a whole**.
>
> > I only see that as feasible if there was a spec out there that was (a)
> > compatible with TiddlyWiki and (b) did everything that TiddlyWiki
> > needs and (c) didn't include lots of features that aren't relevant for
> > TiddlyWiki and (d) had usable JavaScript code.
>
> >> This would enable plugging TW into a standardized toolchain so that it
> >> can be either a "publishing and distribution target", along with say
> >> EPUB, AsciiDoc and HTMLhelp, or perhaps even the location where the
> >> "master source" text is edited, to then be able to output and
> >> transform to such formats. NB I consider TW's forte to be the former
> >> rather than the latter, but something like Pandocs would give the
> >> flexibility to go in either direction.
>
> > As I say, the ability to have pluggable parsers and renderers should
> > give you the capabilities you want. For y

Re: [tw] Re: TiddlyWiki Development News

2011-12-15 Thread Martin Budden

I concur with HansBKK that you should adopt a standard wiki markup for
TW 5. I differ from in that I think you should adopt WikiCreole see:

http://www.wikicreole.org/wiki/Creole1.0
and
http://www.wikicreole.org/wiki/CreoleAdditions

The main reason for this recommendation is the WikiCreole markup is
*very* similar to TW markup. The main differences being the handling
of bold, headings and links. WikiCreole even recommends using double
angle brackets for plugins.

Since TW 5 is going to break compatibility, then I think it should
also take the opportunity to move to a standard wiki format. I know
text compatibility and code compatibility are different things, but
nevertheless I believe this is the correct way forward.

Note TW 5 could support standard TW wikiformat using a plugin, and
also could provide a converter so that people can easily move their
text from TW format to WikiCreole format. Since the formats are so
similar, conversion would be fairly straightforward.

Martin

On 15 December 2011 09:22, Jeremy Ruston  wrote:
>> I've been doing a lot of research and playing around in the "tools
>> that transform markup" space recently, and would **implore** you to
>> consider choosing one of the more mainstream cross-platform syntaxes
>> rather than re-implementing a proprietary TWmarkup, even if it may be
>> "based on" one of them.
>
> The primary constraint I am embracing is to retain compatibility as
> far as possible with existing TiddlyWIki markup. I think that that
> rules out the wholesale adoption of a standard format - for instance,
> TiddlyWiki gets [[pretty|links]] the wrong way round from most wikis.
>
> To get around the limitations imposed by that constraint, we have the
> idea of pluggable parsers and renderers, so that it is possible to
> adopt other formats, and intermingle them and so on. If you can find a
> JavaScript parser for it, then hopefully you'll be able to use it.
>
>> Markdown is a popular choice, lots of active development in the
>> Pandocs project - their "extensions" may be a bit proprietary, but
>> since the focus of the whole project is interoperability, it's for a
>> good cause.
>
> Adopting MarkDown in its entirety is a bit troublesome from my
> perspective; it's not very formally defined, and the only
> implementations that I've seen are even hairier balls of regexps than
> the old TiddlyWIki wikifier. It also lacks what I'd have thought of as
> basic features, like tables, arguing that users should write HTML tags
> for them.
>
>> Other candidates are txt2tags and reST/Sphinx, with the former having
>> the edge in a huge number of output formats currently supported. Both
>> of these are implemented in Python, while Pandocs is Haskell, if that
>> means anything.
>
> I need JavaScript code, obviously. There may be bits and pieces worth
> taking from those projects, but a brief glance shows that they take in
> concerns that don't entirely match TiddlyWiki, so I don't see a way to
> wholesale adopt those syntaxes.
>
>> IMO the key is to **not** pick and choose bits and pieces, but to take
>> on an entire **syntax spec as a whole**.
>
> I only see that as feasible if there was a spec out there that was (a)
> compatible with TiddlyWiki and (b) did everything that TiddlyWiki
> needs and (c) didn't include lots of features that aren't relevant for
> TiddlyWiki and (d) had usable JavaScript code.
>
>> This would enable plugging TW into a standardized toolchain so that it
>> can be either a "publishing and distribution target", along with say
>> EPUB, AsciiDoc and HTMLhelp, or perhaps even the location where the
>> "master source" text is edited, to then be able to output and
>> transform to such formats. NB I consider TW's forte to be the former
>> rather than the latter, but something like Pandocs would give the
>> flexibility to go in either direction.
>
> As I say, the ability to have pluggable parsers and renderers should
> give you the capabilities you want. For you, the native TiddlyWiki
> format might just be what gets used for the application plumbing, with
> all your content being in other formats.
>
>> But please **please** don't just throw another proprietary wikiMarkup
>> syntax set into the mix, this is an historic opportunity to contribute
>> to the idea of "open data" in the larger ecosystem rather than
>> continuing to view tiddlers as an isolated silo needing custom coding
>> to extract inline markup semantics.
>
> I'm not planning to throw another proprietary wiki markup into the
> mix. I'm planning to improve TiddlyWiki's existing markup so that it
> isn't broken with respect to paragraphs, and to introduce some
> alternative syntaxes for some simple formatting.
>
>> Thanks in advance for at least considering these ideas. . .
>
> As I say, I think the kinds of things you're interested in are enabled
> by the parsing/rendering architecture. I would very much appreciate
> feedback on the improvements to the wikitext.
>
> Best wishes
>
> Jeremy
>
>> /rant
>>
>>

Re: [tw] Re: TiddlyWiki Development News

2011-12-15 Thread Jeremy Ruston

> I've been doing a lot of research and playing around in the "tools
> that transform markup" space recently, and would **implore** you to
> consider choosing one of the more mainstream cross-platform syntaxes
> rather than re-implementing a proprietary TWmarkup, even if it may be
> "based on" one of them.

The primary constraint I am embracing is to retain compatibility as
far as possible with existing TiddlyWIki markup. I think that that
rules out the wholesale adoption of a standard format - for instance,
TiddlyWiki gets [[pretty|links]] the wrong way round from most wikis.

To get around the limitations imposed by that constraint, we have the
idea of pluggable parsers and renderers, so that it is possible to
adopt other formats, and intermingle them and so on. If you can find a
JavaScript parser for it, then hopefully you'll be able to use it.

> Markdown is a popular choice, lots of active development in the
> Pandocs project - their "extensions" may be a bit proprietary, but
> since the focus of the whole project is interoperability, it's for a
> good cause.

Adopting MarkDown in its entirety is a bit troublesome from my
perspective; it's not very formally defined, and the only
implementations that I've seen are even hairier balls of regexps than
the old TiddlyWIki wikifier. It also lacks what I'd have thought of as
basic features, like tables, arguing that users should write HTML tags
for them.

> Other candidates are txt2tags and reST/Sphinx, with the former having
> the edge in a huge number of output formats currently supported. Both
> of these are implemented in Python, while Pandocs is Haskell, if that
> means anything.

I need JavaScript code, obviously. There may be bits and pieces worth
taking from those projects, but a brief glance shows that they take in
concerns that don't entirely match TiddlyWiki, so I don't see a way to
wholesale adopt those syntaxes.

> IMO the key is to **not** pick and choose bits and pieces, but to take
> on an entire **syntax spec as a whole**.

I only see that as feasible if there was a spec out there that was (a)
compatible with TiddlyWiki and (b) did everything that TiddlyWiki
needs and (c) didn't include lots of features that aren't relevant for
TiddlyWiki and (d) had usable JavaScript code.

> This would enable plugging TW into a standardized toolchain so that it
> can be either a "publishing and distribution target", along with say
> EPUB, AsciiDoc and HTMLhelp, or perhaps even the location where the
> "master source" text is edited, to then be able to output and
> transform to such formats. NB I consider TW's forte to be the former
> rather than the latter, but something like Pandocs would give the
> flexibility to go in either direction.

As I say, the ability to have pluggable parsers and renderers should
give you the capabilities you want. For you, the native TiddlyWiki
format might just be what gets used for the application plumbing, with
all your content being in other formats.

> But please **please** don't just throw another proprietary wikiMarkup
> syntax set into the mix, this is an historic opportunity to contribute
> to the idea of "open data" in the larger ecosystem rather than
> continuing to view tiddlers as an isolated silo needing custom coding
> to extract inline markup semantics.

I'm not planning to throw another proprietary wiki markup into the
mix. I'm planning to improve TiddlyWiki's existing markup so that it
isn't broken with respect to paragraphs, and to introduce some
alternative syntaxes for some simple formatting.

> Thanks in advance for at least considering these ideas. . .

As I say, I think the kinds of things you're interested in are enabled
by the parsing/rendering architecture. I would very much appreciate
feedback on the improvements to the wikitext.

Best wishes

Jeremy

> /rant
>
> --
> You received this message because you are subscribed to the Google Groups 
> "TiddlyWiki" group.
> To post to this group, send email to tiddlywiki@googlegroups.com.
> To unsubscribe from this group, send email to 
> tiddlywiki+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/tiddlywiki?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2011-12-14 Thread HansBKK

On Dec 14, 7:54 pm, Jeremy Ruston  wrote:

> One of my next steps is to rewrite the wikifier as a peg.js grammar,
> developing a revised TiddlyWiki wiki format that is largely backwards
> compatible but handles paragraphs sensible, and brings in the best of
> markdown (I'm very used to writing `code like this` now, for
> instance).

I've been doing a lot of research and playing around in the "tools
that transform markup" space recently, and would **implore** you to
consider choosing one of the more mainstream cross-platform syntaxes
rather than re-implementing a proprietary TWmarkup, even if it may be
"based on" one of them.

Markdown is a popular choice, lots of active development in the
Pandocs project - their "extensions" may be a bit proprietary, but
since the focus of the whole project is interoperability, it's for a
good cause.

Other candidates are txt2tags and reST/Sphinx, with the former having
the edge in a huge number of output formats currently supported. Both
of these are implemented in Python, while Pandocs is Haskell, if that
means anything.

IMO the key is to **not** pick and choose bits and pieces, but to take
on an entire **syntax spec as a whole**.

This would enable plugging TW into a standardized toolchain so that it
can be either a "publishing and distribution target", along with say
EPUB, AsciiDoc and HTMLhelp, or perhaps even the location where the
"master source" text is edited, to then be able to output and
transform to such formats. NB I consider TW's forte to be the former
rather than the latter, but something like Pandocs would give the
flexibility to go in either direction.

But please **please** don't just throw another proprietary wikiMarkup
syntax set into the mix, this is an historic opportunity to contribute
to the idea of "open data" in the larger ecosystem rather than
continuing to view tiddlers as an isolated silo needing custom coding
to extract inline markup semantics.

Thanks in advance for at least considering these ideas. . .

/rant

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

> Hi Jeremy,
> Nice work !!
>
> Have you seen dox [1] project. It can handle markdown and JSDoc style
> tags. The big difference to other doc generators is, that it produces
> JSON output, that can be rendered by any templating engine.

Thank you, I hadn't seen that. I'm intending to use a full JavaScript
parser for javascript tiddlers, and hoping that it will integrate with
any of the TextProcessors.

Cheers

Jeremy

> [1] https://github.com/visionmedia/dox
>
> --
> You received this message because you are subscribed to the Google Groups 
> "TiddlyWiki" group.
> To post to this group, send email to tiddlywiki@googlegroups.com.
> To unsubscribe from this group, send email to 
> tiddlywiki+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/tiddlywiki?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

[tw] Re: TiddlyWiki Development News

2011-12-14 Thread PMario

On Dec 14, 2:02 pm, Jeremy Ruston  wrote:
> (Parenthetically, I'm planning to resolve the tension between docs in
> the source files and in the readme.md by auto generating the readme
> from the code).

Hi Jeremy,
Nice work !!

Have you seen dox [1] project. It can handle markdown and JSDoc style
tags. The big difference to other doc generators is, that it produces
JSON output, that can be rendered by any templating engine.

-m

[1] https://github.com/visionmedia/dox

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

> I'm not sure it's relevant, but there's now a few SSJS engines
> knocking around (e.g. SilkJS http://silkjs.org/)

Interesting. My first reaction is not to like the JST file idea, but
I'll dig around a bit.

>> Yup, I'm finding that lots of modules that I'm interested in are
>> already built and tested both for node and the browser (for example,
>> peg.js, which I'm planning to use for parsing CSS and so on).
>
> Have you seen language.js as well
> (https://github.com/tolmasky/language)? It has similar syntax to
> peg.js, but seems somewhat better at error handling.

Brilliant, I hadn't seen that, very interesting, thanks.

Best wishes

Jeremy

>
> --
> You received this message because you are subscribed to the Google Groups 
> "TiddlyWiki" group.
> To post to this group, send email to tiddlywiki@googlegroups.com.
> To unsubscribe from this group, send email to 
> tiddlywiki+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/tiddlywiki?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

2011-12-14 Thread Ben Gillies

>> node.js runs on the 2 main O/Ses I care about (Linux and XP), and
>> javascript is now an integral part of the Gnome desktop. That makes a
>> pretty level playing field for better integration of TW based apps
>> with my personal desktop, and still provding for a relatively simple
>> connection path from my desktop/TW (F15/Gnome) talk to my laptop/TW
>> (XP).
>
> Yes indeed. I've been reading that there is now deep support for
> node.js on Windows, which is pretty cool from the point of view of
> TiddlyWiki5 going mainstream.

I'm not sure it's relevant, but there's now a few SSJS engines
knocking around (e.g. SilkJS http://silkjs.org/)


> Yup, I'm finding that lots of modules that I'm interested in are
> already built and tested both for node and the browser (for example,
> peg.js, which I'm planning to use for parsing CSS and so on).

Have you seen language.js as well
(https://github.com/tolmasky/language)? It has similar syntax to
peg.js, but seems somewhat better at error handling.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News

> On Dec 13, 7:04 pm, Jeremy Ruston  wrote:
>> So, at the beginning of December I took a deep breath and
>> transliterated the existing TiddlyWiki wikifier code into cook.js. In
>> the process, I massively refactored it, and structured it much more
>> sensibly. Instead of using jQuery and the DOM, it now parses the
>> wikitext into a generic tree format, and then renders that into
>> textual HTML.
>
> \o/ +1

It was surprisingly easy to get the basic transliteration up and
running, and of course very satisfying to thrash it into some sort of
respectable shape. I'm very excited about the way that it makes lots
of things easy and elegant that were frightful and tacky in the old
code.

>> The reason why this is a big deal is that it brings all the TiddlyWiki
>> developments together. We've got a build tool that can uniformly build
>> old and new TiddlyWikis. We've got a single wikifier code base that
>> can be used on the server, in the browser and as a command line tool.
>
> Very curious to see the wikifier in action. The twikifier code works
> relatively well, but is not ideal, and is fairly inscrutable.

The new wikifier is currently synchronous, but I'm planning to convert
it to synchronous operation, which I think might simplify things on
your side a bit.

One of my next steps is to rewrite the wikifier as a peg.js grammar,
developing a revised TiddlyWiki wiki format that is largely backwards
compatible but handles paragraphs sensible, and brings in the best of
markdown (I'm very used to writing `code like this` now, for
instance).

Cheers

Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Re: [tw] Re: TiddlyWiki Development News