Custom markup (continued 4)

544 views
Skip to first unread message

PMario

unread,
Oct 27, 2020, 11:19:19 AM10/27/20
to tiddly...@googlegroups.com
Hi folks,

This is the continuation of 
 - Custom markup [1]
Let's start a new one before [3] starts to use pagination.
Have a closer look at link [1] it's possible to show all the topics in 1 page


have fun!
mario

PMario

unread,
Oct 27, 2020, 1:04:13 PM10/27/20
to TiddlyWikiDev
Hi,

V 0.7.0 - 2020-10-23

  • New Inline functions
    • _symbol.class.clsss:param:param some text__
    • .class and :param work the same way as "block" definitions
  • Removed underscore from "block" definitions, because it's used by "inline"
  • Added: \\ pragma comments
    • It's faster than HTML comments <!-- comments -->, since it can be used outside macro \define x() blocks

NO \customize inline functions yet.



As you can see in the code below there are 4 possibilities atm.  I intend to reduce them to 2 if possible!

a)
 - start: 2 underscores: __
 - end: 3 underscores or 1 underscore slash : ___ or _/

b)
 - start: /°
 - end: °/

c)
 - start: ⠒
 - end: ⠶

d)
 - start: ﹙
 - end: ﹚

a,b,c are nestable if using them again.

d) is only nestable if one of the others is used. I'm not sure, if I like this behaviour. ...

-mario

    switch (this.match[1]) {
        case "__":
            reEnd = /___|_\//g
        break;
        case "/°":
            reEnd = /°\//g
        break;
        case "⠒":
            reEnd = /⠶/g
        break;
        case "﹙":
            reEnd = /﹚/g
        break;
    }

TonyM

unread,
Oct 27, 2020, 4:33:07 PM10/27/20
to TiddlyWikiDev
Mario

Thanks for the update today. I will review in the next few hours.

In responce to your last reply, to me the small brackets,
do not look like they are surrounded by spaces in  tiddlywiki.

I will look at the 4 possibilities above, my current personal preference is d, b, a, c;
but I want to look at the outcome with customise inactive.

I am not sure why you say new inline functions then you say no inline customise functions.
Do you mean inline works with underscore, you just can not customise it?

regards
Tony

PMario

unread,
Oct 27, 2020, 8:08:49 PM10/27/20
to TiddlyWikiDev
On Tuesday, October 27, 2020 at 9:33:07 PM UTC+1, TonyM wrote:

I am not sure why you say new inline functions then you say no inline customise functions.
Do you mean inline works with underscore, you just can not customise it?

It is able to detect start / end and nested inline definitions. But at the moment it only sets class-names. ... No possibility to call widgets. ... Will follow soon.

At the moment the plans are:

_element should be configurable. ... I think it will be limited to widgets and html inline elements, or may be even a subset of them.

_endString will be _not_ configurable.

_mode has to be fixed to inline

I tend to remove __ and ___ ... since it will overwrite the existing __underline__ wikitext definition, which isn't usable atm.

.. The rest will be the same as the existing params

-m

TonyM

unread,
Oct 27, 2020, 8:14:30 PM10/27/20
to TiddlyWikiDev
Mario,

A few observations.
Again please don't be overwhelmed just consider these ideas please. Nor do these ideas imply it demands your work, although in some cases that is most likely.

The key issue I am grappling with is the systemisation of glyphs, symbols and the scope of customises wiki text. To make this easy to use and remember. Presently I always need to lookup the reference material and slowly construct wikitext, if its slow and hard for me (involved in this project from the start) it may appear impossible to future new users. There are differences in the way Mario, TT and myself envision this, until this is cleared up even testing will be clumsy apart from helping future users.

Observed - In a tiddlywiki without custom mark-up
This is some Text __.test Inline text ___ with more
fails gracefully

;This is some Text __.test Inline text _/ with more
Fails ungracefully. Disrupts future wiki text.


In this example I use a custom endString basically /symbol 
\customize tick="d" _element="details" _classes=".notop.cbox.cbox-primary.hard-linebreaks" _endString="/d" _mode=block
\customize tick="s" _element="summary" _classes=".margin-init"  _endString="/s"

´d ´s Details - Summary
/s
line
1
line
2
/d
´d
´s Details - Summary
/s
line 1
line 2
/d
Is there any reason why we could not make this a default end string, ie the "/symbol" automatically. unless specified for such blocks.
Then allow the end string to be set to a logical "\n" or "\n\n" for the automatic closure at end of line or end of double line break/paragraph.

Also can you explain or document a little "the use of this nesting" ?
´d ´s
as I understand it ´s follows ´d and a <space> so it looks inline, but I assume it is not, 
can we say "customise blocks can be nested by following one with another on the same line, but only at the beginning of the line or at the beginning of subsequent lines" 
Just to get a more general statement?

