from:"@TiddlyTweeter"

*Problems Of Working In The Dark*

One of the biggest issues I have had is getting a CONSISTENT approach to 
both determining "Candidate Markup Glyphs" AND sharing them.

I mean, before we go too far,  would it not be a good idea to identify by 
U+0023 numbers what we are talking about? Both for favourite pairings, or 
simple glyphs that strike you for markup?

IF you give me the numbers I can begin to think easier how to extract them 
from a font!

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/dbce183a-88e3-4d24-a718-adc6793ec14en%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*Candidate Source Font(s)*

I been doing testing with the Google NOTO SANS font (sets) to see what the 
coverage is like... Up points ...

--- The Licensing is permissive and would allow extraction of glyphs to a 
new font.

--- The *Unicode coverage is very good *(the aim of Noto is to eventually 
cover the whole of Unicode)

--- The visual design is consistent across its component fonts.

Frankly, I'm not an expert in Font modification software, but, in principle 
this looks like a series of font sets that we might derive the glyphs we 
need from.

Thoughts
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/91896a57-2460-4ecb-9edb-7bd12042edffn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*Note on KATEX plugin*

Tony's explore of Katex is useful! Tx! Studying it: it holds several fonts. 
WE don't need that complexity.

Rather, i think what we need is just *one *"Regular" font.

What impressed ME studying Katex is it totally clarifies HOW to embed a 
font in TW. Jeremy provides a bit of docs too which may prove helpful too.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/a37ec45d-e189-46de-b342-95850648bafen%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*Note On Custom Embedded Font*

Frankly I think that ultimately a custom (very small) font of ONLY markup 
glyphs is the BEST solution.

TonyM has shown that much of the time the normal font cascade on Windows 
will usually (but not determinately) work.
However there are additional issues even when it does. The main issue being 
that different fonts have *different design styles .*

I think it far better that ALL CustomMarkup Glyphs are visually consistent 
in design. Much better experience.

And I think it important we can GUARANTEE that the Glyphs are available in 
TW so it will work on all platforms without complications.

Regarding SIZE I will comment more later, but as far as I tested the CMFont 
would be no more than 10-30kb

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/eba1cbf0-0d2f-4e48-baea-3b7371f1ce90n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

Ciao TonyM & PMario

Sorry for my absence. I'm ill and not achieved yet what I was aiming it. 
That said, I have followed the discussion and done a bunch of background 
research which I will comment on next.

TT, x

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/f87cf316-9ef4-454b-8009-7498e48c14f7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-12-01 Thread @TiddlyTweeter

Ciao TonyM & PMario

TonyM wrote:

> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying reliable 
> Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>  
>

*TonyM*: That demo shows the issues arising over font support are 
generic---Not Just for PMario Markup. I think we should pursue the broader 
scope in a NEW thread. Maybe "Unicode and Font Support in TW". Do you want 
to start it? I have some solutions in mind. But they are refactory to this 
thread.

*PMario*: I think TonyM is *definitely heading in the right direction* on 
trying to pin down font support issues for your Custom Markup by 
illustration.
I can see the beginning of a *solution*. One where reliable markup glyphs 
could be always relied upon whatever platform you are on. It would be *a 
very minimal font embedded in TW for JUST markup glyphs. It would be 
kilobytes, not megabytes*. To get to the point of proof-of-concept I need 
some days yet, but I'm getting close. Its just trudge over the Unicode BMP 
to establish which fonts would provide the glyphs needed, cost free, to 
make a good "TW-MarkupGlyphsFont".

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/c592a5aa-d387-4a40-8b8d-2a6d1c2f172fn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-30 Thread @TiddlyTweeter

>
> On Thursday, November 26, 2020 at 11:17:50 AM UTC+1 @TiddlyTweeter wrote:
>
>> *BUG? v.0.8.1 -- Block Nesting Broken?*
>>
>
On Sunday, 29 November 2020 at 14:16:34 UTC+1 PMario wrote: 

> See _mode=block !!
>

RIGHT! I AM an idiot! Thanks for your patience. 

That admitted, I do think the inline/block setting importance needs 
(eventually) flagging more in docs.
I was away from the markup a week and forgot everything I learned. 
I kinda think grasping the sophistication of Custom Markup MIGHT be 
something of an issue.

Just thoughts
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2508a4a1-10d3-45a4-ba23-3456a036e54bn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-29 Thread @TiddlyTweeter

TonyM

I looked more closely at the macro that constructs the Unicode charts you 
made from: 
https://anthonymuscio.github.io/PreReleaseGlyphs.html#New%20Tiddler

Man, that is brilliant!

Beyond its immediate use for our explore, it could be used well to 
illustrate in some docs how to solve a problem in TW elegantly for 
Intermediate level users. 

TT

On Saturday, 28 November 2020 at 11:56:27 UTC+1 @TiddlyTweeter wrote:

> Ciao TonyM
>
> TonyM wrote ...
>
>>
>> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
>> reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>> <https://anthonymuscio.github.io/PreReleaseGlyphs.html> 
>>
>
> * Very good! *Hots off. Definite step in the right direction.
>
> Comments: *Load time is slow.* Is it GZipped? On Desktop its fine. On 
> Android smartphone is just never finished loading for me.
>
> For MARKUP glyph purposes it might be interesting to do a version more 
> delimited to "Text Markup Friendly" Unicode blocks?? A thought.
>
> Best wishes
> TT
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/29af65bc-41e9-4201-93f8-a6842c398e94n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-29 Thread @TiddlyTweeter

codacoder...@outlook.com wrote:

>   Wow - I mean just WOW! I just spent I-don't-know-how-long reading all 
> this stuff - yes, ALL four threads 

My own sense is that what PMario initiated is very significant in 
potentiating/expanding WikiText to become a proper full-html/css 
methodology that is lightweight and powerful. By loosing the (often largely 
self-imposed) limits of Gruber (MarkDown inspired) styling we open up to 
actually using the power of CSS/HTML to make end-user writing much, much 
easier.

In particular, it will become much, much easier to quickly design efficient 
markup systemS without needing to hack Javascript parsers. Ones which just 
up-and-work. 

That is why I'm keen on doing what I can.

My 2 cents
TT 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/e9239e83-7507-4558-b9e2-c6aec5bb6f29n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-29 Thread @TiddlyTweeter

Ciao. Nice to read you!

The "Joshua" v. "Josiah" conflate is an easy one to make since the 
"shortform" for both is "Jos."

Best wishes
Josiah

On Saturday, 28 November 2020 at 19:56:19 UTC+1 codacoder...@outlook.com 
wrote:

> On Saturday, November 28, 2020 at 11:44:01 AM UTC-6 coda coder wrote:
>
>>
>> Joshua - your guidance and background on unicode codepoints and the 
>> potential disconnect with font support is second to none. Excellent 
>> diligence!
>>
>> Face-palm - JOSIAH. Blame post-thanksgiving brainfog and a new son-in-law 
> called Joshua. :/
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/943f2454-4ff8-4723-befe-d57c0f101538n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-28 Thread @TiddlyTweeter

Ciao TonyM

TonyM wrote ...

>
> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying reliable 
> Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>  
>

* Very good! *Hots off. Definite step in the right direction.

Comments: *Load time is slow.* Is it GZipped? On Desktop its fine. On 
Android smartphone is just never finished loading for me.

For MARKUP glyph purposes it might be interesting to do a version more 
delimited to "Text Markup Friendly" Unicode blocks?? A thought.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8b1da3d7-a3b7-4144-ad95-c7e73059db03n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-28 Thread @TiddlyTweeter

TonyM wrote:

> This article lists glyphs supported by an intersection of a set of fonts 
> .
>  
> Perhaps we could take this list and present it in a tiddler, in a large 
> font size and put it out to the user forum for people to test and report if 
> all the glyphs are visible. Perhaps also in an empty.html at a URL people 
> can just open an review on their various devices?

 The problem with that "intersection" (nice idea) is it does NOT really 
work to illuminate what is going on.

All that entering those glyphs would show is that somewhere in the "global 
font hierarchy" a character in a font (a character in some registered font 
somewhere) those glyphs exist.

It is unfortunate that there is little explicitness in most documentation 
that CHARACTER substitution is ADDITIVE to FONT CASCADE.
In CSS cascade you can MATCH on font but FAIL on CHARACTER. At that point 
another method of substitution arises that, as far as I can see, CSS 
doesn't fully control. The substitution "pretends" that the glyph exists in 
a font when actually it doesn't. It is an invisible process.

In reality, the "full substitution-stack", roughly speaking is: (1) CSS 
Font Cascade  > (2) Browser Cascade/Stack > (3) OS Font Stack. Not all OS, 
or browsers, handle this substitution logic the same way.
FYI (OS) Substitution rules read header data in Fonts to determine match to 
the nearest consanguineous font character in another similar looking font 
first. Etc. etc

This is a short way of saying: *What that would show is Machine Support, 
Not Specific CSS font support. *

*That is good!* But it isn't really providing the full clarity needed to 
pin down UNambigous reliability for markup glyphs.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/096d1912-4f8b-48f5-95dd-256303725231n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-27 Thread @TiddlyTweeter

Ciao TonyM

TonyM wrote:

> The thing I find frustrating is fonts seem not to document the "code 
> pages" they include.  There must be Unicode rich ones available for linux 
> and apple and other devices as there is for Windows. 
>

I agree. *Frustrating* is the word. It is one of those areas of OS process 
that is simultaneously BRILLIANT and CONFUSING.

It is *brilliant *in that modern glyph end-usage got so much easier. Thanks 
to Unicode + improved Font File Architecture + Substitution metadata. 
It is *confusing* in that the OS+software mediated process of substitution 
actually now makes it difficult to answer simple questions about which 
fonts to use where---because the substitution process transparently does it 
automatically. Unraveling that is really for an expert in that specific 
field now.

I did some tests in TW to see if I could get it to use a special Test Font 
that Adobe provide which indexes ALL Unicode code points to a "blank." 
Doing that you can, in theory, set a CSS cascade such that you effectively 
switch-off substitution (i.e. cascade: Font, BlankFont). that make it quick 
and easy to know which fonts truly hold a glyph.
Unfortunately Windows 10 doesn't directly support the indexing method the 
AdobeBlankVF font file uses. 

I'm still playing around with the idea though.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/cb4f0205-2377-406b-9374-e35d0654ea33n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-27 Thread @TiddlyTweeter

TonyM wrote:

> It would be interesting to look at a selective font, as a last resort, 
> that we could embed in tiddlywiki with only the symbols we need. I have 
> seen font builders around but it remains a bit of a dark art to me. Most 
> users such as myself have most of the Unicode covered (as I use Windows 10) 
> so a local font is likely to satisfy the requirements. I would be surprised 
> if any would have to revert to the last resort font if we choose the fonts 
> correctly (or check the existing ones)
>

Right. Last resort in an internal TW cascade. Lot of work BUT would be *a 
reliable way round Cross-Platform UN-certainty.*

Whilst I agree that Windows 10 "font stack" (i.e. substitution order by OS 
for fonts lacking in a TW defined CSS cascade) is very rich, it is still 
needing clarity on what is going on.

