Hi Greg,
> Does that mean you have Tiddly under source control? How useful is it,
> being it's all one file?
>
Nope, not yet. I simply reversed the functionality on tb5. The one file
thing is what I have used so far, except for binaries which I prefer to
keep outside unless we're talking really small images for ui components.
> I feel by the very nature of the TW architecture this isn't possible, but
> just to confirm, there's no way maintain some kind of link with plugins and
> their source?
>
It is possible insofar as you can use node and github repositories to cook
your desired TiddlyWiki's. You can have one built command that lets you
build a server-tw which syncs back individual tiddlers to your node store
and you can have another build command that builds that
singlefile-selv-contained wiki that stores itself in its entirety. Two
different approaches that you can sure combine, so long as you manage to
keep track.
I have not even started versioning my little "snippets" yet... which will
change with GitHub.
> Does updating plugins literally mean keeping an eye on the devs
> communication channels and dragging over an updated file to my personal
> TiddlyWiki
>
Right now, yes, unless...
1. your plugin author has a stable code-repo
2. you're merging his changes into your local copy and
3. build your TiddlyWiki(s) based on those updated plugins
Not sure if I'd recommend that because you do want to keep an eye on
changes and have a way to verify one-by-one if there are things that break.
At some point, there will surely be some sync adapter that allows you to
check your plugin source for updates.
Plugins are really just "Tiddler-Bundles", so they can be anything from
code to content... the task is really not "keeping plugins up to date" but
rather to keep any "remote bundles" up to date.
There is no repo or submodule functionality to pull in upstream changes for
> plugins, right?
>
Not until those repos actually exist, which is true for those plugins that
you find in the core repo. So far, I have yet to set mine up for others to
pull from and include. Not sure, if automation actually scares me or not,
because the degree at which "tested code" is going to be expected will
surely be much higher than it traditionally was in this community.
Ah, now it's coming together! I've achieved part of what by hacking at your
> hard work :)
>
<<list-search
> "[tag[ProjectA]tag[Research]]"
> "search"
> "$:/temp/ProjectAResearch"
> "$:/template/tagList">>
>
Again, right now, you can either use list-search or taggly, not both, I'm
afraid... since you won't see any matching children for your filter string
when using both in combination.
> in my "$:/template/tagList" I modified your "$:/template/tagged-timeline"
> to just display title and tags:
>
<div class="tagList-item">
> <dt>
> <$link to={{!!title}}><$view field="title"/></$link>
> </dt>
> <dd class="tagList-tags">
> <$list filter="[all[current]tags[]sort[title]]-[<remove>]"
> template="$:/core/ui/TagTemplate"/>
> </dd>
> </div>
>
> It's a shame that the ToC macro doesn't accept two tags like list-search
> does. Then I think I would have self-managing hierarchy I desire! :)
>
Not sure what you mean, list-search doesn't really accept "two tags". What
it does is allow you to define any arbitrary filter which, in addition can
be filtered via some search mode defined by you. With any list widget
implementation you are free to define any template you want, with or
without tags, etc...
Thanks for the help and all the hard work Tobias, I see you everywhere I
> look for TW documentation. haha
Call it a passion project. ^^
Best wishes, Tobias.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
