we have filter regex, but what about a filter replace?

133 views
Skip to first unread message

TheDiveO

unread,
Feb 28, 2017, 12:19:31 PM2/28/17
to TiddlyWikiDev
Actually, I would like to develop a filter to extract some multi-digit number from tiddler titles to be used in list filter magic. Remembering Jeremy's motto of better doing it more universal, where appropriate, I'm asking here about the design of a "replace" filter: the bad twin of the regex filter. I would like to hear feedback on my idea, and the design.

Would you deem such a filter of broader use?

And how do I overcome the limitation of filters to have only one operand? For a replace filter I would need the regex, and also the replacement expression. So, two operands. Is there a better way than to simply string these two operands together, with some strange delemiter between them, such as ::?

Any feedback and help greatly appreciated!
TheDiveO

Mat

unread,
Feb 28, 2017, 10:01:54 PM2/28/17
to TiddlyWikiDev
Spontaneous thought (...at 4 a.m so possibly gobbledigook)

Replacing something is a pretty complex action. Still one that is doable using a wikitext macro consisting of various subfilters that split out the first part of the string, remove the out-string, append the chaing-in, append the rest of original, etc. (I did this in cherrypicker and probably @ttention)

Sooo... if the aim is to make a general operator... how about a "macro operator" that takes the filter run output at that point and uses it as input to a user made wikitext macro. The output is then passed on to the rest of the run. E.g:

\define foo() $input$bar (or maybe even just $$, i.e $$bar here)

[tag[grok]macro[foo]suffix[bar]] (gives some true result)


This would solve your need and just in general be a super powerful operator, AFAICT.

<:-)

PMario

unread,
Mar 1, 2017, 7:18:28 AM3/1/17
to TiddlyWikiDev
Hi,

At the moment, the regexp filter is just a "search" filter. So what you want to have is a .match() with different "group" return values. right?

eg:

^/?/?/?([-A-Z0-9.]+:?/)?([-A-Z0-9/%._]*/)?([-A-Z0-9/%._]*$)


applied to: c:/path/to/file/filename.txt

will give us 1 match and 3 groups:

Match 1:    c:/path/to/file/filename.txt   0        28
Group 1:    c:/                            0         3
Group 2:    path/to/file/                  3        13
Group 3:    filename.txt                   16       12


At the moment filters can only check for Match 1: ...

So stealing Mat's idea, we could use variables like:

$(g1)$, $(g2)$ .. for Group 1: and Group 2:  .... and so on
$(m1)$ ... for Match 1:

Those variables would need to be created by [match[regexp]]

we could create a filter like:

[match[regExpGoesHere]replace<variable>]

where variable can be

\define variable() filename: $(g3)$

just an idea.

have fun!
mario

PMario

unread,
Mar 1, 2017, 7:22:07 AM3/1/17
to TiddlyWikiDev
The problem with regexp's, I see is performance. If done wrong they can considerably slow down list creating. ... And I'm sure, there will be a lot of problems, since regexp creation is a science of its own.

-m

Thomas Elmiger

unread,
Mar 1, 2017, 3:39:03 PM3/1/17
to TiddlyWikiDev
Hi TheDiveO

I made something similar to Mat’s Cerrypicker, a pure wikitext macro: https://tid.li/tw5/hacks.html#%24%3A%2F_telmiger%2Fextract

Maybe this can be an inspiration or show you the limits of splitbefore combined with prefix and suffix juggling …

Good luck!
Thomas

TheDiveO

unread,
Mar 2, 2017, 2:44:04 PM3/2/17
to TiddlyWikiDev
Thank you very much for all the feedback and interesting ideas, much food for thought!

As for performance: a dedicated filter optimized to my task surely is easy to write. But I doubt that it would be faster for the kind of regex I have in mind than the more generic filter on top of s.replace() -- mainly, because no backtracking would be involved.

As for the macro trick: yes, that may be workable, but if I need to explain that to me a few weeks down the road I would never understand  (again). On thing my daytime job taught me is that no every hack that is cool is maintainable in the long run and this isn't desirable. I'm afraid that such a filter trick would effectively turn its own design into a non-general-purpose filter. I appreciate its cleverness, though.

TheDiveO

unread,
Mar 2, 2017, 2:52:24 PM3/2/17
to TiddlyWikiDev
I noticed splitbefore before, but it does not what I want to achieve; I wasn't exactly clear on that I now notice. In my application I'm not sure that the selection contains titles that will match the regex. Those titles are to be removed from the selection. Titles that match need to undergo a replacement operation. So not so general anyway.
Reply all
Reply to author
Forward
0 new messages