*Why? *Because different regional installs can make available different 
fonts in different W10 regions (Asian v. European probably being the 
largest mass issue). Frankly, I do NOT know, with certainty, how much of an 
issue this is in practice. The MS documentation is not that easy to 
understand. And the font substitution process is sophisticated.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/f7287309-9f32-4690-a923-c51300de8444n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-26 Thread @TiddlyTweeter

*Font-ish Thoughts ... *

Ciao TonyM & PMario

TonyM wrote:

> What I did discover is the following 
> 
>  includes 
> the letter symbols 🄐 - 🄩 and other sets. Some of which will show a color 
> icon with the right fonts
> [image: Snag_2a82c66a.png]
> My thought is what if the glyphs available are from a set that an 
> (optional) web font presents in an enhanced color form. Something one could 
> toggle on/off? between plain and coloured.
> In edit these would be bright and easy to see, but after wikification and 
> when acting as customise symbols they are invisible. 
>

Right. Interesting ideas. If you look back you will see brief discussion 
between me and PMario concerning *ways round the 'local machine' font 
problem*.

I think its worth commenting on some of the options ---

1 - *Use Web Fonts From Web. *I think PMario would not be too keen on this 
as you'd need to online connect your wiki to a distant server and all that 
involves. 

2 - *Use Web Fonts Once Downloaded. *Many free web fonts can be downloaded. 
DOWNSIDE: adds *a lot *of complexity to set-up.

3 - *Embed Glyphs in a Custom Font that comes with the plugin*. This might 
be good. ISSUES: What size would it be? Who would have knowledge how to 
make it? And have the time? 

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/21cab858-19e1-491c-a7c6-167f702bdef1n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-26 Thread @TiddlyTweeter

*BUG? v.0.8.1 -- Block Nesting Broken?*

Ciao PMario

Below is example that fails to render nested elements. Code first. Render 
second.
Normal WikiText also fails within the scope of the "POEM" div. Failed part 
of example render in  RED.

Best wishes
TT


--- CODE -
\\ CUSTOM POETRY \\
\\ -- container - \\
\customize angle=POEM _element="div" _endString="/POEM" _classes=".poem-c"
\\ -- components --- \\
\customize single=P-H _element="h3"
\customize pilcrow=P-B _element="div" _endString="/P-B" 


»POEM

  ›P-H JABBERWOCKY

  ¶P-B ’Twas brillig, and the slithy toves
  Did gyre and gimble in the wabe:
All mimsy were the borogoves,
  And the mome raths outgrabe.
  /P-B

/POEM

--- RENDER --
 

 ›P-H JABBERWOCKY 

 ¶P-B ’Twas brillig, and the slithy toves 
 Did gyre and gimble in the wabe:
 All mimsy were the borogoves, 
 And the mome raths outgrabe. 
 /P-B 

 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5ebdf387-d0ba-4b3f-b7ad-4a437315a996n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-25 Thread @TiddlyTweeter

*"Braille" Has Advantage It is SINGLE Characters With Wide Font Support *

PMario
⠒ braille⠶ ... 
I did play around with "braille" a little bit and for me it is _not_ 
visible enough in plain text. ... So I'm inclined to remove it for the 
initial (beta) release. ...

The INLINE "⠒ braille⠶ " pair retains merit (let us find a similar 
alternative that is more "visible").

WHY?
Because for inline it is far better to have single characters than doubled. "X 
text Y" is much better than "XY text YX" for readability and typing.

For these reasons I hope you will keep it for now!

Best wishes
TT
On Monday, 23 November 2020 at 14:27:12 UTC+1 PMario wrote:

> Sorry for the late reply. ... I Wasn't aware, that I can only see, if 
> something is going on, if I change the group :/
>
> On Wednesday, November 18, 2020 at 11:48:23 PM UTC+1 TonyM wrote:
> ...
>
>> So perhaps we now need to ask
>>
>>- How do we go about a degree of rationalisation
>>- code pages English + Extended Symbols and utilities eg mathematical 
>>alphanumeric's
>>- font recommendations
>>- Multi-Platform support
>>
>> TT What do you perceive should be included?. 
>>
>
> Hi folks, 
> Interesting discussion. I did implement the different glyphs, for 
> experimentation, so we can see how it works out. My conclusion atm is: That 
> it creates way more problems, as it solves. .. Really! I don't want to 
> explain, that users need a special font. .. It has to work out of the box. 
>
> At the moment we have:
>
>- There are 4 "inline" elements
>   - __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
>- There are 6 "block" elements
>   - pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›
>
> I did play around with "braille" a little bit and for me it is _not_ 
> visible enough in plain text. ... So I'm inclined to remove it for the 
> initial (beta) release. ... 
>
> I do like "underscore" because it's easy to see in plain text, but it 
> needs more internal code :/.
>
> "little" causes unicode problems. ... I'd like to remove it.
>
> So I may end up with "underscore" and "slash". They don't cause unicode 
> problems and are present on every keyboard. 
>
> ---
>
> I'm inclined to stick with the block elements for the initial release. 
>
> 
>
> My main point is, that I don't what to deal with the unicode support 
> problems. The advanced usecase of the plugin is difficult enough to 
> explain. 
>
> just some thoughts. 
> -mario
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8997d8bc-bc1e-42e5-b54c-f67820f0a433n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-25 Thread @TiddlyTweeter

*Goodbye ﹙ little﹚, Hello Font Supported Unicode*

PMario ...
"little" causes unicode problems. ... I'd like to remove it.  

I agree. (1) because of Unicode support; (2) because it is visually 
ambiguous.

However , worth noting,Tony's push for it can be addressed by other types 
of bracket IF the end user could define ID glyphs.

But for base release I think it is both not determined to be fully font 
supported and potentially confusing visually.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/13512831-90f3-4fb3-94d9-4ba2d5ece475n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-25 Thread @TiddlyTweeter

PMario wrote
The advanced usecase of the plugin is difficult enough to explain.

Right. And the *ordinary* usecase needs time too.

FWIW, after a week away from Custom Markup I had to relearn it.

We really need a "crib sheet"--a one tiddler complete overview--I think, 
eventually.

I would be very happy to help on that if you agree on the need for it.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/836ea61e-1317-4a85-b45b-aae8a8ee5a45n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-24 Thread @TiddlyTweeter

TonyM wrote:

> A quick look for "safe Unicode characters" gave me this 
> https://qntm.org/safe 
> I don't pretend to understand it fully but perhaps TT does.
>

Ciao TonyM. It is interesting and matches my understanding. Its actually 
reads more "scary" that we need. Most of the mentioned caveats would not 
arise in TW usage,
The reason it sounds somewhat complex is it is about Unicode in general (in 
any app). But WE only need be concerned with how it works in HTML & JS.

One big point he makes is about "Diacritical Marks" ("Combining 
Characters"). Actually the way they are used in HTML means you can use them 
NON-combining in a way you can't in most word processors. So that part of 
it take with a pinch of salt. Especially as those glyphs are common in 
European language fonts and could be useful.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/57464e16-95a6-4f55-b5cd-d63a1b5792a0n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-24 Thread @TiddlyTweeter

*The Problem With _Underscore_*

PMario...
I do like "underscore" because it's easy to see in plain text, but it needs 
more internal code :/.  

Hi Mario. In previous posts I have tried to show, with examples, why I 
think underscore is NOT a good idea.
Basically, IF it were not already used in TW for markup, I'd say it was 
brilliant. But is IS used already.

*I think using it in Custom Markup will be confusing.*

My two cents
TT
 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5d74eb96-70d2-4974-b181-e5c2ce46dd68n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-24 Thread @TiddlyTweeter

PMario wrote:

>
> My main point is, that I don't what to deal with the unicode support 
> problems. The advanced usecase of the plugin is difficult enough to 
> explain. 
>

Right. In any case the DEFAULT glyphs in the standard plugin I hope are 
finite in number and (pretty sure to be) in fonts on ALL machines.
Otherwise, as you say, it could become a support nightmare of missing fonts.
With at least some of them on KEYBOARD, so much the better too.

My interest in exploring Unicode is ...

-- IF you ever allowed a method to allow advanced users to define IDs. :-)

-- I think it could be VERY useful to be able to do so.

But note I also agree with TonyM that *there is more font support than we 
perhaps realise*.
The PROBLEM is to have a robust method to precisely determine what Unicode 
characters are UNIVERSALLY SUPPORTED.

My thoughts
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/24bee47a-9bd5-47e2-beb3-82b8e7394490n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-20 Thread @TiddlyTweeter

Ciao TonyM

   - Determine if Unicode is present in a given wiki (higher Unicode 
   character search?)

Tech point.

To use regular expressions for higher Unicode (it would go through JS) in 
TW is simplest if one uses single Unicode code points in RANGES.
JS regex ranges for Unicode are recognised easily BUT there are TWO 
different methods which makes it confusing at first.

As far as I am aware only Tiddler Commander directly currently supports the 
consistently effective method (every character point is represented by only 
ONE hex number). This behavior is initiated via a regex flag (/u). 

Best wishes
TT

On Wednesday, 18 November 2020 at 23:48:23 UTC+1 TonyM wrote:

> TT,
>
> I was thinking on this matter of unicode support, which could have 
> consequences both for and in the use of custom wikitext. In many ways 
> tiddlywiki "supports" Unicode, however for example no Unicode is usable in 
> fieldnames, yet it is in titles, text and field values etc... However there 
> is no reason we should not have a plugin and or a configuration option that 
> supports Unicode. Not withstanding the need for local fonts, for example, 
> windows covers most Unicode. 
>
> Now Unicode is a broad set and the large range of languages supported do 
> not necessarily need to be part of a standard distribution, somehow we need 
> to be both selective and try to be exhaustive or at least provide guidance. 
> If I were a speaker of another language I may already be using fonts in my 
> language and keyboards that support it. 
>
> To Support Unicode it would be good if we had the tools to;
>
>- Detect if extended Unicode is in use in content during import
>- Determine if Unicode is present in a given wiki (higher Unicode 
>character search?)
>- Provide information on what people will see when there is a missing 
>font and how to remedy it
>- Perhaps a plugin that once active provides a subset of Unicode 
>support, and if not so does not. basically designers or users will need to 
>opt in to the more extensive Unicode, and on visiting a tiddlywiki we can 
>see if the author has chosen to support extended Unicode.
>
> In may ways these activities are future issues being given strategic 
> consideration today, along with the conscious decision to use "special 
> characters" in the customise text solution.
>
> Why do I care?
>
>- As a designer or author access to extended character sets offers 
>substantial potential.
>- TiddlyWiki is a master in knowledge and information storage and will 
>benefit from robust support.
>- As Unicode use grows TiddlyWiki can be a leader in its use.
>- There are some nice innovations and self documentation features that 
>can come from extended characters, in effect namespaces and more.
>
> So perhaps we now need to ask
>
>- How do we go about a degree of rationalisation
>- code pages English + Extended Symbols and utilities eg mathematical 
>alphanumeric's
>- font recommendations
>- Multi-Platform support
>
> TT What do you perceive should be included?. 
>
> Regards
> TonyM
> On Wednesday, 18 November 2020 at 22:18:33 UTC+11 @TiddlyTweeter wrote:
>
>> Ciao Tony & PMario
>>
>> TonyM wrote:
>>>
>>>
>>> I had not tested Android, although a big user. 
>>>
>>
>> I think Android matters. Though personally I never use it for heavy edit, 
>> its clear that lots of people do.
>>
>> It DOES raise an interesting issue of relevance to PMario too.
>>
>> I think it got clear through the 4 threads in this discussion that 
>> UNIVERSAL support for ...
>>
>> -- Default Keyboards is likely IMPOSSIBLE
>>
>> -- Direct insertion via Keyboard ShortsCuts, and The Stamp Tool, is NOT 
>> TOO DIFFICULT
>>
>> -- Unicode FONT SUPPORT requires research into CROSS-PLATFORM conditions.
>>
>>
>> For the DEFAULT plugin markup IDs it is BEST to have UNIVERSAL FONT 
>> SUPPORT.  
>> Otherwise we will create a huge "support problem".
>>
>> Therefore: in examining Candidate Glyphs the single most important issue 
>> is good FONT support.
>>
>> I'm stating the obvious. But answering it is not trivial.
>>
>> Best wishes
>> TT 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/59fed92d-d46d-4675-8afe-170594df80f3n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-18 Thread @TiddlyTweeter

