[TW5] widget to Goto Ranomized Tiddler

[Philip Coltharp]

I envision a widget defined like so..  a list in side a button like so.  ( Imagine this was put in a tiddler on http://tiddlywiki.com/)

<$button to="<$list filter="[tag[Widgets]] pick-at-random="1">">Go To Random Widget Tiddler</$button>

         OR

<$button to="<pick-at-random from="<$list filter="[tag[Widgets]]">">">Go To Random Widget Tiddler</$button>

The ideal is to get a button to send a user to a tiddler picked at random from a list.

I could do this in Classic Tiddlywiki but I want to learn Tiddlywiki5.  How might one do this in TW5 differently than in TWC?

[Eucaly J]

maybe ... to implement a random filter

<$list filter="[tag[Widgets]random[]limit[1]]" variable="randomTiddler">
<$button to=<<randomTiddler>> >Go To Random Widget Tiddler</$button>
</$list>

Philip Coltharp於 2014年10月7日星期二UTC+8上午7時37分00秒寫道：

[Philip Coltharp]

That's something I wouldn't have thought of. Thanks

[Eucaly J]

Here comes the random filter (to limit to n results), as attached.

usage : [tag[Widgets]random[1]]


Philip Coltharp：

[Philip Coltharp]

What type of object is source?

[Eucaly J]

Hi Philip:

Could you explain your question a little further?


Philip Coltharp：

[Philip Coltharp]

is it a list/array of arbitrary objects, indexed by title?

Is it a list/array of only tiddlers, indexed by title?

The code

source(function(tiddler,title) {
 results.push(title);
 });

is some thing I don't understand well.  What is the name given to the javascript concept used here?, which I suspect is transforming the object source in to another object results
.

[Philip Coltharp]

Euclay,

So I'm reading and learning tiddlywiki filter code and its conventions.  I just read the code "TiddlyWiki5\core\modules\filters.js" and I believe I've started to answer my question.

Thank you for what you have given so far.

On Tuesday, October 7, 2014 6:28:17 AM UTC-4, Philip Coltharp wrote:

is it a list/array of arbitrary objects, indexed by title?

Is it a list/array of only tiddlers, indexed by title?

The code

source(function(tiddler,title) {
 results.push(title);
 });

is some thing I don't understand well.  What is the name given to the javascript concept used here?, which I suspect is transforming the object source in to another object results
.

[Jeremy Ruston]

Hi Eucaly

Here comes the random filter (to limit to n results), as attached.

usage : [tag[Widgets]random[1]]

There is a potential issue with this approach. It means that each time the filter is evaluated it might return different results, even if the tiddler store hasn't changed. This is contrary to the expectations of the rest of the system; it means, for example, that content could change unexpectedly whenever there is a refresh cycle. In many situations this might not matter, of course.

A better approach would be to generate a random number and store it in a tiddler, and then use that tiddler value to choose a tiddler to display. That would mean that the entire state of the UI is once more represented by the tiddler store.

So, in outline, we introduce a tiddler '$:/info/random' that is initialised with a random number at startup. We'd also add a "tm-generate-random" message so that the random value could be regenerated by the user after startup.

Then we'd add a new filter "choose" that would be used like this:

[tag[Widgets]choose{$:/info/random}]

The action of the 'choose' filter would be to modulo the operand by the number of entries in the current list, and then use the result as an index to choose a value from the current list.

Best wishes

Jeremy

 

Philip Coltharp：

That's something I wouldn't have thought of.  Thanks

--
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 tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[PMario]

On Tuesday, October 7, 2014 1:25:33 PM UTC+2, Jeremy Ruston wrote:

Then we'd add a new filter "choose" that would be used like this:

[tag[Widgets]choose{$:/info/random}]

If you write the tiddler title to $:/info/random you could use  <$transclude tiddler={{$:/info/random!!text}} mode=block>>  or

\define showRandom()
<$transclude tiddler={{$:/info/random!!text}} mode=block>>
\end

<<showRandom>>

-m

[Eucaly J]

Hi Jeremy:

The "refresh cycle issue" did come across my mind earlier today.
I will add a warning message on the "random filter".

After reading your suggestion, I will agree that such unexpected change would better be user driven -- as a button.
(to issue "tm-generate-random" message, or calling some plugin).

But the scale will somehow larger than "random filter".

I will wait the response from who initiate this thread.


Jeremy Ruston：

[Philip Coltharp]

On Tuesday, October 7, 2014 7:25:33 AM UTC-4, Jeremy Ruston wrote:

There is a potential issue with this approach. It means that each time the filter is evaluated it might return different results, even if the tiddler store hasn't changed. This is contrary to the expectations of the rest of the system; it means, for example, that content could change unexpectedly whenever there is a refresh cycle. In many situations this might not matter, of course.

A better approach would be to generate a random number and store it in a tiddler, and then use that tiddler value to choose a tiddler to display. That would mean that the entire state of the UI is once more represented by the tiddler store.

I think I am seeing this, the widget action  gets added to the DOM , between the time the widget is added and the widget is activated, changes to the store can happen...  

[Philip Coltharp]

Still a random filter(s) might be used on lists, yes?  One could think of four such filters, pick N at random, remove N at random, pick N at random with replacement, and randomize .

[Jeremy Ruston]

Hi Philip

Still a random filter(s) might be used on lists, yes?  One could think of four such filters, pick N at random, remove N at random, pick N at random with replacement, and randomize .

There are some subtle assumptions that filter execution is deterministic (ie, a given filter string will evaluate to the same list every time it is executed in the context of the same tiddler store values). For example, the list widget re-evaluates the filter each time it is refreshed, and detects changes to the list. If there were a randomising filter operator then the filter would be deemed to have changed every time, leading to continuous repeated refreshing of the list widget content.

Best wishes

Jeremy.

[Philip Coltharp]

I am relatively closer to understanding.  

[Stephan Hradek]

Am Dienstag, 7. Oktober 2014 13:25:33 UTC+2 schrieb Jeremy Ruston:

The action of the 'choose' filter would be to modulo the operand by the number of entries in the current list, and then use the result as an index to choose a value from the current list.

 
I propose to have $:/info/random be a number from x with 0 <= x < 1. Then do not do a modulo, but multiply $:/info/random with the length of the list. The integer part of the result is the index.

If you have modulo, you get unfair distributions. Suppose your numbers range from 0 to 99 (so modulo 100). And your list length is 66. The result will be that the first 33 elments will be picked with a double the probability than the last 33.

[Philip Coltharp]

On Wednesday, October 8, 2014  Jeremy Ruston made the commit https://github.com/Jermolene/TiddlyWiki5/commit/0dcf54c3b59ed04645928f0ec4ced647e5a0da7f:

in editions/tw5.com/tiddlers/ActionNavigateWidget.tid:

The ''action-navigate'' widget is invisible. Any content within it is ignored.

 

Euclay's random filter idea will work with this new action widget,  because the content is ignored by the "refresh cycle"....   correct?

[Jeremy Ruston]

No that is not correct. The content of the action-navigate widget is completely ignored; it won't be rendered or refreshed.

Best wishes

Jeremy

 

[Philip Coltharp]

So I did it. 

https://github.com/PhilipColtharp/TiddlyWiki5/commit/bd94f508aa4726bf690446c983c2c0ed66cfb7b8

[Jeremy Ruston]

Hi Philip

Well done, very cool.

I think it can be done without modifying the navigator widget though, by introducing a "randomly choose from filter" action widget:

<$button>

<$action-chooserandom filter="[is[tiddler]]" tiddler="$:/config/randomtiddler"/>

<$action-navigate to={{$:/config/randomtiddler}}/>

Goto random tiddler

</$button>

Best wishes

Jeremy

On Sat, Oct 11, 2014 at 10:25 PM, Philip Coltharp <colthar...@gmail.com> wrote:

So I did it. 

https://github.com/PhilipColtharp/TiddlyWiki5/commit/bd94f508aa4726bf690446c983c2c0ed66cfb7b8

[Tobias Beer]

Actually, I think the most powerful apporach is a random filter.

randomm[n]  — out of the filtered set randomly chose (max) n tids

Best wishes, Tobias.

[Tobias Beer]

Hi Jeremy,

 

I think it can be done without modifying the navigator widget though, by introducing a "randomly choose from filter" action widget:

<$action-chooserandom filter="[is[tiddler]]" tiddler="$:/config/randomtiddler"/>

What is the benefit of that over a [random[n]] filter? Other than a need to remember a once drawn random number there isn't really any need to specify a random number tiddler, is there? Why would that be something a user is concerned with?

Best wishes, Tobias.

[Tobias Beer]

There is a potential issue with this approach. It means that each time the filter is evaluated it might return different results, even if the tiddler store hasn't changed. This is contrary to the expectations of the rest of the system; it means, for example, that content could change unexpectedly whenever there is a refresh cycle. In many situations this might not matter, of course.

First of all, I think there are usecases where a new random set at each refresh is actually desired. Where that is not the case, does the DOM get entirely replaced or are states preserved upon refresh?

A better approach would be to generate a random number and store it in a tiddler, and then use that tiddler value to choose a tiddler to display. That would mean that the entire state of the UI is once more represented by the tiddler store.

 

So, in outline, we introduce a tiddler '$:/info/random' that is initialised with a random number at startup. We'd also add a "tm-generate-random" message so that the random value could be regenerated by the user after startup.

Doesn't there have to be one random number per filter expression requesting it rather than one global random number for all filters to make use of?

 

Then we'd add a new filter "choose" that would be used like this:

[tag[Widgets]choose{$:/info/random}]

That I really don't get. What is important is that each instance of a [random[]] filter or a filter making use of a random number needs to persist the initial draw until a page reload.

The action of the 'choose' filter would be to modulo the operand by the number of entries in the current list, and then use the result as an index to choose a value from the current list.

As Stephan pointed out, modulo will impinge on randomness.

Best wishes, Tobias.

[PMario]

On Sunday, November 16, 2014 9:40:09 PM UTC+1, Tobias Beer wrote:

 

Then we'd add a new filter "choose" that would be used like this:

[tag[Widgets]choose{$:/info/random}]

That I really don't get. What is important is that each instance of a [random[]] filter or a filter making use of a random number needs to persist the initial draw until a page reload.

Widgets can be redrawn at any time, if the core detects changes in the tiddler store. So whenever a tiddler, or a section of a tiddler is redrawn and it contains the [random[]] filter, you'll get a new result. But that's not what you want.

-m

[Tobias Beer]

Widgets can be redrawn at any time, if the core detects changes in the tiddler store. So whenever a tiddler, or a section of a tiddler is redrawn and it contains the [random[]] filter, you'll get a new result. But that's not what you want.

Then that means that such a "random state" is required for every instance, without the user necessarily being required to specify it. The question of whether or not there'd be a [random[]] filter seems independent of that requirement to me.

Best wishes, Tobias.

[Jeremy Ruston]

Hi Tobias

Just to be clear, a "[random[]]" filter is a dead duck with the current architecture

> What is the benefit of that over a [random[n]] filter? 

That it is possible for it to work! A random filter cannot work.

> First of all, I think there are usecases where a new random set at each refresh is actually desired.

I don't think so. A refresh cycle can happen at any time, potentially many times a second.

> Where that is not the case, does the DOM get entirely replaced or are states preserved upon refresh?

The DOM is selectively updated, with parts of the tree being replaced as required. It is not possible to store state in the DOM.

> What is important is that each instance of a [random[]] filter or a filter making use of a random number needs to persist the initial draw until a page reload.

We can use the stored random number as a seed for generating the numbers that we need. We can also provide a "throw the dice" button that generates a new random number.

Perhaps it would be helpful if I understood your underlying use case. What are you trying to achieve with random number generation?

Best wishes

Jeremy

[Tobias Beer]

Perhaps it would be helpful if I understood your underlying use case. What are you trying to achieve with random number generation?

There are plenty usecases for outputting a random list of tiddlers matching a given filter along with a template...

• show: 10 random unanswered / wrongly answered quiz questions
• show a random quote
• show a "Did you know?" section listing interesting content
• ...

Best wishes, Tobias.

[Jeremy Ruston]

Hi Tobias

OK, I can only reiterate what I've said above. If you want to do stuff like that then the current state of the random number needs to be stored in a tiddler so that it will be available across refreshes. There needs to be a specific trigger to change the random number (eg starting up, or clicking a button). What you are asking for is possible, but I don't think the alternative implementations that you've proposed would not work.

Best wishes

Jeremy.

[Danielo Rodríguez]

I don't see the problem on randomly update the random number. I mean, on any refresh cycle of the wiki.

[PMario]

On Wednesday, November 19, 2014 11:45:43 AM UTC+1, Danielo Rodríguez wrote:

I don't see the problem on randomly update the random number. I mean, on any refresh cycle of the wiki.

What, if it done with every keystroke?

eg:
a random number generator opens a tiddler, depending on the number, in the story view.
So with every keystroke you may get a new / different tiddler.
While there may be cases where we want that, I'd be confused by this behaviour.

-m

[Tobias Beer]

a random number generator opens a tiddler, depending on the number, in the story view.
So with every keystroke you may get a new / different tiddler.
While there may be cases where we want that, I'd be confused by this behaviour.

Not sure I fully understand your example but one thing I find rather confusing is that open draft tiddlers end up directly updating and showing up in lists. While that may have its benefits to see the result before commiting, it adds to the number of not really needed refreshes.

Best wishes, Tobias.

[PMario]

--- OT ---

On Wednesday, November 19, 2014 1:20:24 PM UTC+1, Tobias Beer wrote:

but one thing I find rather confusing is that open draft tiddlers end up directly updating and showing up in lists. While that may have its benefits to see the result before commiting, it adds to the number of not really needed refreshes.

There is a convention, that "end user" facing lists should not contain shadow and system tiddlers. eg: All, Recent and some other sidebar tabs. So the default filter set doesn't contain the $:/ prefixed tiddlers

It turns out, that many <$list...> filters (especially templates) also have !has[draft.of] in them. There was a discussion, to change the default behaviour of the filter to exclude drafts from standard lists. ... It would have meant, to create a big incompatible beta-change, so imo it wasn't implemented.

If you don't like drafts in your list you need to add !has[draft.of] to your filter expression

-m

[Tobias Beer]

Hi Mario,

 

If you don't like drafts in your list you need to add !has[draft.of] to your filter expression

That's not quite the point, though. The point would be to ask: Do we want tw to update the document with things that we're currently just about editing and not even done with? Here's a no to that from my side.

Best wishes, Tobias. 

[PMario]

On Wednesday, November 19, 2014 6:36:58 PM UTC+1, Tobias Beer wrote:

If you don't like drafts in your list you need to add !has[draft.of] to your filter expression

That's not quite the point, though. The point would be to ask: Do we want tw to update the document with things that we're currently just about editing and not even done with? Here's a no to that from my side.

The TW core concept is, that basically every keystroke gets saved back to the TW internal store as a draft tiddler.
If you switch on the "reflow highlighting" in chrome debug tools, you'll see what's going on with every keystroke.

Draft tiddlers are also saved back to the server if there is one. Saving is done, if you stop typing for some time.

So TW core will update drafts and I'm pretty sure, that's not going to be changed.

-m

[Tobias Beer]

The TW core concept is, that basically every keystroke gets saved back to the TW internal store as a draft tiddler.
If you switch on the "reflow highlighting" in chrome debug tools, you'll see what's going on with every keystroke.

Draft tiddlers are also saved back to the server if there is one. Saving is done, if you stop typing for some time.

So TW core will update drafts and I'm pretty sure, that's not going to be changed.

And that's a much appreciated feature, for sure. A fool to complain about that.

So the balance is somewhere between <ensuring nothing gets lost> vs, <everything get's constantly updated>.

I'm progressively a lefty in this one and only hesitantly conservative towards the right side. ;-)

Best wishes, Tobias.

[Jed Carty]

Something that may work for the original question of opening a random tiddler when a button is pressed, and something that I would like to see if possible, is a simple RNG that gets called by a message (like the 'throw the dice' button that can be called by a widget message). That way to implement the 'open a random tiddler' function you initialize the random value into a state tiddler, and then each time you click the button it opens a tiddler based on the current value in the tiddler and updates the value for the next time. Or updates the value and then opens the tiddler, I am not sure how the widget messages are executed so the order may matter.

Some interface like <$button><$action-sendmessage $message='tm-rng' $state=<<placeToStoreNumber>> $range=[lowerEnd, upperEnd] $stepsize=someValue/>Generate Values</$button> could open interesting options for new uses. A parameter that allows you to select the distribution would be interesting, but probably outside the current scope of TW.

On Monday, October 6, 2014 5:37:00 PM UTC-6, Philip Coltharp wrote:

I envision a widget defined like so..  a list in side a button like so.  ( Imagine this was put in a tiddler on http://tiddlywiki.com/)

<$button to="<$list filter="[tag[Widgets]] pick-at-random="1">">Go To Random Widget Tiddler</$button>

         OR

<$button to="<pick-at-random from="<$list filter="[tag[Widgets]]">">">Go To Random Widget Tiddler</$button>

The ideal is to get a button to send a user to a tiddler picked at random from a list.

I could do this in Classic Tiddlywiki but I want to learn Tiddlywiki5.  How might one do this in TW5 differently than in TWC?

[Jeremy Ruston]

Hi Jed

> Something that may work for the original question of opening a random tiddler when a button is pressed, and something that I would like to see if possible, is a simple RNG that gets called by a message (like the 'throw the dice' button that can be called by a widget message). 

Yes, that sounds right to me. It would make a good plugin.

Best wishes

Jeremy

--
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 tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.

[Jed Carty]

There is an example here that uses a plugin I wrote that does what the original poster wanted. Unfortunately you have to manually set the range for the random numbers, but other than that it works as expected.

http://inmysocks.tiddlyspot.com/#RandVal%20Plugin

[Jed Carty]

I wrote a widget that lets the example I linked to open random tiddlers from dynamically generated lists.

[Neil Griffin]

Halfway down this thread, Jeremy suggested an approach for selecting a random tiddler which seemed to me to be the cleanest method.  I don't know if anyone tried to implement this $action-chooserandom widget, so I did it myself and thought I'd share the result.  The notation is essentially the same as Jeremy's suggestion, except I used attribute names with the $ prefix (is there a good reason for the inconsistency on use of $ in different widgets? I often get errors due to guessing wrongly, and sometimes these can be data-deleting errors), and I also have a $field attribute.

My widget can be found here:
http://ng110.tiddlyspot.com/#%24%3A%2Fng110%2Fwidgets%2Faction-chooserandom.js

and an example of use can be found here:
http://ng110.tiddlyspot.com/#Choose%20Random%20Demo

Cheers,

Neil.

[Eric Shulman]

The notation is essentially the same as Jeremy's suggestion, except I used attribute names with the $ prefix (is there a good reason for the inconsistency on use of $ in different widgets? I often get errors due to guessing wrongly, and sometimes these can be data-deleting errors)

The $ prefix is ONLY used for the widget name (i.e., <$name ....>).  Attribute names are just simple keywords.  The $ also is used as a prefix on "system" tiddlers (i.e,. "$:/..."), which can be *transcluded* as parameter values in a widget call (using the {{...}} syntax).  However, this is not an "attribute name"... it's a reference to a tiddler.

enjoy,

-e

Eric Shulman

TiddlyTools / ELS Design Studios

"Inside TiddlyWiki: The Missing Manual"

https://www.indiegogo.com/projects/inside-tiddlywiki-the-missing-manual/x/8816263

YOUR DONATIONS ARE VERY IMPORTANT!

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

   http://TiddlyTools.github.com/fundraising.html#MakeADonation

Professional TiddlyWiki Consulting Services...

Analysis, Design, and Custom Solutions:

   http://www.TiddlyTools.com/#Contact

[Jed Carty]

Neil,

I like it, it is far simpler than how I was doing it, which for something that seems to have as much interest as this does is a very good thing. Could you add an option to pick how many tiddlers are returned? Like

<$action-chooserandom $filter={{SearchText}} $tiddler="SearchResults" $field="randomlist" $pick=5/>

to return a list of 5 random tiddlers you could put in a list widget?

Action widgets use $ for the parameters, I am assuming that is because you can pass (some of) them lists of name=value pairs, like the setfield widget. The $ in needed to distinguish between things like in this example

<$action-setfield $tiddler=SomeTiddler tiddler=hi/>

which sets the field called tiddler of SomeTiddler to hi. I am assuming that $ was picked because it isn't a valid symbol in a field name.

[Eric Shulman]

On Saturday, March 7, 2015 at 8:00:53 AM UTC-8, Jed Carty wrote:

Action widgets use $ for the parameters, I am assuming that is because you can pass (some of) them lists of name=value pairs, like the setfield widget. The $ in needed to distinguish between things like in this example

<$action-setfield $tiddler=SomeTiddler tiddler=hi/>

which sets the field called tiddler of SomeTiddler to hi. I am assuming that $ was picked because it isn't a valid symbol in a field name. 

The $ prefix is used to differentiate parameters used by the widget itself as compared to parameters without the $, which are simply "passed through" to the specific macro or action being invoked by the widget.  For most widgets (except $macrocall and $action-xxx), the parameters do not have the $ prefix.

-e

[Neil Griffin]

I like it, it is far simpler than how I was doing it, which for something that seems to have as much interest as this does is a very good thing. Could you add an option to pick how many tiddlers are returned? Like

<$action-chooserandom $filter={{SearchText}} $tiddler="SearchResults" $field="randomlist" $pick=5/>

to return a list of 5 random tiddlers you could put in a list widget?

How's this?:
http://ng110.tiddlyspot.com/#Choose%20Random%20Demo%202

Neil.

[Neil Griffin]

If the $ is needed in some cases, is there an argument for allowing it for all widget parameters to improve consistency?

As an example of the result of the confusion caused by inconsistency, a couple of times I have neglected the $ in the $tiddler and $field parameters of a $action-setfield widget, with the result that, when activated, the action defaulted to the text field of the current tiddler, overwriting all the text I was working on!  That's extremely annoying, and quite difficult to debug when you no longer have the wikitext that caused the problem!

Neil.

[Eric Shulman]

On Sunday, March 8, 2015 at 9:57:42 AM UTC-7, Neil Griffin wrote:

If the $ is needed in some cases, is there an argument for allowing it for all widget parameters to improve consistency?

Respectfully, that makes *no* sense!  There is a need to differentiate parameters with the same name that are to be handled differently (e.g., "$tiddler" vs. "tiddler").  If all widget params have a $ prefix, we'd still need to invent *another* way to differentiate the parameters.

Also, if *all* widget parameters use the $ prefix, then why have the prefix at all?

As an example of the result of the confusion caused by inconsistency, a couple of times I have neglected the $ in the $tiddler and $field parameters of a $action-setfield widget, with the result that, when activated, the action defaulted to the text field of the current tiddler, overwriting all the text I was working on!  That's extremely annoying, and quite difficult to debug when you no longer have the wikitext that caused the problem!

Changing the syntax won't provide a solution for your specific problem, as you still need to explicitly differentiate the use of the same parameter names, and the underlying cause of the problem is that you *forgot* to do that.  Perhaps the better solution is to have a "developer debugging mode" setting that would add some extra checks with a prompt to confirm before a widget overwrites any data in the store (e.g., "Are you sure you want to change TiddlerName!!fieldname?")...  Maybe it can just check for overwrites for the "text" field, and be limited to widgets that actually use the "$foo" vs "foo" parameter handling, so that it isn't too disruptive during development.  Of course, the setting could be turned off after debugging, so that real-world use would nto be affected.

enjoy,

-e

Eric Shulman

TiddlyTools / ELS Design Studios

"Inside TiddlyWiki: The Missing Manual"

https://www.indiegogo.com/projects/inside-tiddlywiki-the-missing-

manual/x/8816263

Note: the IndieGogo funding campaign has ended,

but direct fundraising continues below...

[Guglielmo]

Hello!

When will a dummy like me be able to install such a great plugin in my tiddlywiki5? I looked for the installation plugin but without success! I hope you can help me.

Thank you!

Guglielmo

[Tobias Beer]

Hi Philip,

Late reply, here's a simple random[] filter.

http://tobibeer.github.io/tw5-plugins/#random (annoucement)

Best wishes,

Tobias. 

[Lotty L]

Hi, sorry I'm very new to this

Whenever I input any of the codes listed here, I may or may not get a button. If I do get a button, once pressed, it will open up a blank tiddler to save part of the code as the title of said tiddler. 

I can't seem to get it to actually randomise my tiddlers

I'm copying and pasting the code into a blank tiddler. Is this incorrect? Is there a specific way to implement the code?