On Fri, 11 Feb 2011, Martin Budden wrote:
[code as the engine of change]
I would also like to see this happen. Indeed it is one of the things I
tried to get going (but based on developer branches in subversion
rather than code forks (in, say, git)). When I started working on
TiddlyWiki I made a
> I personally don't much like the separate "PluginInfo" tiddler
Originally, each of my plugins contained both the documentation and
the code in a single tiddler. While this provides a good *initial*
learning experience for the user, the documentation isn't actually
necessary in order to use the
> No, that wasn't my intention... however I wouldn't mind if Eric's way of
> documenting his plugins (how it's seen at TiddlyTools...) was a standard
> which was followed by all TWDevelopers.
> 1) Plugin,
> 2) PluginInfo,
> 3) Examples of usage - maybe even a
> 4) Usercase vertical, setup for imme
On Feb 12, 1:57 am, Måns wrote:
> At the very beginning there were some posts in the
> > group. But since several month. Nothing ... Either, the users don't
> > use these plugins anymore, or they got them fixed. There was no need
> > to stop the core.
>
> I don't agree :-)
Thx Måns, I hoped I
Hi Paul
... but you can see this from
> the source code recipes:
>
>
> http://svn.tiddlywiki.org/Trunk/verticals/TiddlySlidy/plugins/split.recipe
>
> You seem to be asking us all to standardise on using plugins from
> other developers. Actually one developer.
>
No, that wasn't my intention..
> My point here is that I would love to be able to fork TiddlySlidy - or reuse
> any of the "killerfeatures" (maybe just some of the css) it has, and
> combine them with options and plugins that I know from other
> circumstances...
TiddlySlidy, etc deliberately have the asthetic of being complete
Hi Paul
> Anyone, including you can do this as of now. But it would be a fork,
> require a lot of changes to work around the use of embedded and
> evaluated JavaScript, which are inappropriate in a shared JavaScript
> environment, and then have to track Eric's changes in TiddlyTools.
>
I am using
> My hope or vision if you like - (initially) was that most of Eric's
> (tiddlytools) great plugins (especially import/export UI's and features)
> would be acknowleged as a standard which users of TiddlyWiki have come to
> expect from TiddlyWiki, and therefore investigated and copied into
> TiddlyS
>
>
> WOW! How can I possibly respond to such kind words, except:
>
> *SMILE* *BLUSH* thank you!
>
>
:-)
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To post to this group, send email to tiddlywikidev@googlegroups.com.
To unsubscr
> Why not "stand of the shoulders of Eric"? "The Legacy of TiddlyTools" ;-)
> Well, - I'm not a programmer and I recon there are many "different roads to
> take" - preferences of style, if you like... However I have come to the
> conclusion that Eric is not "just" a gifted programmer in the normal
Hi TiddlyWikiDevWizards
Since github is a network of trust, every user can decide, which core
> to use. If you like the conservative approach, go with the
> conservative core. If you like the community approach, go with the
> community core, if there is one.
>
> I think this is very common, wi
On Fri, 11 Feb 2011, Martin Budden wrote:
[keeping people informed]
I'm one of the ones that argues that a ticket should be enough. From
your comment I presume you don't. But to move on we need to understand
why a ticket is not sufficient. Rather than a rather vague comment
such as "exerience su
Some comments on your "things that need narrowing down":
1) "Some seem to argue that the presence of a ticket or a reference to
it is enough. Other
suggest that commit messages ought to be enough."
I'm one of the ones that argues that a ticket should be enough. From
your comment I presume you don
> ... the core team should do everything possible to facilitate
> the efforts of plugin authors to keep their code viable and up-to-date
> with the latest core code rather than putting the onus onto the plugin
> developer to scramble and catch up."
>
> I think this is unfair. Any TiddlyWiki changes
Quite interesting ...
I like the idea, having a repo, that doesn't change weekly.
I also like the idea, using the newest stuff.
I think, having the core moved to github, can provide both.
I feel comfortable if a stable core moves on every half a year of even
every year.
On the other hand, I thi
On Wed, 9 Feb 2011, Eric Shulman wrote:
I think that the 'pointed language' on *both* our parts is a result of
the long-term frustrations with the process. Regrettably, those
frustrations sometimes lead to a bit more 'heat' and less bit less
'light'. Thanks for looking past the words to get to
Chris's vision of an open source project:
"In a modern healthy open source project, activity is focused around
source code. It's right there in the name. I want to see a future
where there is some person or persons "X" who maintain a git repo from
which the official TiddlyWiki core is built. Surro
>
> Extra thought: THANK YOU! This is the discussion we've been needing
> for YEARS!
>
> -e
I couldn't agree more.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To post to this group, send email to tiddlywikidev@googlegroups.com.
To unsubsc
> It's interesting: I think we mostly agree but because of some of my
> pointed language I may be triggering a reaction in you that is
> obscuring some of that agreement.
I think that the 'pointed language' on *both* our parts is a result of
the long-term frustrations with the process. Regrettabl
[My response below is quite long. I hope you will read it, but if you
want the tldr version it is this: I mostly agree with Eric, I think
the core maintainers need to communicate more, that's what I've been
saying all along.]
On Tue, 8 Feb 2011, Eric Shulman wrote:
TiddlyWiki suffers from some
I am all in for "blowing out the dust". TW core development should be
agile enough to move on, especially with fundamental, high priority
issues like that of tiddler IDs.
If there are plugins that were published for TW 2.1.x and are expected
to flawlessly cooperate with 2.6+, I think one should ei
Though I'm new here, I've been using TW for a couple of years and have
been developing software for over 25 years. I'm also a bit out-of-the-
loop on TW plugins released in the last year due being on some other
projects. However, this discussion raises the (perhaps naive)
question...
Since each TW
> TiddlyWiki suffers from something that might be called the tyranny of
> the legacy[1]. It's captured in the idea that it is up to the maintainers
> of the core to go out and search for plugins that might be harmed by
> changes to the core.
There is no "tyranny" of the legacy. But there *is* a w
> To get back to what I took as FND's original point, the issue here is
> not this one bug about jQuery, but rather how long it is taking it,
> as an example of many bugs, to get resolved. A healthy open source
> project "should move more rapidly and be more responsive".
That was indeed my main
On Tue, 8 Feb 2011, Eric Shulman wrote:
However, the same may not be true for other, non-TiddlyTools plugins
that are still constructing their own tiddler element IDs. I suggest
that, before releasing any fix for #472, we should perform a simple
text search through as many known, published plug
I'd favour sticking with the underscore escaping, and not attempting
to pursue XHTML compatibility.
Cheers
Jeremy
On Tue, Feb 8, 2011 at 12:21 PM, Paul Downey wrote:
>> The problem is not finding a fix, indeed the proposed solution is
>> escaping spaces with underscores (and underscores with do
> The problem is not finding a fix, indeed the proposed solution is
> escaping spaces with underscores (and underscores with double
> underscores).
I'm not mad about legitimate underscores becoming doubled, and it
seems a reasonable work-round for a HTML document:
http://www.w3.org/TR/html5/e
The problem is not finding a fix, indeed the proposed solution is
escaping spaces with underscores (and underscores with double
underscores). The problem is that this or any fix will break plugins,
so time was allowed for the plugins to be fixed.
I've just heard from Eric to say that he has fixed
> (http://trac.tiddlywiki.org/ticket/472). Although the fix
> is simple to implement, it breaks a number of Eric's plugins so we
> didn't put the fix in release 2.6.2 so that he would have time to fix
> those plugins.
There were a small number of places where TiddlyTools plugins were
using:
sto
Hi,
if spaces are a problem, what about escaping them? Something like url-
escape possible or a html code.
url escaping would be: space%20
and for html something like:
en space
em space
thin space
If spaces in titles could be html escaped, I think not too much would
Hi Folks,
3 years ago I even didn't know that TW exist. IMO this issue should
have been fixed 3 years ago. Or may be 2 years ago, after a one year
beta. I started programming TW about one year ago. Not fixing this
issue, now causes trouble, for everyone, that have made the mistake to
use a function
31 matches
Mail list logo