Ciao Tony & PMario

TonyM wrote:
>
>
> I had not tested Android, although a big user. 
>

I think Android matters. Though personally I never use it for heavy edit, 
its clear that lots of people do.

It DOES raise an interesting issue of relevance to PMario too.

I think it got clear through the 4 threads in this discussion that 
UNIVERSAL support for ...

-- Default Keyboards is likely IMPOSSIBLE

-- Direct insertion via Keyboard ShortsCuts, and The Stamp Tool, is NOT TOO 
DIFFICULT

-- Unicode FONT SUPPORT requires research into CROSS-PLATFORM conditions.

For the DEFAULT plugin markup IDs it is BEST to have UNIVERSAL FONT 
SUPPORT.  
Otherwise we will create a huge "support problem".

Therefore: in examining Candidate Glyphs the single most important issue is 
good FONT support.

I'm stating the obvious. But answering it is not trivial.

Best wishes
TT 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/4039680e-9810-42b9-9763-2ca5536ebe8ao%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-18 Thread @TiddlyTweeter

TonyM wrote:
>
>
> determining one freely available that can ensure the lions share of 
> Unicode is available, this is what we must do.
>

Right!

I been looking at various methods for doing that.

I use BabelMap Portable, which is pretty good, to examine the font 
substitution process.

It is highly UNLIKELY with more esoteric glyphs that common fonts will hold 
them. 
Though many ARE available on local machines through substitution.

What we really need, IMO, is a TW that can be designed so that it itself 
presents selected Glyphs in various fonts (and ONLY those fonts).
The online tools I looked at for this (i.e. seeing precisely which Unicode 
characters render in which font) are not really adequate to our needs.
I'm trying to find a consistent & quick way to answer the issues of font 
support for TW in TW. 

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5b29cb67-df74-4230-a105-a179300f876fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-14 Thread @TiddlyTweeter

Tony & PMario

This illustrates issues in Font Support I mentoned earlier & in the main 
group.

In choosing Unicode solutions we do need to ensure they have font support 
across OS.

On Windows 10 I see (correct) ...

[image: Screenshot 2020-11-14 103852.jpg]
... On my Android 8 the lead Unicode characters don't have font support  ...

[image: Screenshot 2020-11-14 105020.jpg]

This is why I refer to the "black art of Unicode". For reliable working 
there needs to be quite a lot of checking.

Best wishes
TT


On Wednesday, 11 November 2020 23:38:34 UTC+1, TonyM wrote:
>
> Further to this generic element solution;
>
> Eg;
> ⮰td terminates end of line
> ⭭tr terminates with /tr
>
> Only valid at the beginning of line it should be rare that a clash would 
> occur.
>
> Tony
>
> On Thursday, 12 November 2020 09:18:24 UTC+11, TonyM wrote:
>>
>> Mario,
>>
>> I think I raised this previously, that perhaps one glyph should resort to 
>> the element being equal to the symbol.
>>
>> Why?
>>
>> Because a large set of possibilities are opened up even without using the 
>> customise pragma just some defaults.
>>
>> Eg;
>> 'tr 
>> would expect /tr and wrap the content in 
>> 
>> Without any further customisation.
>>
>> ie; the symbol is automatically adopted as the _element 
>> Sure this can be customised however there are many cases where this, and 
>> perhaps a .classname is more than enough
>>
>> Of course another glyph that does the same automatically terminates on /n 
>> would also help eg;
>> 'tr
>> °td contents of table detail
>> /tr
>>
>> °li contents of list item
>> °li.bold bold contents of list item
>>
>> This is another way to help html/css savy users to make use of this 
>> solution right out of the box with no customising.
>>
>> I could look from some appropriate glyphs rather than the above ' and °
>>
>> Regards
>> Tones
>>
>>
>> On Saturday, 7 November 2020 09:39:43 UTC+11, TonyM wrote:
>>>
>>> Mario,
>>>
>>> That's why I favour customised 'tr and /tr  but then you have to be 
>>> familiar with html tables. 
>>>
>>> Regards
>>> Tony
>>>
>>> On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:

 Hi,

 I did a bit more docs for table formatting. So there are the same 
 formatting options as available with standard wikitext. 
 The only problem is, to find good "start" and "end" symbols, to make 
 the wikitext readable. 

 -m

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/164fa505-02c1-4577-94e8-4ad24cb40656o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-07 Thread @TiddlyTweeter

Ciao PMario

Sorry. I am getting lost in the wiki!

What Tiddlers do I need to look at to understand the additions/docs?

I'll comment then.

Best wishes
TT

On Friday, 6 November 2020 11:13:23 UTC+1, PMario wrote:
>
> Hi,
>
> I did a bit more docs for table formatting. So there are the same 
> formatting options as available with standard wikitext. 
> The only problem is, to find good "start" and "end" symbols, to make the 
> wikitext readable. 
>
> -m
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/60a3b004-44a7-4f7d-a325-b5072f76f466o%40googlegroups.com.

[twdev] Re: Writing Forms (not HTML forms, ways of writing)

2020-11-05 Thread @TiddlyTweeter

The OT is about supporting WRITING that, minimally, questions the, online, 
MODERN PARAGRAPH.

PMario got the idea.That its about concepts of what "text expression" is.

I DO like both Corey & TonyM's ideas, though neither address the OP.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b21e2e96-e38d-4a92-898a-92b3a5f0ce0eo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-02 Thread @TiddlyTweeter

Ciao PMario & TonyM

I'm pretty sure that when Unicode started in 1991  
there was no idea that the characters 
would often get later "hi-jacked" for purposes never intended!

What we have in Unicode is a very vigorous standard that is then partially 
trashed FROM LACK OF ATTENTION TO THE NET AS AN EMERGENT SYMBOLIC LANGUAGE. 
Meaning, the origin of Unicode completely neglected that the Web was itself 
a language, deserving a dedicated plane. 

Its still like that.

IMO "we" basically, I mean ALL of us, are using it in a "bent" way a lot of 
the time.

Its got quite like the "Net" before the content/structure ideas emerged 
into "Web Standards" that cleaned things up.

Side thoughts
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/d239cd79-d974-46e2-8f5b-21765a252feco%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-02 Thread @TiddlyTweeter

Ciao TonyM

At some point I think we should go through the whole of Unicode Basic Plane 
and give a chart of USEFUL GLYPHS FOR MARKUP.
There are a lot of them, but they aren't infinite.

IMO understanding what is in Unicode AND supported in fonts on users 
machines by default is a primary issue.

Thoughts
TT

On Monday, 2 November 2020 09:52:33 UTC+1, TonyM wrote:
>
> Idea,
>
> It would be quite simple to find all uses of glyphname=symbolname 
> throughout a wiki to provide a Editor toolbar drop down list of existing 
> glyph/symbol definitions and on click insert them at the current location 
>  so the custom definitions are easier to lookup and 
> select. Self documenting if the symbols are chosen well.
>
> Tony
>
> On Sunday, 1 November 2020 11:44:36 UTC+11, TonyM wrote:
>>
>> TT,
>>
>> I did read your history, it's Quite interesting. And to some extent I 
>> defer to you, but in my return quote I pointed out the "modern" use of 
>> Pilcrow.
>>
>> It is interesting to know where the indented 1st line of a paragraph 
>> comes from, something I have never liked the aesthetics of, to be honest. 
>> You may be interested in this 
>> https://unicode.org/L2/L2016/16235-two-medieval-chars.pdf
>>
>> What I do hope is in the end we can accommodate different mark-up needs, 
>> and in fact that is the value of this project. That is one reason I 
>> speculated if it were possible to have an end of line only mark-up symbol, 
>> not only because that is the way I would be inclined to use pilcrows, but 
>> to support other end of line annotations. I believe this may already be 
>> achieved with inline mark-up placed at the end of line. One persons end of 
>> line is another's beginning of line anyway, for example I can imagine ﹙¶
>> ﹚.
>>
>> I could see someone with the interest providing both the plugin and 
>> custom for anyone of these different systems. Not unlike they way a 
>> mathematician may extend tiddlywiki to their own mark-up language to 
>> represent complex maths, perhaps people may do this for old English, 
>> newspapers, PageMaker (One of the first professional printing applications 
>> and the use of postscript 
>> <https://www.hackworth.co/what-is-postscript-and-why-do-almost-all-high-end-printers-support-it/>).
>>  
>> The key being people can make tiddlywiki their own, in new ways, through 
>> the value of mark-up. Or as an example people preparing medieval style 
>> texts or writing about them.
>>
>> One example I am aware of is using custom mark-up to write HTML via 
>> shortcuts. Combined with tiddlywiki's automation I have always seen the 
>> potential for tiddlywiki to be configured to be a site designer and 
>> generator as well, this is where using html elements are helpful. One thing 
>> that excites me a lot is using an "arbitrary html tag" inside a custom 
>> mark-up. Basically it allows the writer to contain custom css and other 
>> "semantically appropriate" sections in the document. Add to this 
>> transclusion and macros an one could potentially generate a website by 
>> filling in some content settings and export (via zip) a whole multi-page 
>> site. Could this be a SquareSpace Wix killer? I have experimented with 
>> connecting to html and external javascript and there is a lot of potential 
>> there for more host interaction, I just do not have the skills yet.
>>
>> Yet another thought of late, is in response to filters, logical operators 
>> and the fact that filters handle sets. It seems to me the introduction of 
>> annotation for basic set manipulations would also be helpful. See in the 
>> pre-release https://tiddlywiki.com/prerelease/#Filter%20Expression 
>> Equivalent 
>> named prefix
>>
>> Regards
>> Tony
>>
>>
>> On Sunday, 1 November 2020 03:57:52 UTC+11, @TiddlyTweeter wrote:
>>>
>>> TonyM wrote:
>>>>
>>>> ¶
>>>> I would not bother with the use of pilcrow unless it was part of an end 
>>>> of line form of glyph only. 
>>>>
>>>
>>> Pilcrow has a complex history before printing, in printing & on the net. 
>>> They all diverge & overlap.
>>>
>>> Essentially the paragraph "mark" is a signal for a "longer pause" in 
>>> thought in all incarnations.
>>>
>>> I mention a bit of its history in some comments to PMario above.
>>>
>>> Best wishes
>>> TT
>>>
>>>   
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/f40d1b75-2425-4518-96a5-a24b42fb01a4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

2020-11-02 Thread @TiddlyTweeter

Looking at the SYNTAX for your Table Markup looks good!

I'd need to actually be able to use it to say more than that.

For instance, does it preserve the ALIGNMENT and CELL-MERGING tricks that 
current Wiki-Text has?

I personally think that Jeremy's WikiText for Tables is pretty amazing :-) 
So if you can go better--well--so much the better! :-)