I love the demo
wow symbol.class:param some text nice
There is also a superscript and subscript form of these (Not the same as each other 
this is some text
this is more text
To me these are two use full pairs to use glyphs for inline content. 
  • Obvious but subtle
  • Open and close are single characters
  • Would just look like a textural mark up without custom wiki text plugin.
  • Provides two/tree pairs for different applications
The use of the Greek delta to represent change may be useful at some point as a glyph.

Question - See diacritical markers
  • Could we have any clashes with these?
Question - customised Glyphs, a glyph too far?
  • As you can see the wide range of glyphs available that have meaning or structure makes me wish to ask if we could allow the user to nominate glyphs either single (line/para/blocks) or pairs for inline or block. ie customise the customise glyphs.
  • This would mean we only choose a few and let the user define extended glyphs (only if they want to take the red pill), this could reduce some missuses if people must add more to get more complex
  • The EditorToolbar buttons would then apply a currently selected glyph or can be cloned to create a new set of buttons for another glyph/or pair.
    • Using either the actual glyphs for the button or an svg version (below)
  • I realise this level of customisation may be problematic but it will solve other problems like forcing us to choose glyphs. I only ask because of its desirability, but have know Idea if coding wizardry permits, even if a reload is necessary.
<svg height="26px" width="24px">
 
<text x="0" y="24">⁽ ⁾</text>
</svg>

<svg height="26px" width="24px">
 
<text x="0" y="22">₍ ₎</text>
</svg>
Note 'y="22"' here, lest it be "trimmed" at the bottom.

So to my thinking about glyphs 
This is done without a detailed response to existing uses and I stand to be corrected, they are suggestions only, more to share the organising principal than the specific glyphs.
In this case the glyphs differ by their default scope ie where they terminate

Pre-prevision two inline braces glyphs
  • ⁽ ⁾ superscript additional braces open and close defined
  • ₍ ₎ subscript additional braces
Pre-provision beginning of line glyphs
  • › suggests, one end of line (eol) which is terminated with "\n" by default - A single line glyph like * and #
  • » suggests, two eol, which is terminated with "\n\n" by default - A paragraph responsive Glyph
    • An alternative or additional paragraph responsive glyph "¶  pilcrow sign" is still in my view  a valuable one and could be used with ⁋ REVERSED PILCROW SIGN to wrap a block and force a paragraph element.
  • ´ tick like "›" but ´ suggests special mark-up follows, which is terminated with "\n" by default, or /symbol if symbol is used (an no alternative given) ie if symbol is used can be used as a block, only terminating on /symbol
    • Useful with html and widget matching symbols eg ´div.classname some text or lines /div (if necessary we could use ⁄ instead of /
  • ° which is terminated with "\n" by default - but can be terminated prematurely with /° (or °/ allowing one to just use the content before /° as the src in the custom, leaving the rest of the line to be wikified as normal. Main glyph used for parameter passing
    • The use of °  then °/ implies the use of  /° content °/ where the ° operates inline, perhaps to support this we allow / to proceed a glyph without altering it 
  • eg
°trans:p1 tiddlertotransclude °/ Futher wiki text

/° the / is ignored here but does allow a glyph to proceed it to be used as it it was the first character on the line °/
But given this then
/
´ may imply ´/ may be used to prematurely close tick. (suggested as \n by default as a line based glyph)


Pre-provision block focused glyphs
  • ≈ Suggests multiple lines, and expects closure, perhaps /≈ by default? ie /glyph, rather than /symbol
  • ≋ Or similar could be used to represent larger blocks, and expects closure, perhaps / by default? ie /glyph, rather than /symbol
On entering the glyphs in wikitext

  • Perhaps a special toolbar button with short cut eg: alt-insert N (then a OL list) N were hitting a number key will insert that glyph (in a fixed order) 
  • no other special handling like your current solution. 
  • No space or otherwise, this is the users responsibility, including closure.
  • At least the glyphs will always be at hand with a simple set of keys
  • An additional button and short cue eg ctrl-insert for a user selected list of "symbols" could be provided that could be used to access any symbol for customise and other applications.
  • The current solution could be changed to be used only for "canned" and prepared customise strings.
Fullwidth characters
  • There is a set of uni-code characters called fullwidth
  • Tilde curly braces, square and parentheses and bar, including broken bar, punctuation and alpha-numerics that are all unique and separate characters. 
  • I am confidence tiddlywiki supports this, but the worst case is customise comes with a raw tiddler loading an appropriate font.
  • "l" list is an example lowercase l


A random Idea
  • I used to use a character combination to annotate lines on personal hand written notes, I have found unicode versions, they always live at the end of a line
    • ? a question (A question) Special forms of these also exist.
    • ! an answer (asserted / definitive answer)
    • ⁇ Question this, it is unlikely to be true 
    • ⁈ You must question this, question - asserted 
    • ⁉ Believe it to be true - asserted but could question
  • So I wonder like your prior work on <space><spaces>\n if we could introduce a end of line type of custom pragma. ie it has no beginning of line, or inline or block characteristics (by default)
    • In a sense inline but only end of line (\n). Used inside ⁉ means nothing.
    • This also means it would typically not have any input (other than symbol, class or :p) unless it detected \n vs \n\n
Perhaps another random and radical idea?
  • As you may know there are special spaces such as 
    U+FEFF ZERO WIDTH NO-BREAK SPACE
  • These is used as glyphs will be invisible both in the editor and rendered output with or without the customise plugin. 
  • Suggests interesting possibilities and if not using "customise plugin". symbols or .classname or :parameter will be invisible anywhere. Makes for highly transferable text. Ie no impact when copied and exported elsewhere.
  • Arguably we could do something to make them appear visible only in the tiddlywiki editor. eg a font character remap.
In closing;
  • In truth once again I am straying into further extensions of possibilities in these notes. 
  • However it seems to me this is a valuable "look ahead" in an attempt to inform the current project to achieve the best outcome.
  • If we are using Extended Unicode as our glyphs, and possibly symbols, this does suggest we need to be well informed in Unicode, hence my explorations here.
  • Extended Unicode do need a font that will represent them, however it seems most are covered already with default fonts, and if it were necessary adding a full back font is trivial, to include with customise.
  • I do declare as per posts elsewhere, what I am learning from this exploration of Unicode has very interesting design implications as raised here. The use of additional character sets within tiddlywiki as it stands, without customise or special fonts provides a whole set of namespaces. This has implications for the designer especially if they limit the use of these characters to their own code and tiddler titles. and example is the word description is an existing field but the word description in another character set could be the name of a tiddler that defines the description field and how to view or edit it.
    • In many ways these lessons make sense to raise within this project because it is all about  glyphs and symbols, which are critical to the success of the customise wiki text solution.
  • My experiments so far suggest making use of extended Unicode is already effective and operational in tiddlywiki by virtue of its standards based implementation. 
Regards
Tony

TonyM

unread,
Oct 27, 2020, 8:26:17 PM10/27/20
to TiddlyWikiDev
To clarify,

The following is about the use of underscore or another glyph to handle "inline custom wiki text."
I am not sure why you say new inline functions then you say no inline customise functions.
Do you mean inline works with underscore, you just can not customise it?

It is able to detect start / end and nested inline definitions. But at the moment it only sets class-names. ... No possibility to call widgets. ... Will follow soon.

That is fine, thanks for clarifying
 

At the moment the plans are:

_element should be configurable. ... I think it will be limited to widgets and html inline elements, or may be even a subset of them.

Great, do we need to suggest only to use inline html elements within this? This is a good reference for html block vs inline https://www.w3schools.com/html/html_blocks.asp
  • I plan to make extensive use of the difference in future with customised wikitext.
 

_endString will be _not_ configurable.

Makes sense if we pre-configure the closure, and define a glyph or set of glyphs of the "inline type"

As in my previous email perhaps some glyphs should also have a default block type pre-set, and a few with neither set.
 

_mode has to be fixed to inline

Again makes sense. that is what it is. See my last post for an attempt to rationalise this and my objections to underscore, which I may add has already cause problems be cause it is hard to see the difference between _, __ and ___ if they are separated by any distance or in different fonts.
 

I tend to remove __ and ___ ... since it will overwrite the existing __underline__ wikitext definition, which isn't usable atm.

Not sure what you mean here, but is it like my objection to undersore?
 

.. The rest will be the same as the existing params

Exciting.

Tony

PMario

unread,
Oct 27, 2020, 8:40:22 PM10/27/20
to TiddlyWikiDev
On Wednesday, October 28, 2020 at 1:14:30 AM UTC+1, TonyM wrote:
A few observations.
Again please don't be overwhelmed just consider these ideas please. Nor do these ideas imply it demands your work, although in some cases that is most likely.

The key issue I am grappling with is the systemisation of glyphs, symbols and the scope of customises wiki text. To make this easy to use and remember. Presently I always need to lookup the reference material and slowly construct wikitext, if its slow and hard for me (involved in this project from the start) it may appear impossible to future new users. There are differences in the way Mario, TT and myself envision this, until this is cleared up even testing will be clumsy apart from helping future users.

Observed - In a tiddlywiki without custom mark-up
This is some Text __.test Inline text ___ with more
fails gracefully

;This is some Text __.test Inline text _/ with more
Fails ungracefully. Disrupts future wiki text.

You are right. ... I didn't consider this. ... But may be we should remove underline. It seems to cause more problems as it solves. And we do have enough other possibilities now.

-m

TonyM

unread,
Oct 27, 2020, 8:50:19 PM10/27/20
to TiddlyWikiDev
Mario,
_endString will be _not_ configurable. 

I agree with this but ask if if it makes sense to be auto-terminated with \n or \n\n  
am I wrong to think Typically inline does end at a line or paragraph break?

So if we use the glyphs I suggested ⁽ this is inlinethis inline .coda at the end will be honoured
  • "coda" is a term used as in the finishing notes in music that end the piece gracefully.
  • In this case it would be an end of line sequence
  • Arguable we may use 
´something rest of line using inline
or
just reusing the inline to the end of line (from the beginning)
  • I suggest this only because there may be a lot of cases where inline is used to highlight text
  • Not demanding closure may reduce incidental errors when closure omitted.
  • This same highlight may be reused in lines as well
  • No need to define another all but identical line of paragraph terminated custom wikitext just to use the same formatting as an inline definition.
This is a sentence ⁽.mark.yellow this text singled out but this text just sentence. Note no space proceeding close.

´something ⁽.mark.yellow rest of line using inline
or
⁽.mark.yellow just reusing the inline custom for a whole line.


*⁽.mark.yellow Item 1 highlighted
*⁽.mark.green Item 2 differently highlighted.

I think inline puts us on the "home run".

Tony

TonyM

unread,
Oct 27, 2020, 8:59:46 PM10/27/20
to TiddlyWikiDev
Minor additional note

A random Idea
  • I used to use a character combination to annotate lines on personal hand written notes, I have found unicode versions, they always live at the end of a line
    • ? a question (A question) Special forms of these also exist.
    • ! an answer (asserted / definitive answer)
    • ⁇ Question this, it is unlikely to be true 
    • ⁈ You must question this, question - asserted 
    • ⁉ Believe it to be true - asserted but could question
  • So I wonder like your prior work on <space><spaces>\n if we could introduce a end of line type of custom pragma. ie it has no beginning of line, or inline or block characteristics (by default)
    • In a sense inline but only end of line (\n). Used inside ⁉ means nothing.
    • This also means it would typically not have any input (other than symbol, class or :p) unless it detected \n vs \n\n
End of line only mark up, with selectable glyphs, Would allow someone like me to define a glyph  "¶" as "<br>br>" so insertion of ¶<space> would render as a new paragraph "break". This provide the complement to beginning of line and inline mark-up.

Regards
Tony

PMario

unread,
Oct 27, 2020, 9:07:25 PM10/27/20
to TiddlyWikiDev
On Wednesday, October 28, 2020 at 1:50:19 AM UTC+1, TonyM wrote:
Mario,
_endString will be _not_ configurable. 

I agree with this but ask if if it makes sense to be auto-terminated with \n or \n\n  
am I wrong to think Typically inline does end at a line or paragraph break?

No. Inline ends with a predefined endString and it uses inline mode only!

﹙.hl some text
! new line <- no H1 here since we are in inline mode!
3rd line
﹚some more text


If you need H1 to be rendered, you'll need to use "angle" or "tick" with _mode=block and an _endString

-m

PMario

unread,
Oct 27, 2020, 9:21:02 PM10/27/20
to TiddlyWikiDev
Hi Tony,

Very good questions. ... all of them.

As I do read the requests, I think we shouldn't make a difference between \customize and \customize inline .... But this could cause a lot more consistency problems, like:

´d ´s some text        <-- only works that way because I liked it.

With strict rules it would need to look like this:

´d
´s some text
some text
----   <-- _endString

I'll think about the ideas .. while I'm sleeping ;)

-mario

TonyM

unread,
Oct 27, 2020, 10:00:32 PM10/27/20
to TiddlyWikiDev
It must be late for you - good night

Tony

@TiddlyTweeter

unread,
Oct 28, 2020, 3:34:40 AM10/28/20
to TiddlyWikiDev
Regarding Using UNDERSCORE - Don't

PMario wrote:

I tend to remove __ and ___ ... since it will overwrite the existing __underline__ wikitext definition, which isn't usable atm. 

Quick observation. 

I think it is a mistake to consider underscore in any Custom Markup. For several reasons ...

1 - IMO, if we have to switch off the EXISTING underline method (__text bits__) in WikiText it would be confusing & and could break users existing markup in Tiddlers. 

2 - AND having both the existing method for the U element and the Custom Markup SPAN element just adds complexity that will make small errors much harder to pin down.

3 - Nesting if we go with ...

reEnd = /___|_\//g

... will produce WikiText that gets difficult to read and is over verbose. For instance ...

We built a ___.h house ___.o on a hill_ _ with a long fence.

... and IF we retain existing underline method it gets even worse ...

We built a ___.h house ___.o __on__ a hill_ _ with a long fence.


Basically, I think its a mistake to use underscore anywhere in Custom Markup!
Custom Markup should use it's own, never used before, glyphs. 

An opinion
Best wishes
TT

 

@TiddlyTweeter

unread,
Oct 28, 2020, 3:58:36 AM10/28/20
to tiddly...@googlegroups.com
Number Of Inline Custom Span Markers? - Two is Enough!

PMario wrote:
As you can see in the code below there are 4 possibilities atm.  I intend to reduce them to 2 if possible!

I think TWO  is good. It's got particular usefulness for easier reading of nested WikiText ... for example ...

/°.b4 He opined on the ⠒.za general remit⠶ of the Higgin's bomb°/ lest it be...

I also assume that existing WikiText span pair (@@ ... @@) will continue to work, so, in effect, you have THREE in total ... (2 x self-nestable; 1 x not-self-nestable) for example ...

/°.b4 He opined on the ⠒.za general remit⠶ of the @@.aa Higgin's bomb@@ °/ lest it be...

So more than two Inline Custom Markup glyph pairs looks redundant.

Best wishes
TT

@TiddlyTweeter

unread,
Oct 28, 2020, 4:19:46 AM10/28/20
to TiddlyWikiDev
Point on Nesting "﹙﹚". Don't have them if they don't nest the same way as the others!

PMario 
d)
 - start: ﹙
 - end: ﹚

...

d) is only nestable if one of the others is used. I'm not sure, if I like this behaviour. ...
The nesting behaviour of Inline Custom Markup pairs should be fully consistent! 

