How modify this regexp?

[Mat]

Original post deleted because I...um... misunderstood my own question. 

This also means that the first few posts refer to the old question.

Instead jump down to my post starting with: "More compact"

<:-)

[PMario]

Hi Mat,

How can this regexp be modified to accept any text that has <<foo ...... >>

For me this:

<$set name=re value="<<foo.*?>>">

{{{ [all[tiddlers]prefix[Draft]!is[current]regexp:text<re>] }}}

</$set>

does the trick.

-mario

[PMario]

Hi,

I did modify the code in the first post to use a regexp: <<foo.*?>> ..

The first version was greedy so it found: <<foo test>> some more text >> instead of <<foo test>>

-mario

[PMario]

Hi Mat,

The best description about regexp I've ever found is: https://www.regular-expressions.info/javascript.html

They describe it in a way that I actually could understand and modify by myself.

-mario

[PMario]

Hi,

Are you sure, you want prefix[Draft]  instead of !prefix[Draft] ?? 

It only detects tiddlers in draft mode atm.

-m

[Mat]

Much appreciated that you're looking at this!

...and your post makes me realize I am asking the totally wrong question (Doh!!! I got confused from dabbling with this so I forgot what I'm actually in need of)  :-/ 

The actual need is to catch the unclosed <<foo in this text, potentially surrounded by completed <<foo>>

Lorem ipsum

Lorem ipsum <<foo bar>> lorem impsum <<foo lorem ipsum <<foo>> and <<foo bar>> lorem.
...

Sorry for confusion and never mind the prefix[Draft] bits, they're not important, I should have removed them.

Again, I appreciate your and anyones help as I don't master regexp sufficiently.

<:-)

[PMario]

On Saturday, March 7, 2020 at 9:33:11 PM UTC+1, Mat wrote:

The actual need is to catch the unclosed <<foo in this text, potentially surrounded by completed <<foo>>

hihi, .. That's a different thing :)

 

Lorem ipsum

Lorem ipsum <<foo bar>> lorem impsum <<foo lorem ipsum <<foo>> and <<foo bar>> lorem.
...

So the end of the line should stop a search. right?

If << comes up again .. there is a problem, so it should return the tiddler name. right

Is there a different "stop" indicator than << ?

-m

[Mat]

Lorem ipsum

Lorem ipsum <<foo bar>> lorem impsum <<foo lorem ipsum <<foo>> and <<foo bar>> lorem.
...

I think it can be phrased as:

Find the first "<<foo "

...that is not followed by ">>" nor "....>>" (where .... signifies any characters)

...OR that IS followed by "<<" or "....<<" (or, for that matter, any other forbidden characters inside a short form macro call)

But the end of the line should not stop the search.  The point is to catch the first uncomplete "<<foo" macrocall however long the tiddler text is.

<:-)

[Mat]

More compact:

Find the first "<<foo "

...that is not followed by "....>>"   (where .... signifies any number of characters, including none)

...OR that IS followed by "....<<"  or character/s that is forbidden inside a short form macro call.

(This is pretty difficult to get right.)

<:-)

[PMario]

I think, the same problem applies that Jeremy had, to detect this pattern. So if it could be detected, it would be valid syntax.

IMO you can _not_ detect this pattern in 1 run. You would have to find every appearance with: <<foo[^<]*  which finds <<xxxx<< ... In a second step you have to see if xxxx contains >> .. If yes -> OK ... If no problem.

1 regexp filter can't handle this. Especially, since our filters return tiddler names and not regexp capture groups, which would be needed.

-m

[Mark S.]

On Saturday, March 7, 2020 at 2:03:23 PM UTC-8, PMario wrote:

1 regexp filter can't handle this. Especially, since our filters return tiddler names and not regexp capture groups, which would be needed.

PR 2963

[Mat]

IMO you can _not_ detect this pattern in 1 run. You would have to find every appearance with: <<foo[^<]* which finds <<xxxx<< ... In a second step you have to see if xxxx contains >> .. If yes -> OK ... If no problem.

