Filter to change Applepie into ApplePie

[Mat]

A list of arbitrary but alphabetical words

Applepie Banana Cherrypie Durian Elderberry ...

I want change all "pie" string fragments into "Pie" so it reads

ApplePie Banana CherryPie Durian Elderberry ...

 

in this arbitrary but alphabetical list of words.

Does anyone have an idea for an efficient filter for this? 

Thank you!

<:-)

[Mark S.]

Maybe

<$list filter="[list[]removesuffix[pie]addsuffix[Pie]][list[]!suffix[pie]]+[sort[]]"/>

[Mat]

Mark S. wrote:

<$list filter="[list[]removesuffix[pie]addsuffix[Pie]][list[]!suffix[pie]]+[sort[]]"/>

Ah - two separate list treatments! Brilliant!

<:-) 

[TonyM]

Nice!

[Mat]

Darn... turns out it ain't quite enuff. OK, here's the real issue I'm trying to solve:

I'm trying to extract the widget names from the actual js widgets in order to create links to their respective widget doc on tiddlywiki.com. The goal is a selectwidget where the user selects a widget title to get its docs show up in iframes.

The problem is thus about reshaping the widgets js code names into tiddlywiki.com doc title format, i.e CamelCase.

The initial extraction is done like so:

[all[shadows]prefix[$:/core/modules/widgets/]removeprefix[$:/core/modules/widgets/]removesuffix[.js]splitbefore[/]!suffix[/]]

which gives this:

action-createtiddler
action-deletefield
action-deletetiddler
action-listops
action-navigate
action-sendmessage
action-setfield
browse
button
...

From here, the exact manipulation depends on the title. E.g "browse" merely needs a capital initial, whereas "action-creattiddler" should become "ActionCreateTiddler". First this filter is added:

sentencecase[]split[-]sentencecase[]join[]

so "action-creattiddler" and all the other such formatted become ActionCreatetiddler where only the capital T, for tiddler, is missing.

Thus my original question - but I missed to clarify that there are multiple suffixes that must also have uppercase initial:

field
tiddler
message
block
mangler
variables
catcher
call
(possibly some more) .

Here's the full construct thus far:

<$list filter=' [all[shadows]prefix[$:/core/modules/widgets/]removeprefix[$:/core/modules/widgets/]removesuffix[.js]splitbefore[/]!suffix[/]addsuffix[ ]sentencecase[]split[-]sentencecase[]join[]split[ ]addsuffix[ ]]'/>

Marks clever idea was in deed good for my simplified case with only one suffix but can anyone come up with something efficient also for this problem with multiple suffixes?

For my use case, one may argue that the complete list is not overly long so it could as well be a static title list - but the solution should not have to be modified if new widgets are added. In deed, the suffix list would still need to be hard coded but these are (hopefully) less likely to change.

The whole concept is part of a much more general thingy soon to be released :-)

Thank you!

<:-)

[Mat]

Merde... I accidentally pasted the link to my secret project. Oh, well. Just note it is not ready yet if you do go there.

<:-)

[PMario]

On Tuesday, February 18, 2020 at 8:49:57 AM UTC+1, Mat wrote:

...

which gives this:

action-createtiddler
action-deletefield
action-deletetiddler
action-listops
action-navigate
action-sendmessage
action-setfield
browse
button

I know, that an algorithm will be more flexible, if new widgets are included, but for me this looks like a problem, that could be easily solved using a lookup table.

eg. widget-docs-lookup .. a data-tiddler ... see attachment.

This code:

<$list filter='[all[shadows]prefix[$:/core/modules/widgets/]removeprefix[$:/core/modules/widgets/]removesuffix[.js]splitbefore[/]!suffix[/]]'><$text text={{{[[widget-docs-lookup]getindex<currentTiddler>]}}}/><br></$list>

Will list all the docs tiddlers. and needed 15 minutes to create it and 10 minutes to test.

There are several widgets, which have no docs. That's intentional. The data tiddler gives us a possibility to address this, with links to explanations. Or use n/a as an additional filter to remove those elements.