If the behavior of  "﹙﹚" pair differs it will likely create confusion!

Best wishes
TT

@TiddlyTweeter

unread,
Oct 28, 2020, 4:47:28 AM10/28/20
to TiddlyWikiDev
What Are UNambigous Markup Pairs? -- where the open & close characters are each SINGLE different characters.

Ciao PMario & TonyM

As you can see in the code below there are 4 possibilities atm.  I intend to reduce them to 2 if possible!
c)
 - start: ⠒
 - end: ⠶

d)
 - start: ﹙
 - end: ﹚

Purely logically these pairs of SINGLE characters are far preferable to multi-character pairs!

Multi-character pairs will be prone to typing errors ... For instance  ...

This /°.n6 looks nice enough°/ for reading

But could very easily get yourself in a knot.

This /°.n6 looks nice enough°/ for reading till you make a small error.

Having multi-character pairs should be avoided. Especially for inline markup where typos and other errors are harder to spot.

Using a pair of SINGLE unique characters is by far better as their use is immediately determinate and less verbose.

Best wishes
TT

@TiddlyTweeter

unread,
Oct 28, 2020, 6:01:19 AM10/28/20
to TiddlyWikiDev
On Why ﹙ ﹚ is a BAD idea. Far too like (  ).

Ciao TonyM & PMario

