Eve syntax embedded in TiddlyWiki

107 views
Skip to first unread message

Brian Theado

unread,
Jun 4, 2017, 3:48:27 PM6/4/17
to Eve talk
Earlier, I had embedded a sample Eve program into the TiddlyWiki
(http://tiddlywiki.com/) application. It used the Javascript DSL. I
have updated it to support the Eve syntax. Now Eve programs can be
stored in "tiddlers" and rendered wherever you want inside the wiki.

You can see the source code at https://github.com/btheado/tweve and a demo at
https://btheado.github.io/tweve/. The demo is single-file,
self-modifiable html. With just a browser and this html file, you can
author an Eve program and save the results to a new html file.

I'm just sharing what I've done so far...I haven't tested it much yet.

Brian

Anton Dyudin

unread,
Jun 4, 2017, 5:32:36 PM6/4/17
to Eve talk
image.png

Adam Logghe

unread,
Jun 4, 2017, 5:52:44 PM6/4/17
to Eve talk
This is super cool.

Two great projects to mashup, nicely done.

I'd use this if I wasn't one of those evil/emacs/orgmode people.

Demo seemed to work for me.

I'd clean up the first block of explanation of the different methods to use eve in TiddlyWiki, it's very confusing as to whats what when editing.

Keep pushing!

Adam

On Sunday, June 4, 2017 at 12:48:27 PM UTC-7, Brian Theado wrote:

Brian Theado

unread,
Jun 4, 2017, 7:30:41 PM6/4/17
to Anton Dyudin, Eve talk
Thanks for this. Could you share what browser and version you are
using? My guess is the code is not transformed into javascript
compatible with your browser, but I'm not very sure.
> --
> You received this message because you are subscribed to the Google Groups "Eve talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eve-talk+u...@googlegroups.com.
> To post to this group, send email to eve-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/eve-talk/32220fa7-8c61-4762-a01a-d23482e5844b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Brian Theado

unread,
Jun 4, 2017, 7:37:30 PM6/4/17
to Adam Logghe, Eve talk
Adam,

On Sun, Jun 4, 2017 at 5:52 PM, Adam Logghe <alo...@gmail.com> wrote:
> This is super cool.
[...]
> Demo seemed to work for me.

Great, thanks for the feedback. Good to know I'm not the only one it works for.

> I'd clean up the first block of explanation of the different methods to use
> eve in TiddlyWiki, it's very confusing as to whats what when editing.

I agree it could be clearer. I'm thinking I should simplify it and
concentrate on the more common case of having the Eve code stored in a
separate tiddler and leave out the Tiddlywiki triple double quotes
example.

Brian Theado

unread,
Jun 4, 2017, 9:40:40 PM6/4/17
to Adam Logghe, Eve talk
I have rewriten the introduction, hopefully making it more clear.

In addition, I fixed a refresh issue and added the eve-starter
base.css so the #ui tagged items look nicer.

https://github.com/btheado/tweve and https://btheado.github.io/tweve/

On Sun, Jun 4, 2017 at 5:52 PM, Adam Logghe <alo...@gmail.com> wrote:
[...]
>
> I'd clean up the first block of explanation of the different methods to use
> eve in TiddlyWiki, it's very confusing as to whats what when editing.
[...]

Zubair Quraishi

unread,
Jun 5, 2017, 2:13:29 AM6/5/17
to Eve talk
Absolutely amazing!!! :)

Josh Cole

unread,
Jun 6, 2017, 2:41:07 PM6/6/17
to Eve talk
Hey Brian,

As everyone else has mentioned already -- this is really cool! Everything worked fine when I tried it on Kubuntu 17.04 in Chromium. Having been in the difficult position of writing easy-to-follow documentation recently, I think you've done a great job with your getting started guide. One thing I'd recommend is to guide users of Eve to tiddlywiki's documentation and users of tiddlywiki to Eve's documentation to help them get started with whichever aspect might be new to them. I can't wait to see the interesting things people will build with this. :)
With respect to your improvements needed section, I can help in the short term with two.


> Maybe there is a way to find root elements and automatically take care of the #tw-widget-root embedding

Sure is! There's a single block responsible for detecting roots and tagging them to be attached to the document in the HTML library. You can write something very similar which should automatically add these "root" elements to the widget container.


E.g.

Any element with no parent (or that is already a child of the widget root) is parented to the widget root.
```search
  widget-root = [#tw-widget-root]
  elem = [#html/element]
  not(
    parent = [#html/element children: elem]
    parent != widget-root
  )

bind
  widget-root.children += elem
```