just a thought.

mario

[Mat]

Much appreciated input Mario.

I know, that an algorithm will be more flexible, if new widgets are included, but for me this looks like a problem, that could be easily solved using a lookup table.

While a lookup table might be a better solution, I don't understand how it would deal with new widgets. Presumably the table would need to be updated also.

 

This code: 

<$list...

Will list all the docs tiddlers. and needed 15 minutes to create it and 10 minutes to test.

No, the intention is for the list to appear as options in a listwidget. So only the selected widget docs will appear. I have it working and it's fast.

 

There are several widgets, which have no docs. That's intentional.

I was not aware of this. Good to know.

 

The data tiddler gives us a possibility to address this, with links to explanations. Or use n/a as an additional filter to remove those elements.

Good thinking!

Regarding the new widgets problem, i.e "new" as in ones that don't appear in the lookup or are intentionally excluded, these could perhaps be detected and alerted about in the lookup.

<:-)

[Mat]

@pmario

Hmmm... come to think of it, if there is no automatic handling of added widgets, is there any benefit with a lookup table instead of just a plain static list with the doc titles?

<:-)

[Mark S.]

The problem is that you are attempting to find a "logical" approach to what is fundamentally a "human" problem --

There is no "logic" (at the string level) to how things are named. As far as electrons are concerned,

TiddlyWiki makes as much sense as TiddlYwiki .

A somewhat harder, but more reliable approach, might be to grab the text from the widget tiddlers. At the

bottom of each tiddler is text like:

exports.setvariable = SetWidget;

where you could, hypothetically, extract the widget name. Unfortunately, for the "action-" tiddlers, you're

going to have to append "action" since they're named differently (did I mention names weren't logical?)

[TiddlyTweeter]

Ciao Mark & Mat

In the specific case I think it would be possible to capture and chunk the thing ("action-dothing" etc as "((a)ction) ((d)o) ((t)hing)") via regex (complex, but possible for all variants). I think the issue is that TW filter regex don't return capturing groups so you can't leverage it? Also need function for return of Uppercase.

Thoughts

TT

[Mat]

Mark S. wrote:

A somewhat harder, but more reliable approach, might be to grab the text from the widget tiddlers. At the

bottom of each tiddler is text like:

exports.setvariable = SetWidget;

where you could, hypothetically, extract the widget name. Unfortunately, for the "action-" tiddlers, you're

going to have to append "action" since they're named differently (did I mention names weren't logical?)

 Great observation! The following reveals some inconsistencies in the widget codes:

<$list filter="[all[shadows]prefix[$:/core/modules/widgets/]]">
<$set name=text filter="""[<currentTiddler>get[text]]""" >
<$set name=name filter="[enlist<text>reverse[]first[3]last[]removesuffix[;]]" >
<<name>><br>
</$set>
</$set>
</$list>

We can note that ActionListopsWidget does have the Action prefix. 

It seems the Edit-text widget is formatted differently. 

And there's "something" with both LinkCatcherWidget and SelectWidget.

Ought these things be "harmonized" (in which case this approach might be useful) or are they actually implemented as they should be?

<:-)

[Mat]

TiddlyTweeter wrote:

capture and chunk the thing ("action-dothing" etc as "((a)ction) ((d)o) ((t)hing)") via regex (complex, but possible for all variants).

In "action-dothing", there's no obvious way to split "dothing" though, except if I predefine the "thing" parts (which is doable - seems to be less than 10). 

 

I think the issue is that TW filter regex don't return capturing groups so you can't leverage it?

Yeah... my spontaneous feeling is that it would take a lot of separate setwidgets, each one filtering out its respective kind (i.e the "thing" in "action-dothing") and one list that removes all these, and then merge them all into a list +sort. Ugly.

Also need function for return of Uppercase.

Thankfully exists: sentencecase operator 

It seems there are a few "almost solutions" but nothing spot on so far, so I'll put this issue on the back burner for now. It is but one semi-independent part of a more general concept.

Thank you for your input amigos!

<:-)