Whilst I understand TonyM's push for this it has POOR READABILTY.

It is far too like conventional parenthesis (round brackets). For instance ...

He stood upon the ground (terra firma) v. he stood upon the groundterra firma﹚.

Which is which? It is NOT immediately obvious.

In addition, conventional brackets in normal writing can have semantic importance that this construct muddies up.

Lets look for an alternative please!

Best wishes
TT 


PMario wrote:

d)
 - start: ﹙
 - end: ﹚

@TiddlyTweeter

unread,
Oct 28, 2020, 8:11:26 AM10/28/20
to tiddly...@googlegroups.com
Note On EndString & Mode -- Agreed & More

PMario wrote

_endString will be _not_ configurable.

_mode has to be fixed to inline

Makes much sense.

INLINE, much more than BLOCK, is about fluidity of writing. 
A simple approach looks appropriate.

Inline that I'm most concerned that markup is as COMPACT AS POSSIBLE (i.e. single character open & close strings). The MAIN innovations in your approach are ...

1 - enabling the use of HTML INLINE ELEMENTS (eventually).

 and

2 - NESTING. 

IMO this combo will do more to AID WRITERS than any other aspect of Custom Markup.

It is a far superior to current Inline WikiText which is an over verbose and a somewhat blunt instrument.

Best wishes
TT

@TiddlyTweeter

unread,
Oct 28, 2020, 8:22:37 AM10/28/20
to TiddlyWikiDev
Block & Inline are Different Things. Having separate definition spaces remains a good idea. 

Ciao PMaio & TonyM

PMario wrote:
As I do read the requests, I think we shouldn't make a difference between \customize and \customize inline .... But this could cause a lot more consistency problems, like:

´d ´s some text        <-- only works that way because I liked it.

With strict rules it would need to look like this:

´d
´s some text
some text
----   <-- _endString

I think the distinction between INLINE & BLOCK remains valid. Of course you can argue one can glide one into the other. But I'd need convincing that the basic distinction should be messed with. Customize each separately. You could still use \customize to change behaviors for any element.

Best wishes
TT

@TiddlyTweeter

unread,
Oct 28, 2020, 8:50:44 AM10/28/20
to TiddlyWikiDev
Regarding User Possibility To Set Markup Glyphs?

TonyM wrote:

Question - customised Glyphs, a glyph too far?
  • As you can see the wide range of glyphs available that have meaning or structure makes me wish to ask if we could allow the user to nominate glyphs either single (line/para/blocks) or pairs for inline or block. ie customise the customise glyphs.

 Ciao TonyM & PMario

IF this were possible I WOULD use it.

Why? Because the kinds of Markup I do would benefit from me being able to choose glyphs VISUALLY SUITED to the purpose.
For instance, for simple paragraphs ...

Start of a paragraph,
more of the same pargraph endedon the
next line.
<--- End String

I understand if its not possible. 

I assume the current approach is hard-coded JS?

Just a thought to say TonyM & I on this idea concur.

Very best wishes
Josiah

PMario

unread,
Oct 28, 2020, 10:53:12 AM10/28/20
to TiddlyWikiDev
On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:
Regarding User Possibility To Set Markup Glyphs?

TonyM wrote:

Question - customised Glyphs, a glyph too far?
  • As you can see the wide range of glyphs available that have meaning or structure makes me wish to ask if we could allow the user to nominate glyphs either single (line/para/blocks) or pairs for inline or block. ie customise the customise glyphs.

 Ciao TonyM & PMario

IF this were possible I WOULD use it.

... need to think about it. But it would make configuration a hell lot more complex.
 
Why? Because the kinds of Markup I do would benefit from me being able to choose glyphs VISUALLY SUITED to the purpose.
For instance, for simple paragraphs ...

Start of a paragraph,
more of the same pargraph endedon the
next line.
<--- End String

I understand if its not possible. 

It would be possible to use pilcrows as "start" and "end" of a paragraph, but I don't understand why.

TW Pargraphs end with \n\n by default

So the "reversed pilcrow" <--- End String is redundant and for me personally it is confusing, since Libre Office and Word use: ¶  as a paragraph marker. ... It may be wrong, but it is shown at the end of a paragraph. ... So the reverse pilcrow feels completely wrong at that position.

I could implement:

¶ some text \n\n

Since it would be the right thing to do. see: Wikipedia Pilcrow. It would be easy to explain, with the link to Wikipedia. It will create a HTML P tag by default.

If you want you can define an _endString. ... Default would be \n\n

-mario

TonyM

unread,
Oct 28, 2020, 7:37:09 PM10/28/20
to TiddlyWikiDev
Mario,Josiah


I would not bother with the use of pilcrow unless it was part of an end of line form of glyph only. Its key use would be to place a pilcrow in a large slab of text to force a pagarapgh break. if other glyphs depended on \n\n, it would be best to resolve these first if possible. There is a implied new paragraph that follows the ¶ that is sufficient in my view (as for this paragraph). If one was to have a start and end the appropriate method is a revers-pilcrow and pilcrow pair.

End of line only mark up, with selectable glyphs, Would allow someone like me to define a glyph  "¶" as "<br>br>" so insertion of ¶<space> would render as a new paragraph "break". This provide the complement to beginning of line and inline mark-up.
 
