I think if people want a detailed split, then they should use the slicer
edition. The SE uses the sax.js library to break down things atomically.
However, even it doesn't always get it right -- you see remainders of HTML
tags in the sample split. The problem with the slicer edition is that the
result isn't really portable -- it needs to be viewed inside the slicer
edition, AFAIK.
My thinking now is to have 3 split options, probably from a dropdown menu:
no split, split by \n\n, and split by self-defined category. So if you
wanted to split by the horizontal markup ( ----\n) you could do that.
Otherwise, there's probably an unlimited number of ways people could think
to split things.
I'm also thinking of adding the ability to allow the user to join up the
next X items. So you could join the next 3 paragraphs to the current
tiddler, mark them as "no split", and just keep that as one "semantic
unit.". Behind the scenes, the original paragraphs would be deleted.
On Sunday, May 31, 2020 at 4:40:07 AM UTC-7, TiddlyTweeter wrote:
>
> springer
>
> I think he's doing very Good. "\n\n+" is a primary marker in actual
> written WikiText. It is a fundamental *separation unit.*
> Seems a very Good DEFAULT to split on after blanks.
>
> *BUT *I'm sure Mark S. is aware you could split differently. SINCE blocks
> like this ARE an issue...
>
>
> <<<
> My Hamster went feral.
>
> --Pet fallacy
> <<<
>
>
> *A line START, After "\n\n" is *"<<<". It is likely easy to find
> (simplifying slightly) regex = "\n{2,}<<<\n".
>
> The ISSUE I think is any idea you need read blocks to do basic
> splitting. I don't think you do in WikiText. *Merely regex for start of
> block*.
>
> I think the issue is whether you looking to "Protect" blocks within a
> COMPLEX parser, OR could be happy with INCREMENTAL SPLITTING.
>
> What do I mean? You use a SERIES of <<noto tag>> to reduce your WikiText
> to smaller fragments in order matched to use case. Rather than a
> blunderbuss complex code.
>
> The point being only that START string should be enough most of the time
> in actual WikiText usage.
>
> Ask if this is not clear.
>
> I footnote this with being explicit I don't actually know Mark's intent.
>
> Best wishes
> TT
>
>
>
>
>
>
>
> On Sunday, 31 May 2020 03:07:22 UTC+2, springer wrote:
>>
>> Why not simply have noto refuse to split any paragraphs that would break
>> any unresolved markup syntax? So
>>
>> <<<
>> Three things I have trouble remembering...
>>
>> 1. When...
>>
>> 2. Why...
>>
>> 3. What was the question?
>>
>> <<< —Somebody
>>
>>
>> would not get split up, nor would
>>
>> @@float:right; If I don't try...
>> <hr>
>>
>>
>> I won't succeed.
>> @@
>>
>> That would suffice for most of my use-cases; if things belong together as
>> an assertion-like unit, I'm often "wrapping" them in some way or other...
>> Also, it seems that whenever we *do* use markup syntax, we will get weird
>> effects if the opening and closing markup end up in different tiddlers. So
>> this would be a good default behavior.
>>
>> -Springer
>>
>>
>> On Saturday, May 30, 2020 at 5:13:40 AM UTC-4, bimlas wrote:
>>>
>>> As a matter of fact, the problem with this solution is that the essence
>>> of the plugin would be lost. Then we need to approach the problem from the
>>> other side:
>>>
>>> For example, putting a space in an empty line would not cut the
>>> paragraph into pieces. However, this space must be deleted before saving
>>> the tiddler in order for the text to actually appear as two paragraphs. But
>>> if you delete it, the next time you edit it, there would actually be two
>>> paragraphs, so the plugin would want to split it.
>>>
>>> That's not a good solution either ... I still have to think about
>>> something useful.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/bfaf7611-011e-4e84-ac58-dffdf2588fbe%40googlegroups.com.
