> ... 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 https://github.com/wikilabs/plugins/discussions/62#discussioncomment-560732

[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: https://github.com/wikilabs/plugins/discussions/93#discussioncomment-552214 and https://github.com/wikilabs/plugins/discussions/62#discussioncomment-517037

[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

[pmario]

But isn't the HTML produced by that non-compliant? I thought p blocks inside p blocks should be avoided?

Sure, but custom-markup does not fix your problems with html nesting rules. ... It does, what is configured. ... That's it.

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?

You are right. There are problems with reconfiguration like this.

Conclusion

It can't be used like that. Use tick (´), single (›), degree (°), ... DIV instead!

[pmario]

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

There is a bug. It's probably the same one, that causes erroneous P tags in the core. ... So it may not be fixable in the short run

[TiddlyTweeter]

There is a bug. It's probably the same one, that causes erroneous P tags in the core. ... So it may not be fixable in the short run

It is a shame, as to get best out of Custom Markup, especially when using parameters, its good practice to check the HTML I think, but then it can get a bit confusing having to sort out what is CM and what is the core behavior!

[TiddlyTweeter]

Conclusion

It can't be used like that. Use tick (´), single (›), degree (°), ... DIV instead!

Right!

[pmario]

It is a shame, as to get best out of Custom Markup, especially when using parameters, its good practice to check the HTML I think, but then it can get a bit confusing having to sort out what is CM and what is the core behavior!

I could add some logic, that checks the _endString. If it is a single new-line, I could switch to DIV as the default element. ... BUT ... I personally don't like software, that wants to be "clever". Because most of the times those decisions are "unexpected"

---

I think, I did find a bug in the core with \n and \n\n handling. .. BUT .. I'll have to have a closer look and I need to create some tests to show the problem. ... And even if I can show the problem it's not sure, to get "a fix" into the core, because of backwards compatibility promise.

[TiddlyTweeter]

I could add some logic, that checks the _endString. If it is a single new-line, I could switch to DIV as the default element. ... BUT ... I personally don't like software, that wants to be "clever". Because most of the times those decisions are "unexpected"

Right. I agree. In any case its not yet that clear whether that behaviour (auto-switch p to div) would actually address the issue @AnthonyMuscio is talking about???

[TiddlyTweeter]

@pmario I think, I did find a bug in the core with \n and \n\n handling. .. BUT .. I'll have to have a closer look and I need to create some tests to show the problem. ... And even if I can show the problem it's not sure, to get "a fix" into the core, because of backwards compatibility promise.

In any case, for more advanced users, it would definitely help to KNOW what is going on :-) ... even IF it can't be fixed because of backwards compatibility. My 2 cents,TT

[TiddlyTweeter]

@pmario, sorry to bring it up again, but we touched on the problem a little in the "Nightmare Scenario" discussion starting at https://github.com/wikilabs/plugins/discussions/56#discussioncomment-517332

Basically I'm asking IF one Glyph were dedicated to a SINGLE LINE <p> (i.e. terminates at \n) would that work or would it invoke all same the problems we see with multi-line <p> at the moment?

I'm just wondering?

[pmario]

There is no problem doing this:

\customize angle _element=div

».hl line1 
line 2 
line 3

The only problem the code has atm is, if you want to use a single \n for glyphs, that use a hardcoded \n\n by default.

---

There IS a problem in the code, and there is my resistance to allow this behavior. ... I want to make it possible that "simple" text can be copy/pasted from 1 wiki to an other wiki, without the need to copy "global" definitions.

So there should be a minimal, usable set of rules, that are valid out of the box. ...

[pmario]

It is a shame, as to get best out of Custom Markup, especially when using parameters, its good practice to check the HTML I think, but then it can get a bit confusing having to sort out what is CM and what is the core behavior!

We are discussing a setting here in the issue, that is not intended to be used that way. It causes problems. I'm not sure if it can be used, or if it should be used.

[AnthonyMuscio]

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

Mario,

The Pilcrow typically delineates a paragraph, so perhaps this should be <p> default rather than <div>?

Here is a piece of reworked text for in https://wikilabs.github.io/editions/custom-markup/#Custom%20Markup%20Definition

; Glyph
: Block: `tick (´), single (›), degree (°)`, Paragraph element default (divides with blank line)
: Block: `angle (»), approx (≈), pilcrow (¶)` Div element default (divides with one new line)
: Inline: `braille ⠒ ⠶`, `corner 『 』`, `slash /° °/` Used inline in text 

If you swapped pilcrow with Degree to alter this?

[TiddlyTweeter]

For @AnthonyMuscio - Demo of a simple method to do SINGLE lines as paragraphs

@pmario It can't be used like that. Use tick (´), single (›), degree (°), ... DIV instead!

(PS: This approach works well in the Editor as you can easily apply the glyph in BULK to any number of lines.)

Hope the code explains itself ...

\customise degree _element=p _classes=".tony-style" _mode="inline" style="margin:0;"

This example works well because `_mode="inline"` _helps produce compliant HTML_ with glyph `°` re-assigned to `<p>`. 

» Glyph `» ` Line 1 - WILL  "eat" adjoining lines IF they are AFTER ... because of //hard-coded// `\n\n`
° ''Line 2''

° Glyph `° `. Line 3 - WON'T "eat" adjoining lines because of //hard-coded// `\n`
° `° ` Line 4
° `° ` Line 5
» `» ` Line 6 - WON'T "eat" adjoining lines IF they are BEFORE

Result ...

[TiddlyTweeter]

@pmario We are discussing a setting here in the issue, that is not intended to be used that way. It causes problems. I'm not sure if it can be used, or if it should be used.

Right. My sense is it is very probably not needed. FWIW I find it hard to think of a use case where a "regex end-pattern" would have a relevant role in CM _endString= ???

[pmario]

@AnthonyMuscio It is defined:

Block: tick (´), single (›), degree (°), ... DIV ... divides with one new line used:

› line 1
› line 2
› line 3

Block: angle (»), approx (≈), pilcrow (¶) P element ... divides with blank line

used:

».hl line 1
line 2 
line 3

» next paragraph

line with some text, that will be created as P from TW core

The .hl class is used to show linebreaks.

[pmario]

With the current core paragraph handling this can't happen. We can have a closer look after this PR has been merged. ... If it ever will be merged.

[TiddlyTweeter]

Understood. I had a look at the PR and realized I had commented into it over a year ago.