Arguably the ¶ could be given a definition that highlights the first word of the next (generated paragraph).
 
Josiah, I don't mind decent, however I disagree with the lack of visibility with "the" parenthesis, and value how the look. First with Custom wiki text present they disappear in the output. Secondly we can use the slightly different examples given. My point here is if something is not good enough rather than exclude it find if there is a way to 〖 address 〗 it, such as ⁽ Here ⁾ or ₍ there ₎ remember as a rule already text contains ' " ` and other characters even less readable. The fact that a reader may not be able to tell the difference may actually be an advantage when no customisation is occurring.

If we have two (or more) open and close braces there is an opportunity to define one as non-operative in text that contains one of the other pairs. The point being the only reason they will be in use is because the writer chooses to.

I am actually keen to use such Unicode braces simply to delimit a piece of text, I would write separate macros to extract those keywords and phrases so delimited, independent of the current text even without the use of customise. However if such pairs are available to "custom wikitext" further automation or formatting can be done to automate this feature.

Tony

TonyM

unread,
Oct 28, 2020, 8:05:53 PM10/28/20
to TiddlyWikiDev
Mario,

Just a thought, if the customise definition was to accept both glyph and symbol as parameters this may be an easier approach.
\customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight _classes=".highlight" _mode=inline
even an new \customise-def that accepts _glyphs and _glyphNames and \customise does not.

Then all the existing definitions would be transferred into this form, but could be altered.
Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent use such as
\customise openenc _classes=".highlight-green"
In effect a redefinition, like the current customise.

In the worst case there will need to be a start-up process that puts glyph definitions in a specific tiddler into a table, ie reload to add new glyphs.

Forgive me for interfering in this aspect of coding, which I am as yet unable to contribute to myself. I wish you had another "coder" (or more) sharing your effort.

I would just add to the general discussion, whilst global customise is a valuable tool, I can see customise being added to the specific tiddlers that wish to use extended mark-up, so in many cases the scope will only be the current tiddler. If a text contains a glyph the editor can just choose another for their special mark-up, a small popup panel could list the glyphs found in a tiddler.

Another approach is using a custom type field, and the type which is equivalent to a mime type also permits providing the character set.

Regards
Tony

On Thursday, 29 October 2020 01:53:12 UTC+11, PMario wrote:

TonyM

unread,
Oct 28, 2020, 8:17:11 PM10/28/20
to TiddlyWikiDev
Gentlemen,

The attached local view template demonstrates the use of additional code in a specific tiddler. 
  • In this case of you add the field local-viewtemplate to any tiddler in the edit view and a new editable field appears. This will be applied through the view template.
  • Please try it, it is immensely useful for research and experimentation on view Template code.
I can see using this or something similar for the application of various customise definitions only on the local tiddler.
  • Keep in mind a local-customise field could contain also a transclusion such as {{extended-markup}} to include a custom mark-up template, or \importcustom [[pragma-details]]
  • I am still to make this work for customize, but Mario would know how to of the top of his head.
  • Note the customised wiki would not apply if the text field were transcluded elsewhere but we could have a template that does include the local-template or local-customise in a Transclude (if it exists) eg {{tiddlername||$:/template/render-with-custom-wikitext}} 
Regards
Tony
Regards
Tony
local-viewtemplate.json

PMario

unread,
Oct 29, 2020, 12:15:20 PM10/29/20
to TiddlyWikiDev
On Thursday, October 29, 2020 at 1:05:53 AM UTC+1, TonyM wrote:

Just a thought, if the customise definition was to accept both glyph and symbol as parameters this may be an easier approach.
\customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight _classes=".highlight" _mode=inline
even an new \customise-def that accepts _glyphs and _glyphNames and \customise does not.

Those definitions will need to be done at startup time.
 
Then all the existing definitions would be transferred into this form, but could be altered.

That's right.

Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent use such as
\customise openenc _classes=".highlight-green"
In effect a redefinition, like the current customise.

In the worst case there will need to be a start-up process that puts glyph definitions in a specific tiddler into a table, ie reload to add new glyphs.

That would need to happen. ... When \customize definitions are parsed, the whole initialisation process is in the past. So there would need to be a configuration tiddler, that contains the necessary definitions.

The problem is, that the user, which wants to define the config tiddler would have to know exactly, how the parser works, to do the right things. ... I think it will be an education / documentation problem.
 
Forgive me for interfering in this aspect of coding, which I am as yet unable to contribute to myself. I wish you had another "coder" (or more) sharing your effort.

I do have a little problem with too many different "glyphs". .. It may also be a "tower of babel" problem, which could make interchanging content much harder. ... So if something is hardcoded, all users have to use the same "mechanisms". ...
 
I would just add to the general discussion, whilst global customise is a valuable tool, I can see customise being added to the specific tiddlers that wish to use extended mark-up, so in many cases the scope will only be the current tiddler. If a text contains a glyph the editor can just choose another for their special mark-up, a small popup panel could list the glyphs found in a tiddler.

If something is defined on a per tiddler basis, I don't see a big problem. ... The problem for content interchange comes with global definitions. .. If users forget to export the global definitions and the tiddler don't contain any info, that there actually IS a global definition.

That's why at the beginning there had to be an \importcustom [[abc]]. If a tiddler contains this info. Everyone knows what to request. ...
 
Another approach is using a custom type field, and the type which is equivalent to a mime type also permits providing the character set.

At the moment the core TW doesn't know how to deal with custom mime-types, which basically makes it impossible to use them.

-mario


PMario

unread,
Oct 29, 2020, 12:46:16 PM10/29/20
to TiddlyWikiDev
On Thursday, October 29, 2020 at 1:17:11 AM UTC+1, TonyM wrote:
Gentlemen,

The attached local view template demonstrates the use of additional code in a specific tiddler. 
  • In this case of you add the field local-viewtemplate to any tiddler in the edit view and a new editable field appears. This will be applied through the view template.
  • Please try it, it is immensely useful for research and experimentation on view Template code.
Hi Tony,
I got it working, but I think I'm the wrong person here. The problem I have with that approach is: I don't understand it.

I can't see the usecase, because my philosophy is completely different in this regard.

------------

For me only 1 multiline field exists: The text field. The tiddler is the smallest element in TW.

If I need "combined multiline content" I think there should be different stories. IMO the Streams concept is the way to go. In TW 5.1.23 there will be some (invisible) elements, that will make working with "combined tiddlers" and multiple stories easier.

As soon as I need a multiline field I think it is much easier to go the multi-tiddler / multi-story way as shown in the video from 9:30 to 10:30 
TW 5.1.23 will contain some elements, that will make this approach easier. ... BUT there is still more work to do. There are some open PRs and discussions at GitHub.