Best wishes
TT

On Friday, 30 October 2020 14:55:25 UTC+1, PMario wrote:
>
> 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
>
> and: https://wikilabs.github.io/editions/custom-markup/#test-dave-table
>
> 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
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/ab0483df-97a5-47ad-a258-aaa87afa1645o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

TonyM wrote:
>
> ¶
> I would not bother with the use of pilcrow unless it was part of an end of 
> line form of glyph only. 
>

Pilcrow has a complex history before printing, in printing & on the net. 
They all diverge & overlap.

Essentially the paragraph "mark" is a signal for a "longer pause" in 
thought in all incarnations.

I mention a bit of its history in some comments to PMario above.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3efbe326-1823-4f3c-a21c-d1f7442790b0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

TonyM

Minor footnote clarifying an issue that comes up often in understanding 
Unicode font implementations.

There is masses to understand about Unicode!

My post mentioned that ...

None of the usual fonts European Language speakers would explicitly set in 
> TW settings have any of them (the doubled brackets) except Cambria Maths.


Why?

Because Asian languages use the same style of brackets NOT for Maths in 
normal writing. SO the WELL DESIGNED MATHS FONT includes, helpfully, 
duplicate signs that are for direct *non-math use* by Asian writers.

Best wishes
TT

On Saturday, 31 October 2020 09:42:25 UTC+1, @TiddlyTweeter wrote:
>
> *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 ...
>
> 【】〘〙〚〛〖〗
>
> 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
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/0e2681e6-99f5-4773-b06f-180467a4f410o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

Ciao PMario
 

> @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 :-)
>>
>
>
PMario ... 

> *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. ... 
>

Okay. Good. 

*Actually your pilcrow example is FINE!*

My issue is its hard to explain if I can't code it to make examples, but I 
can't code examples it until its done enough to code them. 

It's a "chicken-and-egg" problem. 
So let's leave that aside for now?

Right now, I reviewed my thoughts on this and I suspect it  is very few 
"base block glyphs" I'd like to be able to set. 
They are ALL "block" elements. "Inline" I can foresee about a dozen ;-). 
But they can be handled well IF in inline we can do ELEMENTS as we do for 
blocks already.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/d2027246-87d8-4e38-8fb2-72d2b3af79eao%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

PMario wrote:
>
> @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 
>> <https://en.wikipedia.org/wiki/Rubrication> 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] <https://en.wikipedia.org/wiki/Pilcrow#cite_note-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 :)
>

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

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/bd8089de-9f41-402f-8b8a-049b35457b89o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

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

On Wednesday, 28 October 2020 15:53:12 UTC+1, PMario wrote:
>
> 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 
> <https://en.wikipedia.org/wiki/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
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/1da32d83-e218-4b1c-8d84-ae02cbdf0955o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

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

On Saturday, 31 October 2020 09:14:29 UTC+1, PMario wrote:
>
> 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
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b2a80e2b-0932-4556-8a32-8a619e7e93d6o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

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 ...

【】〘〙〚〛〖〗

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. I'm not sure if its a problem for some Asian 
TW users.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/6cdbe216-5167-45dc-aa55-49180e368cc3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

PMario wrote:

Inline nesting seems to have a problem. 


Right. I noticed that. Hope its solvable!

Best wishes
TT 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/a5de16bd-ccbb-4268-97a0-1e94476c16e1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

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

On Saturday, 31 October 2020 02:03:36 UTC+1, TonyM wrote:
>
> Do note I found these alternate small braces that may be better.
> ﹙₍ ₎﹚
>
> Regards
> Tony
>
> On Saturday, 31 October 2020 12:01:43 UTC+11, TonyM wrote:
>>
>> 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
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/568f4f4e-ac06-42cd-9249-7b0071eaf74fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*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

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/fa7cf420-eb06-41a4-b63f-f9e4cbf44904o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*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

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/bf731c1f-bb52-4d42-8943-18316163302do%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*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.

In line with 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 somewhat blunt instrument.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b0008013-2cac-4099-98d5-ad1aa9e52863o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

TonyM wrote ...
>
>
>  ... in this set I cant see the Maths alphanumerics 
> https://www.unicode.org/charts/PDF/U1D400.pdf
>

Right. That is a chart of Unicode "Supplementary Plane: Mathematical 
Alphanumeric Symbols". Unicode 1D400 to 1D7FF (996 characters).

Something you may not yet be aware of (it would be useful for you to know, 
I think!) is that the characters can't always be represented using a single 
character directly (applies to characters above ). 

At the end-user level this is not an issue if you dealing visually. But it 
CAN be an issue in search & coding. All Unicode can be represented BUT 
there is more than one method! One for the  Unicode Basic Multilingual 
Plane characters (up to ) and other ways above that retrofit to webpage 
address space by "combining characters".

FYI I looked up the font substitution cascade on my local computer (Win 10 
default fonts) for  "Mathematical Alphanumeric Symbols" and the only main 
font that supported them is *Cambria Maths.*

IMO, on the whole its worth looking though the *Basic Multilingual Plane *first 
for characters before additional planes (which have some caveats I 
mentioned). The Basic Plane is itself massive!

Best wishes
TT



-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b977b848-6741-4091-b3d0-1ca6453384c1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Using Unicode

Hi TonyM

In the spirit of learning about using Unicode ...

You can also turn them into SVG icons
> 
>   𝝣
>  
>
>>
>>
Right. And *not *so right.

The issue is that Unicode is NOT a font. Its simply a  code for a character.
The actual font representation you see will DIFFER with the font that is 
rendered.
That will differ according to fonts available and their substitution 
cascade on target systems.

To try make this clearer for you look up Unicode 25B6, that's HTML ▶

Its in Unicode called: BLACK RIGHT-POINTING TRIANGLE.
In much net use its the "Play Button" ...

And look here to see examples of the result on different systems ... 
https://emojipedia.org/play-button/

*Point is in design for on-line usage often you need to explore the fonts 
that will exist on target users systems for consistency.*

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/97159322-7353-4cc4-ab0c-57c8216086c4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*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 ground*﹙terra 
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: ﹚
>
> d) is only nestable if one of the others is used. I'm not sure, if I like 
> this behaviour. ... 
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/4bdc7280-dbea-4db8-a4a4-e5a7c955c551o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*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

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/51dc7c39-5731-4ba6-9146-2c335989d1ado%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*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

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8ec6b076-5972-4072-818f-1fdce751ac4fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*No 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

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/6e7dff5e-ef00-4eef-a70e-95fc56dd2ba3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

*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

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/529e7edd-3184-48f1-8bc0-b28454d7c697o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)


>
> I use this one, it names them nicely: 
> https://www.compart.com/en/unicode/category


That is a good Unicode resource because it honors Unicode, yet gives 
additional ways to navigate.

TT

On Monday, 26 October 2020 14:37:08 UTC+1, PMario wrote:
>
> On Monday, October 26, 2020 at 2:21:44 AM UTC+1, TonyM wrote:
>
> The best resource I have found now is https://www.unicode.org/charts/
>>
>
> I use this one, it names them nicely: 
> https://www.compart.com/en/unicode/category
>
> -m
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/a22d6fea-52d6-4a40-8c97-b8f395758e60o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*How Can Unicode Help?*

I, for myself, did a UNICODE exploration of PAIRED MARKUP characters. 
By "markup" I actually mean LITERAL markup characters used by workers in 
the PRINT industry. 

No Maths was added.

I also added PMario's mashup ideas. As well as stuff I know already.

Let me know IF you want me to post these!

Best wishes
TT

On Friday, 25 September 2020 13:46:32 UTC+2, PMario wrote:
>
> Hi folks,
>
> This is the continuation of Custom markup 
>  
> [1] and Custom markup (continued) 
> and Custom 
> markup (continued 2) 
>  [2]
>
> Let's start a new one before [2] starts to use pagination. 
> Have a closer look at link [1] it's possible to show all the topics in 1 
> page
>
> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>  the above link won't 
> work anymore!
> have fun!
> mario
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/75b7da87-e0ee-4d25-ba46-5f46bb69f566o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao Tony

One issue with Unicode is that it identifies all "unique character" 
addressing (i.e. each character has a unique code) BUT is totally agnostic 
about how they are REPRESENTED in fonts. Font variations can give 
unexpected results.

Much of the time this is not an issue. But sometimes it is.

I DO think taking Unicode more seriously in TW is definitely a good idea. 
Frees us up from the standards of 1986 that are no longer needed. 

BUT there are several "trip-up" points along the way to be understood & 
skirted.

Best wishes
TT

On Monday, 26 October 2020 02:21:44 UTC+1, TonyM wrote:
>
> Folks,
>
> Just sharing some Unicode exploration
>
> The best resource I have found now is https://www.unicode.org/charts/
>
> Fullwidth brackets FF5F ｟ FULLWIDTH LEFT WHITE PARENTHESIS • the most 
> commonly occurring glyph variant looks like doubled parentheses → 2E28 ⸨  
> left double parenthesis ≈ 2985 ⦅ FF60 ｠ FULLWIDTH RIGHT 
> 3010 【 LEFT BLACK LENTICULAR BRACKET 3011 】 RIGHT BLACK LENTICULAR BRACKET
>
>
> You can also turn them into SVG icons
> 
>   𝝣
>  
>
> Of note all the standard characters have a mathematical equivalent.
>
> We can also find Mayan numerals to 19 
> https://www.unicode.org/charts/PDF/U1D2E0.pdf
>
> Also I found a set of small punctuation symbols, that look the same only 
> small, but they are separate characters
> https://www.unicode.org/charts/PDF/UFE50.pdf
>
> so we could use ﹙ to mark inline ﹚ then continue
>
> compare with  (﹙  ﹚) so we could use (﹙ to mark inline ﹚) then continue
>
> Tony
>
> On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>>
>> Hi folks,
>>
>> This is the continuation of Custom markup 
>>  
>> [1] and Custom markup (continued) 
>> and 
>> Custom 
>> markup (continued 2) 
>>  [2]
>>
>> Let's start a new one before [2] starts to use pagination. 
>> Have a closer look at link [1] it's possible to show all the topics in 1 
>> page
>>
>> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>>  the above link 
>> won't work anymore!
>> have fun!
>> mario
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/54cfd77b-338f-424f-80fb-1406774891f7o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao TonyM

You will see on the main group I commented about ensuring FONT support for 
online TW.

In your case here you likely on safe(ish) ground.
But it would be worth checking the individual listed TW fonts to establish 
that end users can SEE them always.
BabelMap is a free Unicode/font tool to do that.

Basically we need a methodology to determine WHAT useful characters in TW 
would always be there for end users ONLINE?

