> ... An example may be, terminate with the end string \n\keyword\n note \k (is undefined and ignored just uses \ .

[pmario]

... An example may be, terminate with the end string \n\keyword\n note \k (is undefined and ignored just uses \ .

Have to have a closer look

Originally posted by @pmario in #62 (reply in thread)

[pmario]

The problem with \n as _endString is, that the regexp needs to look like this: \\r?\\n. It needs some escaping and unix / windows adjustments.

[TiddlyTweeter]

The problem with \n as _endString is, that the regexp needs to look like this: \\r?\\n. It needs some escaping and unix / windows adjustments.

It is an interesting issue. One of the tech things about TW I actually understand is that a lot of it uses regex, especially in parsing. My understanding is it is quite difficult to have "raw" inter-working with regex from the actual TW HTML (though its often used in the JS)?

I'm a big regex fan :-) BUT I'm not sure that exposing it in CM would necessarily be a good idea? I think it could be confusing?

Just side thoughts.

[pmario]

.. BUT I'm not sure that exposing it in CM would necessarily be a good idea? I think it could be confusing?

That's exactly the thing. .. It can be confusing, because "What you see is not what you get"

[pmario]

@AnthonyMuscio ... The following example already works on unix like systems, but may fail on windows.

\customize angle _endString="\n" _mode=block

» test
line 2 

some more text

[pmario]

The following should do on both windows and linux ... I can only test it on linux atm.

\customize angle _endString="\r?\n" _mode=block

» test
line 2 

some more text

[TiddlyTweeter]

The following should do on both windows and linux ... I can only test it on linux atm.

\customize angle _endString="\r?\n" _mode=block

» test
line 2 

some more text

It doesn't work on my Windows tablet ... I get 3 paragraphs inside a paragraph ...

<p class="wltc-l1 wltc"><p>test</p><p>line 2 </p><p>some more text</p></p>

[pmario]

That's exactly, what it should do.

[AnthonyMuscio]

@pmario

If I use the following;

» test
» test2
line 2 

Then test and test 2 either have an additional line between them or a large line size.
Looking at the html I see its paragraphs;
<p class="wltc-l1 wltc"><p>test</p><p class="wltc-l1 wltc"><p>test2</p><p>line 2 </p><p>some more text</p></p></p>

So I imagine I need to use an alternate element to avoid these larger gaps, for my work through of key uses and use of quick additional mark-up while typing.

Tony

[AnthonyMuscio]

I note Curious handling of the "before" in this below, the \r? is it regex or JS encoding?, to find the meaning!

This looks good that such "special characters"/"Patterns" can be used.

\customize angle _endString="\r?\n" _mode=block

» test
line 2 

some more text

before
» test
» test2
line 2 

some more text

[pmario]

The "gap" comes from the default CSS for wltc, which you will need to change. see: #93 (comment) and #62 (reply in thread)

[pmario]

I note Curious handling of the "before" in this below, the \r? is it regex or JS encoding?, to find the meaning!

Yes, that's "regexp" encoding. ... And it "works by accident" ... It wasn't meant to be used that way. ... I'll have to have a closer look, if it is consistent and will reliably work.

You know the whole project is still beta!

[pmario]

There are the styles used in the edition atm. ... Some of them will directly go to the plugin ... not all of them.

https://wikilabs.github.io/editions/custom-markup/#Predefined%20Stylesheets

[pmario]

So I imagine I need to use an alternate element to avoid these larger gaps, for my work through of key uses and use of quick additional mark-up while typing.

There are 3 glyphs, that use P by default, and there are 3 glyphs which use DIV.

tick (´), single (›), degree (°), ... DIV

angle (»), approx (≈), pilcrow (¶) ... P

[TiddlyTweeter]

@TiddlyTweeter <p class="wltc-l1 wltc"><p>test</p><p>line 2 </p><p>some more text</p></p>

@pmario That's exactly, what it should do.

But isn't the HTML produced by that non-compliant? I thought p blocks inside p blocks should be avoided?
I am aware that some parser in TW does add surplus p containers sometimes.
But in the example output code the outer containing p is what is inserted by Custom Markup I think?

Not trying to be awkward. Just trying to understand what is happening! TT