-mario

PMario

unread,
Oct 29, 2020, 2:10:03 PM10/29/20
to tiddly...@googlegroups.com
Hi,

V 0.8.0 - 2020-10-29

  • There are 4 "inline" like elements
    • __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
  • There are 6 "block" like elements
    • pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›
and it's crazy!

The "inline"-like elements do have predefined _endStrings but all the parameters can be defined. 

There are 6 "block"-like elements now. pilcrow uses a P aragraph as default and terminates \n\n as default.

__underscore__ behaves exactly as the existing wikitext ... so it uses an html U element by default. This can be re-defined if needed.

"braille" and "shlash" are nestable by default.

Shortcut buttons and docs is missing.
I didn't test all the possible combinations, since that's really a lot. ...


WE WILL NEED TO SIMPLIFY THIS! ... but it's cool to play with it ;)

have fun!

mario

PMario

unread,
Oct 29, 2020, 2:14:46 PM10/29/20
to TiddlyWikiDev
Hi,

Inline nesting seems to have a problem.

-m

PMario

unread,
Oct 29, 2020, 2:49:26 PM10/29/20
to TiddlyWikiDev
Hi Folks,

There has been so much feedback lately, that I'm still a bit overwhelmed. .. I need to read and re-read the infos several times.

At the moment we have maximum flexibility, except user-glyph-configuration. ... But let us test, what we have atm. ...

I'll need to create a lot more automatic tests, to avoid regressions in the future. Since "inline"-like configuration can do the same things as "block"-like customs I think we have a lot to test ;)

It may be even possible to reduce the number of used glyphs. ... BUT I think there is enough variety to satisfy the users preferences. Especially as every glyph can have unlimited "symbols"

-m

TonyM

unread,
Oct 29, 2020, 7:27:24 PM10/29/20
to TiddlyWikiDev
Mario,

An Idea, to avoid us returning to a solution which has no additional glyphs config, could be solved by providing a packaging solution, not unlike the bundler plugin. We can just select tiddlers with customise and bundle the definitions and custom definitions to ensure transferability.

Of importance here though, I am suggesting giving the vast majority of users, an appropriate set of pre-defined glyphs, they may never know you can define more. Being able to customise them, apply parameters and classes, use symbols etc... "is more than enough rope". But we know and we can innovate via this new Glyph mechaisium. If we can define a way to distribute a new glyph definition, perhaps in a separate file or plugin then a level of modularisation occurs, even allowing us to build the default glyphs in the same way. There is no harm if it demands a reload, we can force it in a glyph definition plugin, with customise wiki text as a dependency.

This customised wikitext solution is so powerful I think providing such an extencibility feature is wise, otherwise there will be too much pressure to update the core solution, and I do not want this to become a maintenance issue for you. 

As long as we can see what glyphs have being defined, it is possible to search for all tiddlers making use of that glyph, and advantage of using Unicode characters rarely found in content. If I go to export a tiddler with customised pragma, if I identify which defined pragma are in use in the current tiddler, and include their definitions, perhaps not the default (definitions), but also optionally the plugin as well. Then transfer becomes easy.

Now, I must declare knowing what customise can achieve so far, and the wealth of shiny Unicode characters, I am taken by the possibilities for writing my own content with any custom wikitext I desire. I really don't care if its transferable, people can read the rendered results, I can capture static HTML or deliver customisations in any Wiki I want. I am already thinking about a glyph for footnotes or extreme semantics like 

This is the conclusion or therefore statement in my text
;This is another conclusion
:This will be helpful review and extend these ideas.
That my knowledge base can extract and I can globally reformat in one place. All by customising a meaningful glyph.

Single line mark-ups for questions, answers, therefore, to do, details, references, errors, .... all triggered by glyph<space> With customise wikitext these can be used to trigger tasks, tiddlers, workflows and more all from insertion of a single glyph.

By being able to choose the glyph we can customise meaningful single character mark ups in a highly semantic way, rather that having to remember a glyph/symbol pair.

This is after all offering a personal productivity solution, sufficient to be wiki specific, as much as, a feature for tiddlywiki for lots of wikis.

Regards
Tone=y

TonyM

unread,
Oct 29, 2020, 7:42:35 PM10/29/20
to TiddlyWikiDev
Mario,

Sorry about the overwhelming. I will try and simplify


The attached local view template demonstrates the use of additional code in a specific tiddler. 
  • In this case of you add the field local-viewtemplate to any tiddler in the edit view and a new editable field appears. This will be applied through the view template.
  • Please try it, it is immensely useful for research and experimentation on view Template code.
Hi Tony,
I got it working, but I think I'm the wrong person here. The problem I have with that approach is: I don't understand it.

I can't see the usecase, because my philosophy is completely different in this regard.

The use case is an instant view template, that impacts on the current tiddler for ViewTemplate development and testing. Once tested you would move the code to a global viewTemplate and delete the local one, unless perhaps you had a bespoke view template for one tiddler.

The reason I suggest it, is we could have a bespoke \customise wikitext pragma field, for the same development purpose, for later globalisation if desired.

I can build it already I believe, If I can do it with a reference somehow to !!custom-pragma
\importcustom [[pragma-details]]

Regards
Tony 

TonyM

unread,
Oct 29, 2020, 8:09:16 PM10/29/20
to TiddlyWikiDev
Mario,

What you have done is fantastic. I will focus on V 0.8.0 - 2020-10-29 From a testing and features arising point of view. 

I am Happy to stabilise with the current solution as a first release if you want.

My only urgency to raise the custom Glyphs is that your are aware of it as a possibility and desirable. However you have done more than enough to accommodate I, your own and TT's questions and imagination. Its a pleasure working with you.

Only one issue you may have overlooked, or I missed your answer. Rather than use pilcrow at the beginning of a line I would only use it at the end, if you don't see an "end of line only pragma" being possible as discussed in this reply then I would suggest the reverse pilcrow, as it indicates beginning of paragraph.

Love your work as usual, and yes the combinatorial complexity is massive. 

We do need to draw the line somewhere. All we need to do is ensure the line does not compromise the future and I think you have that in control.

Regards
Tony

PMario

unread,
Oct 30, 2020, 12:44:29 AM10/30/20
to tiddly...@googlegroups.com
On Friday, October 30, 2020 at 1:09:16 AM UTC+1, TonyM wrote:

Only one issue you may have overlooked, or I missed your answer. Rather than use pilcrow at the beginning of a line I would only use it at the end, if you don't see an "end of line only pragma" being possible as discussed in this reply then I would suggest the reverse pilcrow, as it indicates beginning of paragraph.


Pilcwrow is used at the beginning of a new paragraph and by default stops with \n\n in the customize implementation. ... Similar to TTs suggestion. ...

