Mario,
I understand your concern in relationship to Unicode. But given TiddlyWiki
has the content type;
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
And most systems have fonts for symbols, beyond the old ASCII sets I am
sure we can find safe Unicode characters. TT may be the best to provide
guidance here.
- The dream would be keyboard enterable "glyphs" or mark-up. Way back
when this started I actually expected custom mark-up to be only triggered
by a leading period "." (first non blank character is "."), in effect an
escape character approach.
- Of course now we have gone a long way past that and uncovered many
more possibilities.
- A Unicode character is less likely to be found in imported text in the
exact way we use it as an "escape" character.
- As long as we can turn off and alter the escape character used, we can
adapt if the text contains our escape character
- And since we need to rule in customised wiki text we are somewhat
safe here.
I am happy with the block approach first, it is already very powerful. Thus
you could use the same principal, only if the escape character or glyph is
the first non-space character (perhaps permit tabs etc..)
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.
Regards
Tony
On Tuesday, 24 November 2020 at 00:27:12 UTC+11 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/732c3bf5-0d9d-4309-882f-a28dcc81bcb7n%40googlegroups.com.
