I imported an RTFD file and then exploded it and introduced some edits. When I left the note and came back, the edits were all GONE.
I’ve pasting the content of the RTFD file onto a note and it does not work either.
I am enclosing a link to the file, any of the exploded notes in the article behaves this way. The article contains many graphic files, so it’s a bit heavy.
Thanks for your help.
Pablo
Well, for the record, it… fixed itself.
I wonder whether (a) there are note name collisions, or (b) you had several equivalent explodes, and edited explode 1 but returned to explode 2.
A note created by Explode… is really just like any other note.
yes, I realize it had nothing to do with the Explode function.
It was the note itself, the RTFD, and the exploded notes inherited whatever was going on.
And then it all stopped. So perhaps there was a lag processing the file after import before it started behaving like a normal note.
I just downloaded my own file and I cannot reproduce the problem.
Thanks
One thing Explode allows us to do is an action on the exploded notes, or apply action code via the “Exploded Notes” prototype. A poor choice of code there can be a portal to all sorts of unexpected hilarity.
Where using Explode to to anything more than just split a $Text into a series of notes it pays, from experience, to do iterative experiments adding extra things like actions only once the basics work as expected. “as expected” is the watchword. It’s not that Explode is flakey but rather that it does what you tell it to and that might not be what you assumed you’d told it, with all the resultant scope for unexpected outpcomes.
This comes to mind as whilst writing this I’m tinkering with an Explode process. 
thank you.
This is what happened: I decided to use a delimiter to split my document (about a 30 page doc). So I went through the note and added ******* at the points I wanted to split.
When I went to Explode, the ****** were gone.
I did that twice and the edits would not hold. SO I did a double space /n/n in the original RTFD file and imported again, split along that delimiter.
But now every note had that characteristic: the edits would not survive my leaving the note and coming back to it.
And then… long story short, it fixed itself.
So I think it’s RTFD import- related, not on the Explode process.
***** is a uniquely unfortunate choice for an Explode delimiter.
Explode delimiters are regular expressions — patterns with wildcards and the liked. The asterisk has a special meaning in regular expressions: 0 or more occurrences of the preceding pattern.
I went to check my docs on Explode, which notes:
This is either a literal string (i.e. the actual characters to match) or a regular expression.
I realise it should say:
This is a regular expression (which can be a the literal characters to match), but all regex control characters must be escaped.
Listing regex control characters is out of scope (it’s a lot of info) but it should alert users to the fact that the error may be user error in the input. IOW, don’t use regex before taking a moment to understand that.
The last isn’t meant unkindly to @Avantango, but reflects my own experience making many such mistakes in the past. We’d like the app to say “you just did something you didn’t, on reflection, mean to do”. But if we feed it valid-but-wrong input, how would the app know the difference?
Still, I’ll revise my aTbRef notes on this. The above should help—a little.
***** is a uniquely unfortunate choice for an Explode delimiter.
Yeah, I can see that in hindsight! I don’t know why I reached for that key frankly. I’m a newbie so it was a monkey with a typewriter moment.
The second time I did it my delimiter was 12345/n and it still did not work.
Hard to help further without an example TBX showing the problem (the forum allows TBX upload). Often in this context there are other unseen configuration errors affecting the result.
[Said as one who genuinely has broken Explode over the years—but most often through my errors!]