I did try to implement pilcrow / reverse pilcrow as inline markers too. .. BUT it produces really strange and invalid HTML code. Ps inside SPANs inside Ps if stuff was nested. .. So I did move it to "block" like syntax, where it produces some predictable html output.

One of my goals still is, to produce html output that is well formed. ... There is a pending PR and some discussion at GitHub, that try to fix the problems with too many Ps in TW wikitext output. Especially in the UI sections, where it causes theming problems.

-m

TonyM

unread,
Oct 30, 2020, 3:52:22 AM10/30/20
to TiddlyWikiDev
Mario,

Go how you want, but my understanding comes from the more "modern use" noted later in the Wikipedia entry, truthfully a leading one may confuse me ans many others given this;

The pilcrow is used in desktop publishing software such as desktop word processors and page layout programs to mark the presence of a carriage return control character at the end of a paragraph. It is also used as the icon on a toolbar button that shows or hides the pilcrow and similar hidden characters, including tabswhitespace, and page breaks. In typing programs, it marks a return that one must type.

I have being keen to make a preview that acts as the aforementioned toolbar button would.

You are right to "produce html output that is well formed", I will return to reviewing the html my tests generate. I not you have many of my prior examples in test tiddlers, thanks its a helpful reference. 

Tony

PMario

unread,
Oct 30, 2020, 9:55:25 AM10/30/20
to TiddlyWikiDev
Hi folks,

I'd like to discuss with you the table syntax as shown in

\customize tick=table _element=table _endString="/endTable" _mode=block
\customize tick=caption _element=caption

\customize tick=! _element=th

\customize tick=cell _element=td _classes=".hl"
\customize tick _use=cell

\customize angle="===row" _element=tr _mode=block _endString="---"
\customize angle=cmulti _element=td _classes=".hl" _mode=block
\customize angle=| _use=cmulti

´table ´caption Some caption text
»===row
´! header 1
´! header 2
´! header 3
---
»===row
»| 1 text

»| 12 text «  and  »

»|
* cell 13 text
* line 2
* line 3
---
»===row
»| 2 text

»| 22 text

»| 23 text

---
/endTable

Do you think it could be used as a default, shipped with the plugin. .. The CSS for multiline and eg: bullet lists will need some adjustment ..

tick-cells are use for single line cells terminated by \n
angle-cells are used for multi, block like cells terminated by \n\n

»===row
   ends with
---

-mario

TonyM

unread,
Oct 30, 2020, 5:43:29 PM10/30/20
to TiddlyWikiDev
Mario,

I think it would be useful to include such "compound customisations" with the plugin or at lest on the plugins website. Although perhaps it could be an optional item that requires tagging.

Having used html tables within wikitext for so long, I find it easier to follow a html table format, and simple closures, as follows;

\customize tick=table _element=table _endString="/table" _mode=block
\customize tick=caption _element=caption

\customize tick=th _element=th

\customize tick=td _element=td _classes=".hl"  _mode=block

\customize tick="tr" _element=tr _mode=block _endString="/tr"


´table ´caption Some caption text
´tr
´th header 1
´th header 2
´th header 3
/tr


´tr
´td 1 text
´td 12 text «  and  »
´td
* cell 13 text
* line 2
* line 3
/tr


´tr
´td 2 text
´td 22 text
´td 23 text
/tr
/table

However if we are considering distributing or documenting "compound customisations" I would be tempted to extend my table to to include a lot more such and head/foot/body, a list widget for both rows and columns, as I would do this for myself anyway.

Perhaps your table responding to classic tiddlywiki tables AND one responding to html tables included would make sense?

Tony

TonyM

unread,
Oct 30, 2020, 8:36:14 PM10/30/20
to TiddlyWikiDev
Mario,

Just for clarification the double underscore (not underscore) is used, does this not clash with its existing use?, or is this intentional?

It is available on most keyboards.

Regards
Tony


On Saturday, 31 October 2020 00:55:25 UTC+11, PMario wrote:

TonyM

unread,
Oct 30, 2020, 8:44:27 PM10/30/20
to TiddlyWikiDev
Question,

If other glyphs and characters could be selected could we actually redefine existing mark-up with customise?
\customise glyph="*" parameters

*This would then take on the new definition here?

I raise this because this us what the current double underscore is effectively doing.

An example I may use if this was possible is to add underline or bold to H1/H2

This would allow redefinition of mark-up already in a text perhaps even making it behave like another mark-up language.
and additions like
\customise glyph="-" _element="li"

- to accept bullets pasted from GitHub


Tones

TonyM

unread,
Oct 30, 2020, 9:01:43 PM10/30/20
to TiddlyWikiDev
Mario,

I would be keen to see these additional inline glyphs made available. They look like a fusion of [ ] and ( )

It would be ideal for mark-up that involves links or buttons and where the content is considered a title.

*A line with〖 This inline 〗and more

  • They also look good when no customisation plugin is in use but does communicate, if it were, this would be treated differently. 
  • I would for example use it like [[ ]] but to trigger a button to create the tiddler from a template
  • Or 〖task This inline 〗to create from the task template
  • Its the more visible version TT is asking for.
However I do want you to retain ﹙ little﹚ for the same reason TT does not want them, they are similar but different to ( ) and less visible. 
  • TT can just "not use them" if he does not like them (I say with all due respect).

Tony

TonyM

unread,
Oct 30, 2020, 9:03:36 PM10/30/20
to TiddlyWikiDev
Do note I found these alternate small braces that may be better.
₍ ₎

Regards
Tony

@TiddlyTweeter

unread,
Oct 31, 2020, 4:02:26 AM10/31/20
to TiddlyWikiDev
Ciao TonyM

Quick query. 

When you suggest glyphs can you please also give the Unicode NUMBER!

In that way we can check where they have a chance of working (being in fonts) across platforms & setups.

Best wishes
TT

PMario

unread,
Oct 31, 2020, 4:14:29 AM10/31/20
to TiddlyWikiDev
On Saturday, October 31, 2020 at 1:36:14 AM UTC+1, TonyM wrote:

Just for clarification the double underscore (not underscore) is used, does this not clash with its existing use?, or is this intentional?

As default, it will do the same thing. So it shouldn't be a problem. But I need to fix it. Atm it isn't 100% the same.
 

It is available on most keyboards.

yes 
-m

PMario

unread,
Oct 31, 2020, 4:18:55 AM10/31/20
to TiddlyWikiDev
On Saturday, October 31, 2020 at 1:44:27 AM UTC+1, TonyM wrote:


This would allow redefinition of mark-up already in a text perhaps even making it behave like another mark-up language.
and additions like
\customise glyph="-" _element="li"

- to accept bullets pasted from GitHub


I was thinking about that too. BUT the github bullet points work in a different  way. eg:

 - aaaa
    - bbbb