We not there yet.

Best wishes
TT


On Monday, 26 October 2020 02:21:44 UTC+1, TonyM wrote:
>
> Folks,
>
> Just sharing some Unicode exploration
>
> The best resource I have found now is https://www.unicode.org/charts/
>
> Fullwidth brackets FF5F ｟ FULLWIDTH LEFT WHITE PARENTHESIS • the most 
> commonly occurring glyph variant looks like doubled parentheses → 2E28 ⸨  
> left double parenthesis ≈ 2985 ⦅ FF60 ｠ FULLWIDTH RIGHT 
> 3010 【 LEFT BLACK LENTICULAR BRACKET 3011 】 RIGHT BLACK LENTICULAR BRACKET
>
>
> You can also turn them into SVG icons
> 
>   𝝣
>  
>
> Of note all the standard characters have a mathematical equivalent.
>
> We can also find Mayan numerals to 19 
> https://www.unicode.org/charts/PDF/U1D2E0.pdf
>
> Also I found a set of small punctuation symbols, that look the same only 
> small, but they are separate characters
> https://www.unicode.org/charts/PDF/UFE50.pdf
>
> so we could use ﹙ to mark inline ﹚ then continue
>
> compare with  (﹙  ﹚) so we could use (﹙ to mark inline ﹚) then continue
>
> Tony
>
> On Friday, 25 September 2020 21:46:32 UTC+10, PMario wrote:
>>
>> Hi folks,
>>
>> This is the continuation of Custom markup 
>>  
>> [1] and Custom markup (continued) 
>> and 
>> Custom 
>> markup (continued 2) 
>>  [2]
>>
>> Let's start a new one before [2] starts to use pagination. 
>> Have a closer look at link [1] it's possible to show all the topics in 1 
>> page
>>
>> starting with  V 0.5.1 https://wikilabs.github.io/editions/custom-markup/ 
>>  the above link 
>> won't work anymore!
>> have fun!
>> mario
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/71ab7927-04d1-43d2-b13d-d992c24be821o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)


*How to dynamically change Custom Markup styling USING a Custom Markup 
launched macro  ...*

Ciao Tony

When I get back to reviewing the customise solution I will demonstrate a 
> method for your need.


The issue is NOT Custom Markup per se. Assume that is DONE already. And 
well.

Rather, the issue is DYNAMIC modification of CSS style values for styles 
already applied.

The Palette macro instantiates an economical stable approach that 
illustrates a solution.

IF you have time to explore this it could be useful. For ...

1 - MY needs;

2 - WIDER demonstration of the utility of macros UNDER Custom Markup.

I think it is point (2) that has most gravitas.

Best wishes
TT
 
On Friday, 23 October 2020 04:50:56 UTC+2, TonyM wrote:
>
> TT,
>
> This requirement is a fundamental aspect of the customise solution, which 
> started with an idea called dot paragraphs. 
> This idea had a leading . on any line causes subsequent lines to be 
> treated as a single paragraph unit a \n is reached.
>
> In your case arguably you want to use a div or span rather than a p
>
> \customise tick=div _element=div
>
>
> When I get back to reviewing the customise solution I will demonstrate a 
> method for your need.
>
> In short it is I believe already possible.
>
> Tones
>
>
>
>
> On Friday, 23 October 2020 01:28:37 UTC+11, @TiddlyTweeter wrote:
>>
>> Ciao Tony
>>
>> Me ... 
>>
>>> A SERIOUS use case would be HOW to invoke dynamic style change via 
>>>> inline buttons.
>>>>
>>>  
>> TonyM ...
>>
>>>  Can you give an example?
>>
>>
>> A simple one would be to able to dynamically change "block style" for 
>> paragraphs. I'm interested in archaic forms of writing where there is NO 
>> gap between paragraphs. They form one flow.
>>
>> Being able to do this simply by changing  ...
>>
>> p.archaic {
>>   display: 
>> }
>>
>> ... from "block" to "inline" in a stylesheet that is otherwise unchanged 
>> would be ace.
>>
>> Hope that is clearer on my aim!
>> TT
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/4751355e-9179-49ea-b727-a83a87da6cd6o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Plee for TWO Inline markers*

PMario wrote:
>
>
> Yes. There will be only 1 inline maker ...
>

This is my last :-) attempt to argue for TWO INLINE MARKERS.

Why?

1 - Let's take the Braille possibility. It is EXCELLENT visually as we 
already discussed. But what if you are blind?  You need Braille.
 Giving a SECOND markup syntax you can let braille writers/readers use 
Custom Markup without them having to use Braille symbols.

2 - Let's take case of complex nested markup. Having MORE THAN ONE way of 
marking up inline is MUCH MORE READABLE ... Do you want to maintain this ...

This _encloses _an enclosure

... or this? ...

This _encloses *⠒*an enclosure*⠶*__

The last version is much easier to read.

3 - It's pretty cheap to do & I think viable? So why not :-)?

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/91bea42c-b88e-4896-949b-6dbaa82cedc2o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*On Being Able To Comment Custom Markup Pragma*

This, I am sure, will help enormously on uptake.

Being able to comment pragma will help a lot! No least because Custom 
Markup is advanced use of parsing and it will often need in-context 
comments to enable end users to make best use of it.

Best wishes
TT

PMario wrote:
>
> On Friday, October 23, 2020 at 1:28:39 PM UTC+2, PMario wrote:
>
> *Pragma Comment*
>>
>> Could be
>>
>> \\ comment comes here till the end of the line
>>
>>
> We are lucky :)
>  
>
>> \\ If pragma comments are used here they are faster as used in the define 
>> block.
>> \\ This comment doesn't produce a parse-tree element!!
>>
>  
>
>> \\define test()   <- this is a comment now
>> \\ this comment is as slow as
>> \\ 
>>
> \\end  <- this is a comment now
>>
>
> Will be active in V0.7.0 ... soon !!
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/665b5c38-f834-4f9a-9c9a-92936a47539co%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*YES. Do use Unicode Glyphs when they have FONT support in TW!*

PMario wrote:
>
> So ⠪.class:param Braille 246 and Braille 2345⠞ may be an option. 
>
>  - So it's Braille: 246 as a start, which seems to be not used by the 
> default alphabet. 
>  - And Braille 2345, which is letter: t
>
> They will be hard to type, but can be predefined. .. 
>
> What do you think about: 25 as start: ⠒ and 2356 as stop: ⠶
>

We discussed already the very complex issue of (1) providing markup glyphs 
that WORK VISUALLY; (2) that are SUPPORTED in default TW FONT assignments. 
Matching both criterion is not easy.

Your discovery that Braiile characters  *⠒ & **⠶* would work (be supported 
by TW fonts) I think brilliant!

I think that pair is an EXCELLENT choice.

Some may complain that they are not on keyboards. But that applies to most 
every new markup character. It is simply NOT possible to support new 
characters on keyboards universally. But all we need is an Editor driven 
button / or key-combo to solve that subsidiary issue, which is easy.

So, I am very in FAVOR of *⠒ & **⠶ *solution. Mainly because it VISUALLY 
makes sense for markup (*⠒ = open & **⠶ = close*) . They are unambiguous, 
single characters, VISUALLY elegant.

Thoughts
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/af500787-baa0-41ad-939f-dfc7ff652ddbo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*On Implicit Closure (i.e. "single open with auto-closure on first \s")*

PMario wrote:
>
> It doesn't work out with a "single" start char. Way to many problems with
> TW variable names eg: _element ... if there is no `_element` definition. :/
>

That is a shame :-(.

It makes my "Shorthand Use Case" that you, PMario, understand much more
verbose than it strictly needs to be ...

So instead of "*_S.in*" I'll need to write things like "*_S.in__"*

That looks innocent till you see (for example) what it could look like in
code in bulk ...

*_S.in **_S.in **_S.in **_S.in **_S.in **_S.in **_S.in **_S.in **_S.in **_S.in
*

... versus ...

*_S.in__ **_S.in__ **_S.in__ **_S.in__ **_S.in__ **_S.in__ **_S.in__ **_S.in__
**_S.in__ **_S.in__ *

In WRITING text its V. MESSY visually for my specific use case.

But I do recognize the limits you encountered in the TW extant parser you
are interfacing with.

I may have* a way round *the PROBLEM. It only occurs in writing. So a
solution is to write as I need and automate the insertion of the Custom
Markup glyphs after I have written what I want. the issue for me is ONLY in
the writing really, the code I don't really care so long as it works.

BUT I wanted you to understand and see the issue that *the more characters
you insert the harder WikiText gets to read!*

Best wishes
TT

--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/0e2bb343-1568-487a-acab-a17d6c4199d7o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

PMario wrote:

I was experimenting with: /° some text /° nested text °/°/
> But I personally think, that's *confusing.*


I AGREE.

If you are *manually typing *those kinds of combinations its a recipe for 
failure.

The problem is *both* visual and conceptual.

Conceptually the HTML "echo" implies that ° ... /° is most suited (i.e. 
on.-tag. off-tag).

Yet VISUALLY */° ... °/ *is much better for implying "sequester" 
(containment).

The problem will be that cognitively these two different possibles are in 
users minds and it will be VERY EASY to confuse them.

That said, IF the user is doing this through highlighting of text to span a 
button press it far less of an issue.

My thoughts
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/8034b8b2-9748-438e-b9ba-12dd1f84ad14o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao PMario

*On Underscore*

__ double-underscore can be a start and - underscore slash could be stop _/  
> ??? or triple underscore ___ as stop. I personally wouldn't have a big 
> problem with those combinations. 


A few points.

1 - I AGREE that underscore is BETTER for INLINE than BLOCK. 
  Visually "_" initiates an implying that "sequestered" text (i.e. 
contained *_text bits__*)  will be styled. 
  It really is better for inline, but never blocks.

  So, IMO, (please note) I don't think it should be used for BLOCKS 
even if it is NOT used for inline (hope this is clear!)

2 - One issue is that visually in some proportional fonts (i.e. not 
mono-spaced in editor) it can get much harder to see on small screens (i.e. 
smartphones) the difference between open and closed.

3 - I'm slightly concerned it will confuse users used to the EXISTING 
method for underlining.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/c916988e-5182-4bc6-a2ce-2c5c8d7a930do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread @TiddlyTweeter

Ciao Tony

Me ... 

> A SERIOUS use case would be HOW to invoke dynamic style change via inline 
>> buttons.
>>
>  
TonyM ...

>  Can you give an example?


A simple one would be to able to dynamically change "block style" for 
paragraphs. I'm interested in archaic forms of writing where there is NO 
gap between paragraphs. They form one flow.

Being able to do this simply by changing  ...

p.archaic {
  display: 
}

... from "block" to "inline" in a stylesheet that is otherwise unchanged 
would be ace.

Hope that is clearer on my aim!
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/22ac474f-328e-4a7f-874d-3b5533b81ed9o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread @TiddlyTweeter

Tony

You were very vocal about the integration of macro invocation via Custom 
Markup.

I'm slightly warming to the idea.  A SERIOUS use case would be HOW to 
invoke dynamic style change via inline buttons.

I *don't *mean simply tagging/untagging  a stylesheet tiddler.

I mean a macro that changes the values of CSS declarations dynamically and 
pass new values simply (like how the Palette system works). 
THAT would, I think, be a superb way to show the power of Custom Markup.

Best, TT

On Thursday, 22 October 2020 11:51:11 UTC+2, TonyM wrote:
>
> Bump,
>
> I too needed a break from this all expansive and innovative rush. But we 
> should try and move it to at least a beta releases before our memories fade.
>
> Please advise if there is something I can do.
>
> Tony
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2e901a53-ddb2-43f7-8e62-404b9477a5fco%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread @TiddlyTweeter

I'm very alive on what PMario is doing. It's very, very useful.

The development of "inline markup" is of concern to me ...

1 - INLINE markup, I commented on before, that IMO we should AVOID 
doubling. Having to type *@@textbits@@ *just to get a span is very 
uneconomic.
 IMO inline markup needs to be (a) the least obtrusive; (b) with the 
least keystrokes.

  I far prefer °textbits° for obvious typing a & visual readabilty 
reasons

2 - On INLINE I also suggested that closure could be on SPACE very 
effectively (regex: \s = space, tab or newline) so that *°textbit *could 
work for items NOT explicitly closed.

3 - Point 2 *implies *that we need TWO inline markers. One for doubling 
(e.g. *´ **text bits/´ *). One for solo (e.g. *°textbit*)
4 - IMO we should withdraw *° *&* ´ * from block markup & replace them. And 
RESERVE them for INLINE only. 
We need glyphs SPECIFIC for inline to ensure minimalism in design.
Those two characters are visually excellent for that job.

I'm aware I'm giving a strong opinion to PMario as developer. I think its 
good to be explicit when you can be.

I hope this is clear. Ask if it isn't.

Best wishes
TT

On Thursday, 22 October 2020 11:51:11 UTC+2, TonyM wrote:
>
> Bump,
>
> I too needed a break from this all expansive and innovative rush. But we 
> should try and move it to at least a beta releases before our memories fade.
>
> Please advise if there is something I can do.
>
> Tony
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/6875427e-0376-4e5b-9a14-edf4fcd68a58o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*--- Definitely OT --- Regarding a use case using "shorthand"*

PMario

>
> Do you have any server based setting to engage with your users? 
>
> I would go a slightly different route. Have eg: about a miniute readable 
> and for the rest you have to be logged in. ...
>

Interesting queries!

Though I have a server service I really don't want to have to code for it.

*Mainly I'm interested in how you can put your right foot behind your neck 
:-)*


