An unfortunate delimiter

Tinderbox Tasks
1

I’ve got an amount of text which separates two sections with a sequence of 3 ‘?’. I’ve tried to explode these notes using a delimiter like so “\?\?\?”. This doesn’t work which is confusing. More odd, however, is that repeated access to the ‘explode note’ pop up shows the delimiter growing. Each time it seems that the '' are escaped again …

While the delimiter may be unfortunate it seems that I should be able to manage this with a properly escaped sequence. Does anybody have advice ?

The ever-growing escape sequence came to my notice when it locked up my document. Once I enter the delimiter sequence \?\?\? the delimiter grows each time I access the ‘explode note’ panel.

unfortunate-delimiter.tbx (75.1 KB)

In an effort to move along I tried to create a stamp to replace the three ‘?’ with ‘===’ like so:

$MyString=$Text.replace(“\?\?\?”,“===”)

This also fails, however I am able to use the buit-in find/replace in the text pane.

2

I’ve just tried this and ??? with no delimiters works for me.

What’s odd, as you say, is that when you re-open the Explode dialogue, the ??? has become \?\?\?. Not sure why that is, but the initial ‘bare’ explode does work.

3

I find ??? does work, although new note #2 incorrectly has a blank line at the beginning. So the residue of the delimiter’s empty title remains. Use ???\n for the correct result.

@brookter is correct to note that on second invocation of explode (in the same app session) the last used delimiter becomes \?\?\?. One the third invocation \\\?\\\?\\\? †. Best to reset the delimiter string manually before use.

Aside \?\?\? ought to work as it implies ‘3 successive (literal) question mark characters’. It unambiusously signals these question marks should not be interpreted in their regex sense. In fact, the reverse seems to occur.

†. (For @eastgate this feels like a glitch. I wonder of the action code parser changes in b708 had a side effect here?)

1 Like
4

I agree the I’d expect ??? to do the trick. I’ll investigate.

5

??? but `???\n" gives a cleaner removal of empty lines/paragraphs.

The recursing escaping of the custom delimiter string does seem to be a new issue.

6

I understand the recursing escapes.

A side question is that I think the current design is wrong.

  1. In the beginning, be broke on literal delimiters. This was inflexible.
  2. Then, we broke on regular expressions. This was flexible! But it also confused users who expected … and *** and ??? to be useful delimiters.
  3. Now, we automatically escape special characters in the delimiter, which (a) is causing this error, and (b) also removes most of the advantages of having regular expressions.

I

7

At the risk of ‘more’ UI, might an literal/regex boolean control be away round this: default, use literal strings. I think that would align with new user expectations. Seasoned hands could turn on regex if wanted.

2 Likes
8

I found myself looking for exactly this affordance. :ok_hand: