Thanks Julian, much appreciated. The long journey of taking TiddlyWiki
from an experiment to a welcoming and useful ecosystem has been thanks
to the contributions of many other people such as Eric, Saq, Simon and
Daniel, Chris Dent, Udo Borkowski and lots more.
The html/wikitext dichotomy is
Jeremy, well done for plugging an overhaul of TW - it will never
please everyone but I think everyone WILL say that TW has already been
an amazing success and a brilliant concept well developed. I for one
am looking forward very much to see a new version using the latest
concepts I've no doubt
Almost all of this discussion is way, way over my head. I understand -- or
misunderstand! -- enough to make me anxious, though.
I hope you have no need to be anxious. TiddlyWiki5 is a functional
superset of classic TiddlyWiki, no-one is going to lose features if
they choose to make the
Hello Jeremy,
On Apr 1, 1:08 am, Jeremy Ruston jeremy.rus...@gmail.com wrote:
I hope you have no need to be anxious. TiddlyWiki5 is
a functional superset of classic TiddlyWiki, no-one
is going to lose features if
TW is a great product, and I certainly appreciate the effort that has
gone into
While it may be true in the technical sense that no one will lose
features, the fact that there will be no backward compatibility with
existing macros/plugins will have an immediate impact on anyone not
using the barebones TW.
Let's be clear: if we wanted TiddlyWiki5 to be compatible with
Any thought paid to supporting semantically rich tagging in TW 5?
That is, being able to associate a relationship type with the tag
instead of just assuming generic isA? Extended fields does this to
some extent, but they are hidden and not as easy to use as tags. It
would be cool to combine the
Any thought paid to supporting semantically rich tagging in TW 5?
That is, being able to associate a relationship type with the tag
instead of just assuming generic isA? Extended fields does this to
some extent, but they are hidden and not as easy to use as tags. It
would be cool to combine
I think simply (tongue in cheek)
1) extending the tag definition to optionally allow definition of the
relationship type as:
tags = conventionalUntypedTag1 isA(tagA) conventionalUntypedTag2
belongsTo(tagB) dependsOn(tagC)
2) then storing these under the cover as extended fields
isA =
this is on Mark S's list, but I would like to second support for
InlineJavascript (plugin or native) w/ TW5
Mike
On Apr 1, 10:19 am, Saverio saverio.mavig...@gmail.com wrote:
Oops, tagA would be stored under the isA extended field, as well:
isA = conventionalUntypedTag1
Hello Jeremy,
On Apr 1, 6:11 am, Jeremy Ruston jeremy.rus...@gmail.com wrote:
Calendar reminder plugins are essential if TW is
going to compete with existing PIM software.
I think a basic calendar plugin would be useful for
the core, but in general I've learned that what I
might call the
this is on Mark S's list, but I would like to second support for
InlineJavascript (plugin or native) w/ TW5
TW5 will definitely support InlineJavaScript via a plugin, but I'm
very cautious about putting it into the core. In shared environments
it could be a vector for malicious code. It'd be OK
plugins are great, allows the core to remain small, and gives
customization options to the end user. I know you mentioned backwards
compatibility - are you thinking of something like
DepreciatedFunctions? Allowing some old plugins to get in, but not
creating a core code increase. . . Kind of a
In following this discussion as to what plugin functionality to
consider moving into the core for TW5, I am left wondering about fET?
This is the single, most important extension for any of my TW files;
calendar, status reporting, addressbook, knowledge databases of
various subjects, and blood
plugins are great, allows the core to remain small, and gives
customization options to the end user. I know you mentioned backwards
compatibility - are you thinking of something like
DepreciatedFunctions? Allowing some old plugins to get in, but not
creating a core code increase. . . Kind of
I recognise the significance of fET, and think that something like it
needs to be built into the core.
The prototype includes the bare bones of support for a jQuery-like
filter chaining syntax that will permit tiddler selection and sorting
in an efficient and readable form of JavaScript. I'm
Saverio wrote;
Any thought paid to supporting semantically rich tagging in TW 5?
That is, being able to associate a relationship type with the tag
A note here, assuming I understand you right; Because tags are
interchangeable with tiddler names, it *is* possiblt to type a tag...
by tagging it!
FND wrote this in twdev:
So I'm not against wysiwyg, and I'm not against being able to write
the HTML, I'm against writing HTML //as a language for markup.//
FWIW, I guess there's a misunderstanding here.
I don't think anyone will be expected to compose tiddlers in raw HTML
(unless they
On Mar 30, 2010, at 12:41 PM, Jeremy Ruston wrote:
What I really don't understand is that you've gone the multiple-format
+ html/wysiwyg approach and not the wikitext/wysiwyg approach.
I presume by wikitext/wysiwyg you mean the approach of
round-tripping from wikitext to wysiwyg and back
Getting away from wikitext is fine, since the industry has not
apparently settled on one particular wiki dialect. If everyone used
the same dialect, then you could seamlessly pour data back and forth
between the various wiki-emulants.
I find the overall move to TW 5 a bit disheartening. Not all
I find the overall move to TW 5 a bit disheartening. Not all of us are
whipper-snappers that can pick up new technologies at the drop of a
hat. I was hoping for a knowledge platform that would stay stable for
a half decade or so at a time. I just about have everything working as
a
Okay it's good to know that there is the option of staying with
wikitext and also the option of having dual wysiwyg/html.
So the choice will have to be made on a per-tiddler basis.
What I am concerned with is that plugins that traverse or use wikitext
(the source of a tiddler) will have to be
The reason the internet community has not been able to agree on a wiki
text format is because MediaWiki has chosen such stupid markup for
bold and italics. (Well there are probably a lot of other reasons but
this is self-apparent). Everyone else has come to adopt the following
convention:
-
Okay it's good to know that there is the option of staying with
wikitext and also the option of having dual wysiwyg/html.
So the choice will have to be made on a per-tiddler basis.
What I am concerned with is that plugins that traverse or use wikitext
(the source of a tiddler) will have to
Thanks Jeremy, insightful answers. I will answer your multi-record
specific answers in the original thread in twdev [1].
This processing to refresh the display is inevitably a
DOM-based operation.
I take it these processing scripts are tailor-made to the specific
event that was registered? I
24 matches
Mail list logo