IF I can get decent income from publishing my work online I'd PAY someone 
to do it for me :-)

TW is full of hobbyist system admins. But I'm not one of them :-). LOL!

TT























 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/41cb6862-020a-4fe3-9283-40b7fcf7d46do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*--- OT --- Regarding a use case using "shorthand"*
 
TT wrote ...

> Pb Ob Pbk Crl o ll at k // A1 Abk 1 L 2 R
>>
>
PMario wrote ... 

> That's very interesting. So you can read this and it makes sense to you :)
>

I DO :-).

IMO an internet that can't facilitate people who have minds already is a 
waste of time :-)

Where the net gets interesting for me is in what computers do well at: 
repetition, automation, scaling. 

I like to have a slave do grunt work :-). 

TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/db0720ce-875f-407e-8fd5-9a1cf7d5a6d0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Light Relief: A sillygism (a faulty syllogism with a bit of truth)*

1. Unicode aims to support ALL written characters

2. Fonts aim to support SOME written characters

3. Documents support Fonts.

∴ (therefore) ...

SOME documents support SOME Unicode.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3fb7a85f-500f-44d8-9d1c-05e8df5849c1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao TonyM

THB I don't really understand what you are asking for!

The construct in Custom Markup (without a \customize pragma) for ...

´aside test

*already *produces in render ...

test

and

´aside.my-style test

produces in render

test


Likely I am missing your point!

Best wishes
TT



On Tuesday, 6 October 2020 00:49:16 UTC+2, TonyM wrote:
>
> Mario,
>
> Perhaps there is something I do not understand but I am suggesting a 
> specific symbol lets say ¤ as a working symbol
>
>- Perhaps I can state it in different words?
>
>
> Consider this
> \customise sym=elementname _element=elementname
>
> ¤elementname that will internally parse this as if there existed a 
>
> ¤elementname.classname and allowing class names
> You can see the customise is repetitive, but currently it must be explicit
>
> What I am suggesting is there is so much value in using customise just to 
> take a named element name and allow a classname(s) to be applied and close 
> it.
>  line or content 
> So I am asking if it would be possible to to convert any line beginning 
> with a fixed special character to result in a open and close element of the 
> immediate text. Arguably auto close on \n\n
>
> Why;
>
>- HTML elements, open and closed arbitrary or not, could be collapsed 
>to ¤elementname.classname
>- Arbitrary html sections allow the author to mark-up their content 
>according to logical names
>
> This tiddler is about 
>
>- Then with a small set of css or macros and view templates we can 
>alter the display, or search all tiddlers for such content
>- This works well *already* but I was wondering if we can replace this 
>with ¤elementname.classname ?
>- Macros can either interrogate the rendered html or between ¤elementname  
>and \n\n to extract the contents.
>
> For many users this would be a compelling use of the customise pragma but 
> they would not need to define such customise parameters at all.
>
>
> Regards
> Tony
>
> On Tuesday, 6 October 2020 02:58:47 UTC+11, PMario wrote:
>>
>> On Monday, October 5, 2020 at 2:54:08 PM UTC+2, TonyM wrote:
>>
>> This makes me ask if one of out special characters could simply default 
>>> to the element that follows the special character
>>>
>>> eg
>>> 'aside Content is an aside
>>>
>>>
>>>- That is nominate one of the special character to just 
>>>automatically treat what follows as this does \customise tick=aside 
>>>_element=aside
>>>
>>> This would be possible if we would check against an HTML list of 
>> "names". which is already done, eg: _element="article" will have a look at: 
>> https://github.com/Jermolene/TiddlyWiki5/blob/9716c326952c16f63345a135e73cf36670dca0d8/core/modules/config.js#L37
>>
>> But we would probably need to update this list, since "Details" isn't 
>> listed there. 
>>  
>>
>>>
>>>- So in fact we do not need to define any \customise 
>>>tick=elementname _element=elementname
>>>
>>> We do for "names" that are not html tags.
>>  
>>
>>>
>>>- This should be achievable programaticaly so any element name can 
>>>be used including arbitrary html elements.
>>>
>>> including "arbitrary" tags is not possible, since this would limit the 
>> names to html elements only. .. That's not what we want. 
>>
>> -mario 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/d3024a89-c6f1-4ad6-a5af-904a787789dfo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

TonyM wrote:
>
>
> I simply can't get over the power this adds to tiddlywiki. 
>

RIGHT! And Right! *But with power comes responsibility.* That is a cliche. 
But documenting the new approach I think we need to help PMario. Especially 
with examples.

TonyM previously wrote: 

> I have returned to research after a short break, and realise it is not as 
> intuitive when you come back to, it but I am getting there.


RIGHT! See my comments at:  
https://groups.google.com/d/msg/tiddlywikidev/JKp9Zp4hvGE/KRj5Di3SBgAJ

And PMario's reply at: 
https://groups.google.com/d/msg/tiddlywikidev/JKp9Zp4hvGE/Tjd9crgpBwAJ

FWIW, I believe that what PMario has done steers a very NEAT course between 
"so open no one will master it" AND "it needs a bit of work to understand 
IF you are doing more complex layouts."

My tuppence
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/768ca2d9-5d3f-4c54-b7b6-287b9c82d03bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Should "Space, Space, Enter" be in Custom Markup too?*
 

> @TiddlyTweeter wrote:
>>
>> For readers on email in my last post prefaced *Regarding examples & 
>> WikiText "interactivity" *I deleted the last paragraph as it was 
>> misleading.
>> TT
>>
>
> PMario wrote: 

> I think it was the one with the space-space-enter, that produces a hard 
> linebreak. .. That's an effect that comes from the second plugin. 
> https://wikilabs.github.io/editions/custom-markup/#%24%3A%2Fplugins%2Fwikilabs%2Fspace-space-newline
>

AH! Got it!

Would it not be good simply to also include that in the Custom Markup 
plugin? 

Or do you think it would be confusing? 

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/db3a20c1-40aa-49fc-8a08-9d5c9b874a0bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

TonyM wrote:
>
>
> I simply can't get over the power this adds to tiddlywiki. 
>

RIGHT! And Right! *But with power comes responsibility.* That is a cliche. 
But documenting the new approach I think we need to help PMario. Especially 
with examples.

TonyM previously wrote: 

> I have returned to research after a short break, and realise it is not as 
> intuitive when you come back to, it but I am getting there.


RIGHT! See my comments at:  
https://groups.google.com/d/msg/tiddlywikidev/JKp9Zp4hvGE/KRj5Di3SBgAJ

And PMario's reply at: 
https://groups.google.com/d/msg/tiddlywikidev/JKp9Zp4hvGE/Tjd9crgpBwAJ

FWIW, I believe that what PMario has done steers a very NEAT course between 
"so open no one will master it" AND "it needs a bit of work to understand 
IF you are doing more complex layouts."

My tuppence
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5f911353-acfc-4050-808e-79bef39e179co%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Revision Suggestions For "exports.htmlBlockElements"*

Ciao PMario & TonyM

TonyM wrote:
>
>
> This makes me ask if one of out special characters could simply default to 
>> the element that follows the special character
>>
>> eg
>> 'aside Content is an aside
>>
>  

> This would be possible if we would check against an HTML list of "names". 
> which is already done, eg: _element="article" will have a look at: 
> https://github.com/Jermolene/TiddlyWiki5/blob/9716c326952c16f63345a135e73cf36670dca0d8/core/modules/config.js#L37
>
> But we would probably need to update this list, since "Details" isn't 
> listed there. 
>

Right! And thanks, Mario, for posting that link!

IMO in addition to  *Details* that list should include the "semantic HTML" 
tag for *Nav.*

It also lacks *Main*. But I don't think it needs adding as you'd only ever 
use it ONCE, so no need for Custom Markup activation on that one.

Yes?

Best wishes
TT

 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/16170cc2-bee1-4a90-960a-9881c188ba80o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)


>
> PMario
> I was thinking about °/ some text and /°  ... Since start and end are 
> different, it should be possible to identify nesting. So 
> ›/ and /› .. may be a second option and ´/ and /´  a 3rd one. 
>
> I would like to keep °° some text °°
>

Well you are the developer :-).

TBH I don't like having TWO characters before and after. Following the 
parser you already launched would this be possible?? ... These are 
suggested defaults ...

(NOTE in the examples I am simply using degree, and single AS IF. I don't 
care if its another character ultimately.) 

*Mode 1 - Match the "word", close at space (any "\s") so ...*

This is an °example of usage.Just an example.

renders as ...

This is an example of usage. Just an example.

You add ONE character. Well good.

*Mode 2 - Match to "end-string" (pair is  › ... ‹)*

This is an › example of usage‹.Just an example.

renders as ...

This is an  example of usage.Just an example.

You add TWO characters.

Just ideas. The main thing being to have as minimal markup as possible, I 
think?

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3246c327-9cfb-410d-8587-2a96b6671820o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