OK, I don't think it is necessary with one step for EditorMagic considering how it is the text of a single tiddler that is searched so it should be pretty fast regardless. With <<foo[^<]* as a start (thank you!) I'll see what I can come up with.

<:-)

[Mat]

Mark S. wrote:

PR 2963 

 

i.e Returns text of input selection that matches regexpr - yes, that would be needed here.

I would also think #4452 Memory variable filter ops is relevant here to enable doing this in a single step.

(Hm, why do my projects hit the outer limits so often?)

<:-)

 

[TiddlyTweeter]

(Hm, why do my projects hit the outer limits so often?) 

I think at least two of your recent ones are related to the current lack of a way under the TW rexexp filter operator to be able return capture groups.

This limits what you can do with regex in filters and requires a kind of coding jujitsu to get around.

TT

[TiddlyTweeter]

PMario wrote:

The best description about regexp I've ever found is: https://www.regular-expressions.info/javascript.html 

They describe it in a way that I actually could understand and modify by myself. 

I agree. There is a depth of context in that site that is very helpful in understanding regex in TW.

(I personally also use the specialized commercial  tools (RegexBuddy, PowerGrep) that Jan Goyvaerts wrote.)

TT

[TiddlyTweeter]

Ciao Mat

I'd also test this with "<<foo[^<]*?". The final qualifier "?"  means that "not <" will only march along the scope to the character just before the first proximal occurrence of "<". Under some conditions, without it, it might match the final occurrence.

TT

[TiddlyTweeter]

(This is pretty difficult to get right.)

Its a very interesting regex issue. Regex often looks counter intuitive. Using negatives can get complicated.

It IS possible to match the needed in one regex. But you would have to chop off the suffix since we can't currently do that by silent non-capturing, then reinstate it so that the "<<" becomes ">><<"

(<<foo([^>])*?)([<]{2})

That matches this ...

--|match|--

<< suffix to replace

TT

[Mat]

TT - that does seem to work! Great!!!

For anyone curious, I have this:

A tiddler with this arbitrary text

title:tid
text: Welcome to TiddlyWiki <<foo , a unique [[non-linear]] xx <<foo bar>>notebook for.

And this is my testing code (at the moment):

<$set name=re value='(<<foo([^>])*?)([<]{2})'>
<$set name=txt filter='[[tid]get[text]]'>
txt: <<txt>><br><br>
list: <$list filter="[{tid}regexp<re>splitregexp<re>]">

</$list>
<br>
<$set name=pre filter="[{tid}regexp<re>splitregexp<re>first[]]">
pre:<<pre>>
<br><br>
<$set name=target filter="[{tid}regexp<re>splitregexp<re>nth[2]]">
target: <<target>>
<br><br>
<$set name=post filter="[{tid}regexp<re>splitregexp<re>rest[2]]">
post: <<post>>
</$set>
</$set>
</$set>
</$set>
</$set>

To be clear, the application in EditorMagic is to be replace the incomplete macro call with a complete one and to keep the surrounding text (the pre and the post) intact. In the above setup, the "target" contains

 <<foo , a unique [[non-linear xx ]]

Other than the added square brackets that mess up the link ([[non-linear]]) I'll have to split the real target, i.e <<foo from the rest and prepend the rest to the "post" text. So ideally, the regexp would cover that IF it says "<<foo blabla <<" THEN it should ONLY capture "<<foo" rather than include the blabla with it. I'm guessing this is too complex for a regex and will have to be done manually. 

<:-)

[Mat]

Meanwhile, I added this request at gh:

Filter op to extract regexp from string

which argues for a set of filter ops (or even a single filter op) that stems from the most basic use case I can think of. 

Do go there and express your agreement or disgust over it. ;-)

<:-)

[TiddlyTweeter]

 Mat wrote:

TT - that does seem to work! Great!!!

It should work fine.

The two cases it will fail in are ...

-- When the problem is nested (I don't think that will happen for the OP).

-- When the item is the LAST in sequence. (That can be addressed but avoid it if it its not absolutely needed as it will make the regex very complex)

TT