The extra bit of trickery in the `not` is required to prevent the block from invalidating itself. If we kept the existing search logic, it would first match a root element, adding it as a child of the widget. Doing so would make it no longer match, so it would stop being a child. This would allow it to match again, ad infinitum. Instead, we include the loophole that, if an element's parent is already the widget, we'll continue asserting that. Just automatically add this block to any program that you'd like to widget-ize and it should work. :slightly_smiling_face:

> Ability to pass in list of watchers to attach to the Eve program

If there's anything on our side we can do to facilitate this, we'd be happy to hear your thoughts. As is, you should be able to repeatedly call `program.attach(name)` where name is passed in from the user.

The other two are slightly longer term projects, but certainly high priority.

> Error handling

On the Eve side at least, this is next on my todo list. There was some trickiness here imposed by supporting the alternate JS DSL which hindered our error reporting. There's no reason why that needs to impact our syntax version though. If you run into any specific and frustrating errors, please don't hesitate to create an issue on GitHub with the block in question.

> Ability to save Eve state

The current plan is to release a proper persistence story in version 0.4, though we may adjust that depending on how the chips fall. In the interim, there's the quick and dirty solution of exporting the essential state yourself using watchers, as Corey demonstrated here: https://groups.google.com/d/msg/eve-talk/OaYaeJKJUiU/XrRn3HjfEwAJ . Unfortunately, this can't be completely transparent without the full persistence story. The program author will need to indicate to you in some way that a particular record should get persisted. That said, it doesn't have to be much more frustrating than just sticking a `#persisted` tag on the necessary records to pickle/unpickle your state.

Looking forward to playing with this more as time permits. Keep up the good work!

On Sunday, June 4, 2017 at 12:48:27 PM UTC-7, Brian Theado wrote:

Brian Theado

unread,
Jun 6, 2017, 11:23:07 PM6/6/17
to Josh Cole, Eve talk
Josh,

Thanks much for your valuable feedback. See below.

On Tue, Jun 6, 2017 at 2:41 PM, Josh Cole <joshu...@gmail.com> wrote:
[...]
> One thing I'd
> recommend is to guide users of Eve to tiddlywiki's documentation and users
> of tiddlywiki to Eve's documentation to help them get started with whichever
> aspect might be new to them.

Good idea.

[...]
> Any element with no parent (or that is already a child of the widget root)
> is parented to the widget root.
> ```search
> widget-root = [#tw-widget-root]
> elem = [#html/element]
> not(
> parent = [#html/element children: elem]
> parent != widget-root
> )
>
> bind
> widget-root.children += elem
> ```

Thanks. This gave me a head start and it worked for a very simple
top-level div. But if I have a structure like div1->div2, then div2
renders both as tw-widget-root->div1->div2 and tw-widget-root->div2.
IOW, any children of a div are somehow also getting assigned as
children of tw-widget-root. I'm still trying to think it through, but
so far I don't see how that is happening as the 'not' logic above
looks sound to me.

I also noticed the block you provided was adding [#tw-widget-root] as
a child of itself. I added a 'elem != widget-root' filter to fix that
issue.

[...]
>> Ability to pass in list of watchers to attach to the Eve program
>
> If there's anything on our side we can do to facilitate this, we'd be happy
> to hear your thoughts. As is, you should be able to repeatedly call
> `program.attach(name)` where name is passed in from the user.

Yes, I had planned to call attach for each watcher given by the user.
Currently I'm only importing a bare minimum of the watchers and will
also have to add the rest to the list of imports.

[...]
>> Error handling
>
> On the Eve side at least, this is next on my todo list. There was some
> trickiness here imposed by supporting the alternate JS DSL which hindered
> our error reporting. There's no reason why that needs to impact our syntax
> version though. If you run into any specific and frustrating errors, please
> don't hesitate to create an issue on GitHub with the block in question.

This one I haven't given much thought to. I just know if someone tries
to develop an eve program using tiddlywiki it will be difficult
without some nice error reporting.

>> Ability to save Eve state
>
> The current plan is to release a proper persistence story in version 0.4,
> though we may adjust that depending on how the chips fall. In the interim,
> there's the quick and dirty solution of exporting the essential state
> yourself using watchers, as Corey demonstrated here:
> https://groups.google.com/d/msg/eve-talk/OaYaeJKJUiU/XrRn3HjfEwAJ .
> Unfortunately, this can't be completely transparent without the full
> persistence story. The program author will need to indicate to you in some
> way that a particular record should get persisted. That said, it doesn't
> have to be much more frustrating than just sticking a `#persisted` tag on
> the necessary records to pickle/unpickle your state.

Yes, I started playing with that approach of marking records to be
persisted. Actually I'm starting with the simpler case of trying to
explicitly persist the [#counter] structure from counter.eve. Once I
have that working, I will try generalizing it so it can with with
anything tagged with #persisted.

Brian
Reply all
Reply to author
Forward
0 new messages