TT .. 

> I have two other simpler suggestions ...
>>
>> 1 - only have ONE character not two ... using @@ or °° is nowhere near as 
>> readable as @ ° alone. *Markup in-line should be the most readable and 
>> the most minimal *because that is where reading happens most.
>>
>
PMario ... 

> That's right. If we find the right "start" and "end" markers we could do 1 
> character as a marker. ... But 1 ° char seems to be valid plain text for 
> me. eg: 20°C ... should not start something special. ... 20 °C ... the ID 
> would be ° (degree) and the symbol would be "C". .. But that's probably not 
> intended. .. 
>

Right. Degree is used by mathematicians, for navigation, for temperatures 
etc ... So one needs an alternative ID :-) for users who use it a lot & 
where an occasional *"°"* won't be enough :-). 

Wher as °°C.class.class:param is a possible marker, that the parser can 
> identify. Especially if the inline mode starts a the beginning of the line. 
>
> °C will clash with the existing parser
>

Right. My concern here is a broader issue. 

Do you think its a good idea to use the same ID characters for inline as 
occur for block (i.e. single charter at line start) mode?

Would it not be better they were totally different?

Thoughts
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/26be8e0a-cd4e-45fd-854f-612f8ac8ca91o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

--- Largely OT 
 

> PMario ...
>
 

> The middle dot is very similar to the "Mediopunkt" in German "Leichte 
> Sprache" rule-set. So we can't really use it. "Leichte Sprache" and 
> "Einfache Sprache" are a "big thing" at the moment.  
>

Ha! I had a quick look at https://en.wikipedia.org/wiki/Leichte_Sprache. 
Most interesting.

TT 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/c326f456-f4f1-49e2-8e8b-01e6a4bc55a3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)


*Discussing putative inline IDs *

> @TiddlyTweeter wrote:
>  
>
>> 2 - ADD a second ID, maybe aimed at paired use by default?
>>
>  
>
PMario .. 

> Not sure, what you mean here.
>

I was suggesting tentatively that there be two ID's for inline markup ...

degree "°" (entity = °)


and another ... (I can help you find one :-) maybe ...

middle dot "·" (entity = ·)


I'll explain in a later post why I think 2 IDs may be a good idea. 

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/1477abaf-5f4a-4e98-8df6-ead30ec52f52o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

For readers on email in my last post prefaced *Regarding examples & 
WikiText "interactivity" *I deleted the last paragraph as it was misleading.
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/b0f5252b-9bd1-4f27-9f67-0af35603f715o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Regarding examples & WikiText "interactivity"*

TT wrote:
>
>
>> These can variously interact under nesting. They can also change existing 
>> WikiText behaviors on line-spacing (when its nested inside some custom 
>> constructs) in a way that can be confusing at first.  Now I understand it 
>> much better. When you understand how it works its ROBUST and you can do 
>> pretty amazing things very elegantly & efficiently.
>>
>
> Yea, there is still some problems, with the TW core parser, that 
> introduces P tags, where they shouldn't be. .. I think there is no real way 
> to work around this. :/
>  
>
>> My point? I think we need to try help PMario document it. 
>>
>
> PMario 

> That's a good idea. Especially documented examples will be helpful. ... 
>

Hopefully I can give you one or two in time.

> In particular we currently lack a brief summary that indicates the 
>> "interactivity" that totally confused me at first.
>>
>
> What do you mean by "interactivity"
>

I mean only what can happen, especially under nesting, with WikiText & 
Custom Markup.

I think the bigger point I was trying to get at is that Custom Markup makes 
much, much easier vastly more sophisticated use of HTML & CSS using a neat 
compact method.
Along with that comes, I think, much higher chances users will trigger 
cases where the layout seems to go all wrong :-). 
So greater clarity of how parsing works is likely going to be needed if a 
user wants to do more advanced work.

A simple example is the current behaviour of adding two spaces at the end 
of a line with some WikiText.
I only just realised that two spaces at the end of a line inserts a * **I 
never grasped that before!*
SO, I think that some aspects of existing WikiText might also need a bit of 
clearer documentation?
Yes?

TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/914cd487-c8f3-419a-8a57-18258a7c9322o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Users on email please note that in my last post prefaced *Regarding a use 
case using "shorthand" *I added a PS at the end reading ...

PS. There is a side-effect too that is very good for me. Generated content 
CSS can't be copied via select on screen. Since these lessons are very 
costly to make I don't want users (or competitors) whom I don't work with 
to be able to easily copy my work. Read fine. Copy or print, no. You have 
to pay for that. CSS lets me make stealing lessons difficult without 
requiring any server involvement.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/5af953f6-c584-4fda-bc0f-3ccc73123e01o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Regarding a use case using "shorthand"

PMario wrote:
>
>
> The point is, I'm completely clueless, why you write "content" with CSS? 
> What is the purpose? Or is it just testing out the possibilities?
>

Its a good question to ask. It forces me to be explicit about it. Yeah, it 
seems very bizarre at first. But its addressing a very specific use case. 

For over a decade I have made manual SHORTHAND for lesson instructions for 
bodywork. An example hand-written (on paper) shorthand for the start of a 
lesson ...

Pb Ob Pbk Crl o ll at k // A1 Abk 1 L 2 R

These are instructions in a class I give voice to like this ...

Lay down on your back. Observe how you lay on the ground  bend your knees. Cross your right leg over your left ... 
etc

A whole lesson is written on ONE A6 card. 
Transcribed a lesson would be 4-6 pages of A4.

I now want to put online some of these lessons (demand from students). 
Since *hundreds of phrases are repeated i*n different lessons I want to 
avoid having to write those for each lesson. That is the background. Hope 
that makes clearer the issue!

I have done some experiments already in TW using transclusion (each 
sub-phrase a tiddler). It works, but (1) the styling (I need to hide/show 
parts of lessons) gets very complicated to manage; (2) its a barely 
readable forest of *{{...}}.*

NOW I'm experimenting with your Custom Markup and the results so far look 
very good. In fact it looks like I might be able to use a slightly modified 
version my existing shorthand system (mixed with typed text). So, for 
example ...

°Pb.-pos °Ob °.pbk IC.rl °.o °.ll It is important at  °.at °K // °.a-1 
°a-bk Rest, then °.L2r 

YES, its an experiment. But a well advanced one that looks very hopeful. 
Once setup it seems very effective!

I think its an interesting use case of efficient utilization of CSS. 

I may actually use it! :-)

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/f4b71668-5164-4f2b-82e1-758f938a2335o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

I was about to post a note on in-lining :-)

I'll update first. A dopo.

TT

On Sunday, 4 October 2020 14:23:33 UTC+2, PMario wrote:
>
> Hi foks,
>
> I did just upload V0.6.0 which has some INCOMPATIBLE changes. 
>
>
>- *New Functionality*
>   - $:/config/custom-markup/pragma/PageTemplate 
>   
> 
>  
>   tagged: $:/tags/Macro
>  - content: \importcustom [tag[$:/tags/pragma]]
>   - contains global pragma definitions .. and macro definitions
>- *Incompatible changes*
>   - _params renamed to -> _classes
>   - _maps renamed to -> _params !!
>   - Adjusted the docs accordingly
>- Improved debug modes
>   - \debugcustomize new parameters: no, list, global, global list, global 
>   ID
>   - _debug new parameter: no,
>- angel renamed to: angle + docs
>
> -mario
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/1e1f117e-f134-4bbc-b9b7-fa3d556dc69bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

*Regarding fonts ...*

 @TiddlyTweeter wrote:
>  
>
>> 2 - SOME NOTES ON FONT SUPPORT - PMario & I already briefly discussed 
>> this. 
>> Its not an issue on the 6 IDs, at least not for European languages. 
>>
>> But it *is an issue if you want to use Unicode characters in \customize 
>> pragma*.
>>
>  

>
>> My point for TW? I'm wondering IF, we could assemble a *custom font *of 
>> say 100 Unicode *typographic *signs (e.g. punctuation marks, markup 
>> symbols, reference signs etc)  and *EMBED* this in a TW?
>>
>
>
PMario ... 

> I'm not the biggest fan of embedded fonts, because of size. ... BUT it 
> will be possible with a second plugin, so users can decide.
>

I agree for complete fonts. I should look at *how big a font of, say, 100 
characters is?*



I personally would install the font. 
>

On computer? Yes. But I'm just wondering if a more TW-centric approach 
would be viable too? (i.e. the embed route, IF font of limited character 
set is small enough?)
 

>  
>
>> Q: Is it possible? Your thoughts?
>>
>  

> I would even consider to create a browser AddOn, that will make the font 
> available for TWs, if users don't want to install new system fonts. 
> I'm not sure if this is possible, but it would be worth a test. 
>

That's encouraging! I had thought it would be very difficult.  

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/691478a9-fcca-40bd-8ddb-726554480aceo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread @TiddlyTweeter

PMario wrote:
>
>
> Yea, there is still some problems, with the TW core parser, that 
> introduces P tags, where they shouldn't be. .. I think there is no real way 
> to work around this. :/
>

Right. I noticed that. I also noticed you can suppress that behavior. 
Though I haven't quite pinned down how and where you can. But, for 
instance, if you start a tiddler ** you get ...




But if you start it *»article* you get ...




Just a comment.

TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/83cc061e-8282-41e0-b695-e3a5cab0d4e3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread @TiddlyTweeter

PMario ...
 

>  I'll publish V0.6.0 with some incompatible changes on Sunday. ... We will 
> get global pragma rules, _parms -> _classes,  _maps -> _params ... angel -> 
> angle ;)


Noted! Global pragma rules will be brilliant for my use case. Thanks angel 
for the angle :-).

TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/a2948582-7cc7-4bbd-9ea6-b68f32be29c2o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

PMario wrote:
>
> Interesting, but without the actual configuration it's really hard for me 
> to see, what it should do. 

.. Can you export your setting and attach a tiddlers.json, so I can see it?

Its actually very complex so I've made a simplified single tiddler example 
containing the \customize, markup example and style block for you to see.
I hope that will help.The example attached is for using the markup in BLOCK 
mode I already have working well. 

In a post later today I'll try to make clearer the issues in INLINE mode I 
was trying to explain.

Many thanks for your patience!

TT 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/576757a5-e0c3-4c73-b754-e41fcdda68cfo%40googlegroups.com.

TT-block-version-test.json
Description: application/json

[twdev] Re: Custom markup (continued 3)

Ciao PMario

*Comments on INLINE markup.*

At the moment I'm writing markup like this ...

»§
›¶ `›¶` Example single line for SA phrase groups. Won't fully work till
custom-inline is finished. ([[TT Notes]])
»¶
°O `»¶ ... ⁋` Example mutli-line block for SA phrase groups.
°O Good morning. Welcome to another
›ABsa
°O ... So, let's start ...
⁋
»¶
°P.p-b-v
°O Observe how your body lays on the ground. What touches clearly. What
doesn't.
⁋
»¶

°A.p-b-v
°O Observe how your body lays on the ground etc ...
°O
⁋
§«

each ° inserts a into a paragraph (»¶ ... ⁋). I'm doing it this way
because at the moment to do it inline would make it (1) FAR LESS READABLE
see below ...
and I also want to insert (2) NON-SPAN inline elements easily like ›ABsa and
(3) sometimes NEST elements.