and so on. I think I'll create a new plugin for them.

-m


@TiddlyTweeter

unread,
Oct 31, 2020, 4:19:43 AM10/31/20
to TiddlyWikiDev
PMario wrote:

Inline nesting seems to have a problem. 

Right. I noticed that. Hope its solvable!

Best wishes
TT 

@TiddlyTweeter

unread,
Oct 31, 2020, 4:42:25 AM10/31/20
to tiddly...@googlegroups.com
Markup Glyphs Should Be Visually Unique & Not Confused With Normal Writing

TonyM wrote:

*A line with〖 This inline 〗and more

The use of glyphs CLEARLY DIFFERENT from normal text is not just TT's issue!

It's important not to have any default glyphs that look like any common, conventional single glyph. ANY character that renders in font like "(  ... )" is particularly bad and should be avoided.

Looking at your suggestion, the Unicode glyphs from Basic Multilingual Plane: CJK Symbols & Punctuation look workable. ("CJK" means they are Chinese, Japanese & Korean glyphs).


【】〘〙〚〛〖〗

Their HTML entity numbers are ...

&#x3010;&#x3011;&#x3018;&#x3019;&#x301A;&#x301B;&#x3016;&#x3017;

They have default font support on my Windows 10 tablet. But this is via "font substitution" using shipped Asian fonts.
None of the usual fonts European Language speakers would explicitly set in TW settings have any of them except Cambria Maths.
That is not a problem for us on Windows. I'm not sure if its a problem for some Asian TW users. 
ADDED: And I haven't confirmed if it works on Android yet.

Best wishes
TT

@TiddlyTweeter

unread,
Oct 31, 2020, 5:01:42 AM10/31/20
to TiddlyWikiDev
PMario & TonyM

Can you please clarify what you mean here!

Do you mean that are TWO different Unicode glyphs for Underscore being used?

Best wishes
TT

@TiddlyTweeter

unread,
Oct 31, 2020, 6:05:06 AM10/31/20
to TiddlyWikiDev
Ciao PMario

It would be possible to use pilcrows as "start" and "end" of a paragraph, but I don't understand why. 
TW Pargraphs end with \n\n by default
So the "reversed pilcrow" ⁋ <--- End String is redundant and for me personally it is confusing, since Libre Office and Word use: ¶  as a paragraph marker. ... It may be wrong, but it is shown at the end of a paragraph. ... So the reverse pilcrow feels completely wrong at that position.

The use case I am thinking of is allow me to simplyfy & share with others an approach to correct manuscripts. 
I work often using specialist software to proof edit articles & books for publishers.
This uses a specific method and its own system of glyphs (based on "printers' corrections").
The software involved is very complex and expensive.
I believe there is a way I could do this work in TW using your Custom Markup if I had a few special glyphs.

I could explain it in detail if you wanted---but I don't want to overload you more than we have already :-)

P.S.: By the way the Pilcrow was originally used inline (often coloured red) in Medieval manuscripts to indicate a ceasura / hiatus / pause in the flow of a text. 
Vellum / parchment was very expensive so text is as condensed as possible. Paragraphs separated by lines evolved much later and was more to do with the development of printing and cheaper paper.

Best wishes
TT

PMario

unread,
Oct 31, 2020, 6:50:02 AM10/31/20
to TiddlyWikiDev
On Saturday, October 31, 2020 at 10:01:42 AM UTC+1, @TiddlyTweeter wrote:

Can you please clarify what you mean here!

Do you mean that are TWO different Unicode glyphs for Underscore being used?

The default behaviour, should do the exact same thing as the existing __underline__ does. ... But it can be customized, if users want.
At the moment, there is a little problem, since custom-markup needs __<space>some text__ ... I'll need to fix that.
-m

PMario

unread,
Oct 31, 2020, 6:54:42 AM10/31/20
to TiddlyWikiDev
On Saturday, October 31, 2020 at 11:05:06 AM UTC+1, @TiddlyTweeter wrote:

The use case I am thinking of is allow me to simplyfy & share with others an approach to correct manuscripts. 
I work often using specialist software to proof edit articles & books for publishers.
This uses a specific method and its own system of glyphs (based on "printers' corrections").
The software involved is very complex and expensive.
I believe there is a way I could do this work in TW using your Custom Markup if I had a few special glyphs.

I could explain it in detail if you wanted---but I don't want to overload you more than we have already :-)

It would be interesting to know. .. Otherwise may implement changes, that work against your usecase, because I don't know it. .. Which probably has happend already as using the pilcrow as a "paragraph" marker. ... Which makes it impossible to be used as an inline marker. ...

-mario



PMario

unread,
Oct 31, 2020, 7:05:07 AM10/31/20
to TiddlyWikiDev
On Saturday, October 31, 2020 at 11:05:06 AM UTC+1, @TiddlyTweeter wrote:

P.S.: By the way the Pilcrow was originally used inline (often coloured red) in Medieval manuscripts to indicate a ceasura / hiatus / pause in the flow of a text. 
Vellum / parchment was very expensive so text is as condensed as possible. Paragraphs separated by lines evolved much later and was more to do with the development of printing and cheaper paper.

Yea, I've seen that. I did find this:

Scribes would often leave space before paragraphs to allow rubricators to draw the pilcrow. With the introduction of the printing press, space before paragraphs was still left for rubricators to draw by hand; however, rubricators could not draw fast enough for printers and often would leave the beginnings of the paragraphs as blank. This is how the indent before paragraphs was created.[11] Nevertheless, the pilcrow remains in use in modern time in the following ways:

very interesting. ... I did ask myself for some time, where the indented first line in paragraphs comes from. .... Now I know :)

-m

PMario

unread,
Oct 31, 2020, 7:07:26 AM10/31/20
to TiddlyWikiDev
On Saturday, October 31, 2020 at 9:19:43 AM UTC+1, @TiddlyTweeter wrote:
PMario wrote:

Inline nesting seems to have a problem. 

Right. I noticed that. Hope its solvable!

V0.8.1 should have fixed it. If not please report!
-m

@TiddlyTweeter

unread,
Oct 31, 2020, 12:09:04 PM10/31/20
to TiddlyWikiDev
TBH my background has helped me a lot in writing for the net. 
I see the content/structure issue totally differently than most people.

That is what happens when you are fluent in Middle English :-).

When you stand back and look at it---"blocks" in HTML/CSS have innovated brilliantly over print media. 
BUT "inline" HTML/CSS seems badly scared to loosen the hold of print! 
Most websites read like newspaper columns.

We are barely using our available freedoms in writing for the net.

Sure this is part OT. But not totally. 
I have to test more, but I'm getting clearer your Custom Markup method will let me PLAY with writing forms viably in the way I want to really.

Best wishes
TT