»¶ °°.p-b-v°° °°.o-ktl°° Now, observe how your body lays on the ground,
particularly °°.p-d.g-l°° In this °°AB.sa°° movements are based on
"°°REF.r-jen.v°°143-9".

You mentioned before that the current inline parser need uses matched
pairs.
But *the pairs are identical *so inline NESTING becomes impossible.

I had a thought (horror!) :-) In block parser for Custom Markup you
basically leverage off LINE SPACING.

I'm wondering IF the use of SPACE INLINE use could work give the leverage
needed (regex °\S* ). IF so MY case above would become ...

»¶ °.p-b-v °.o-ktl Now, observe how your body lays on the ground,
particularly °.p-d.g-l In this °AB.sa movements are based on
"°REF.r-jen.v 143-9".

... Now you gonna say that would ONLY match words ... so for anything other
than a word (string of chars that are not spaces) you use a closure.
Let's pretend ... its /°

»¶ °.p-b-v °.o-ktl Now, observe how your °.o-h body lays on the
ground/°, particularly °.p-d.g-l In this °AB.sa movements are based on
"°REF.r-jen.v
143-9/°".

Hope this is clear! I'm wondering if this approach is possible??

I have two other simpler suggestions ...

1 - only have ONE character not two ... using @@ or °° is nowhere near as
readable as @ ° alone. *Markup in-line should be the most readable and the
most minimal *because that is where reading happens most.
2 - ADD a second ID, maybe aimed at paired use by default?

Very best wishes.
TT

--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/cd7d49ab-1ef6-41b5-915d-cd03f1f5e52fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao PMario

*Is Six ID's Enough? YES.*

In practical use I think its a good number.

- Good balance between strict TECHNICAL NEED to make it work (i.e. 2) and ..
- ... VISUAL VARIANCE to make typing variant markup a good experience.

In my tests I used all 6. 2 extensively. 2 moderately. 2 for special cases.
That number is well supporting of even complex markup.

I would cap it at 6. More, I think, would be visually redundant.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/29060e65-7ff1-46e7-9ec3-fc44a96b839do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao PMario

*A CONFESSION -* Using Custom Markup at first was very confusing for me!
As soon as I started to do anything other than simple the layout would
break.
*This is because of Custom Markup's richness. Because it can do a lot a lot
of different ways.*

There are several dimensions which behave differently according to ID or
\customize settings ... In my own way of thinking you have ...

*Scope Match of three types* (expressed in pseudo-regex) ...

1. ^ID ... \n (for 4 IDs)
2. ^ID ... \n\n (for 2 IDs)
3. ^_endString (overrides default scope 1 & 2 in \customize)

*\customize Flow Setting of two types*

1. _mode="inline" (default)
2. _mode="block"

These can variously interact under nesting. They can also change existing
WikiText behaviors on line-spacing (when its nested inside some custom
constructs) in a way that can be confusing at first. Now I understand it
much better. When you understand how it works its ROBUST and you can do
pretty amazing things very elegantly & efficiently.

My point? I think we need to try help PMario document it.
In particular we currently lack a brief summary that indicates the
"interactivity" that totally confused me at first.

Best wishes
TT

--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/223e83b5-5ec4-4756-8146-fcebf4207b11o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

Ciao PMario & all

I been doing a lot of testing of using Custom Markup for layouts and
precision CSS application. It is VERY good.

A number of issues came up. I will post about each separately. First I
comment about Editor Look & Keys, then Fonts & Unicode.

I did testing on English Win7 (DT), Italian Win10 (tablet) & Android6
(standard phone) computers.

*1 - EDITOR LOOK & SETUP*

*Key Availability *- It became clear quickly that whilst all three system
tested on have Font Support they all differ in native Keyboard Support.
*None has all 6 IDs available easily on keys.*
This just confirms what we said before: *the tool requires buttons,
keyboard shortcuts and likely (for boilerplate WikiText) stamp tool use.*

The approach PMario took to deal with this via buttons & key shortcuts
works well...
but ...

*Too Many Buttons? - **I think there may be too many buttons :-). *For
instance are the buttons that just *remove *an ID needed at all?
What is primary is to be able to insert IDs, which it does.
But I don't see added value (myself) to remove them where a single "delete"
stroke does it anyway!

*Button Pictures - *This is ONLY an aesthetics comment; but why not just
have a *picture of the single ID* on a button and no more?
Visually I think they are over-noisy.

2 - SOME NOTES ON FONT SUPPORT - PMario & I already briefly discussed this.
Its not an issue on the 6 IDs, at least not for European languages.

But it *is an issue if you want to use Unicode characters in \customize
pragma*.

I tried to pin down some RELIABLE (typographic) characters available
through Unicode (i.e. that have "universal" font support).
This is not an easy thing to do. Font substitution behavior of OS' systems
(a pretty amazing process BTW) that create "composite" fonts on the fly,
using available fonts on the computer can make it near impossible to
predict (1) glyphs that will appear in other people's TW; (2) what they
will look like (e.g. sometimes coloured, sometimes not, sometimes visually
very different).

This is obviously NOT directly a TW issue. But it made me wonder whether in
fact we (the whole internet) are seriously under-using Unicode that would
make life much easier---and not just to better support Custom Markup.

My point for TW? I'm wondering IF, we could assemble a *custom font *of say
100 Unicode *typographic *signs (e.g. punctuation marks, markup symbols,
reference signs etc) and *EMBED* this in a TW? I don't know how you'd
embed it or access the font. But I know how to make such a font set.

Q: Is it possible? Your thoughts?

Best wishes
TT

--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/64c9e825-5ac7-4bb2-88a9-4ac5ed85b193o%40googlegroups.com.

[twdev] Re: Writing Forms (not HTML forms, ways of writing)

Right.

The very freedom has slashed the throat of slow evolution. Visual design 
potentials got over DIVORCED from meaning.

So we have exciting visuals, for what?

I do think its interesting to look back to perfectly viable systems where 
the pen had to handle both content AND form simultaneously.

Best wishes
TT

On Saturday, 26 September 2020 21:24:15 UTC+2, PMario wrote:
>
> Hi,
>
> That's a very interesting topic. Printing books has been developed and 
> improved since about 500 years. .. HTML and the internet was able to 
> "destroy" it in 20 years. .. In the last may be 10 years the standardizing 
> groups try to implement elements from "printed media" into "web media"
>
> We got new HTML/CSS elements like flexbox, grid, masking and others, that 
> allow us to improve and control the layout of a web page. ... BUT we are 
> still miles away from printing a good looking page, directly from the 
> browser. 
>
> We need to convert HTML to TeX with 3rd party tools, to be able to get a 
> good looking printed page, that we can read with joy as a PDF. .. No trees 
> need to die ;)
>
> -mario
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/0dc571dc-6c43-4b5f-ba38-efabf0fd853do%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

PMario and all

I been thinking about all this. Especially markup symbols.

Looking back at Gruber 2004. At that time you were stuck visually on glyphs 
between a rock & a hard place.

We are no longer so constrained. 

MY POINT? Let us ensure we are VISUALLY free on markup symbols, not get 
stuck in 2004 code pages :-).

A thought
TT

On Saturday, 26 September 2020 13:57:05 UTC+2, PMario wrote:
>
> On Saturday, September 26, 2020 at 1:33:40 PM UTC+2, @TiddlyTweeter wrote:
>
> Quick point. In my USE CASE I'm interested in using CSS classes AS the 
>> "code" /.  shorthand (actual end-user text is inserted via CSS *::before 
>> *) . The user would see NO comprehensible text at all if they opened a 
>> Tiddler in edit mode ... They would see stuff like this ...
>>
>> °.x-4x
>> °A.standard-back
>>
>> etc ...
>>
>
> OK. ... That's interesting. 
>  
>
>> My point in my OP was to open-up what "readable" means. My "shorthand" is 
>> totally readable to me. It produces (in render) ...
>>
>> On all fours. First attend your back. Can you form a mental image of 
>> where it is in space?
>>
>> I don't think that approach is like Gruber Markdown at all. But the 
>> concepts Gruber initiated have had enormous shaping influence on how we 
>> think about markup. Especially in wikis.
>>
>
> It's true, readability is different for every user. ... My intention is, 
> to allow "styling" markup like .x-4x directly after the ID like: °.x-4x  
> but if the user chooses to make the wikitext more "verbose" they can move 
> the "cryptic" elements into the _params parameter and define a wikitext 
> like so: °this-and-that-should-happen ... 
>
> For me it's important that both variants work. 
>
> So when PMario talks about "readability" I want to push it :-) I think 
>> what he means is text in *"Gruber mode"*. I.e. part of normal language 
>> use with markup symbols that compliment that.
>>
>
> That's right, as written above.
>  
>
>> But PMario's tool actually opens up totally what "readability" could be. 
>> When you start thinking this through it gets liberating.
>>
>
> Yes. That's the intention. 
>  
>
>> TBH Tony, I don't think it is a programming syntax per se (in my use case 
>> it is just standard CSS, there is NO programmatic logic. Its simple text 
>> SUBSTITUTION).
>>
>  
>
>> The easiest was I could describe it is "*Private Shorthand Supporting 
>> Public Messaging*".
>>
>
> That's 1 usecase and it has been the initial one :)
>  
>
>> It is provision of an efficient method for supporting AUTHOR writing 
>> methods. Full stop.
>>
>
> yes .. over and out (for this post) q;-)
>
> -mario
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/d5e41e23-47e8-4b40-bd47-6811739d3116o%40googlegroups.com.

[twdev] Writing Forms (not HTML forms, ways of writing)

Lot of the time here we deal in housekeeping -- developing necessary code 
work to be able to write what we want as we want it.

Yet we seem bad at exposing what it is for. End products.

I am very interested in writing forms. Modernist writing style for instance 
(already 100+ years old); playing with writing cliches.

An instance: We take for granted the paragraph. In Medieval England a lot 
of (of course) hand-written paragraphs started with red text to indicate 
break in thought--it was both marker of new physical scope (now paragraph) 
AND meaning substance summary (now H1 etc). There was NO concept of line 
breaks visually. It was a valid form that worked well.

I wonder IF anyone reading here is interested in exploring writing forms? 
TW in this a means to an end. A good one. But results nothing to do with it 
directly (i.e. reader does not need to know).

Dimmi (tell me)
Best wishes
TT


-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/a1324705-b460-491f-89d3-fe14ba07a0d0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)

PMario & Friends

The implications of The Tool are freeing, whilst also complex and diverse.

IN PARTICULAR the easier use of CSS could lead to what PMario identified as 
a potential TOWER OF BABEL.

In my own case I recognize the need for a decent way of thinking CSS class 
naming through (there will be about 300 classes for my use case I think).
I will likely implement a crude framework using Telmiger's Bricks tool to 
do so.

My point? The IMPLICATIONS of The Tool are large. There will arise need, I 
think, to clarify how deal with that ENLARGED FREEDOM effectively.

Best wishes
TT

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/43244ea9-f73b-4811-8996-b7cf113c01e8o%40googlegroups.com.

[twdev] Re: Custom markup (continued 3)