Mario, *A few observations.* Again please don't be overwhelmed just consider these ideas please. Nor do these ideas imply it demands your work, although in some cases that is most likely.
The key issue I am grappling with is the systemisation of glyphs, symbols and the scope of customises wiki text. To make this easy to use and remember. Presently I always need to lookup the reference material and slowly construct wikitext, if its slow and hard for me (involved in this project from the start) it may appear impossible to future new users. There are differences in the way Mario, TT and myself envision this, until this is cleared up even testing will be clumsy apart from helping future users. Observed - In a tiddlywiki without custom mark-up This is some Text __.test Inline text ___ with more fails gracefully ;This is some Text __.test Inline text _/ with more Fails *un*gracefully. Disrupts future wiki text. *Question* Example the details in https://wikilabs.github.io/editions/custom-markup/#Customize%20the%20Details%20Element In this example I use a custom endString basically /symbol \customize tick="d" _element="details" _classes= ".notop.cbox.cbox-primary.hard-linebreaks" _endString="/d" _mode=block \customize tick="s" _element="summary" _classes=".margin-init" _endString= "/s" ´d ´s Details - Summary /s line 1 line 2 /d ´d ´s Details - Summary /s line 1 line 2 /d Is there any reason why we could not make this a default end string, ie the "/symbol" automatically. unless specified for such blocks. Then allow the end string to be set to a logical "\n" or "\n\n" for the automatic closure at end of line or end of double line break/paragraph. Also can you explain or document a little "the use of this nesting" ? ´d ´s as I understand it ´s follows ´d and a <space> so it looks inline, but I assume it is not, can we say "*customise blocks can be nested by following one with another on the same line, but only at the beginning of the line **or at the beginning of subsequent lines"* Just to get a more general statement? I love the demo wow ﹙symbol.class:param some text﹚ nice There is also a superscript and subscript form of these (Not the same as each other ﹙﹚₍₎⁽⁾ ⁽this is some text⁾ ₍this is more text₎ To me these are two use full pairs to use glyphs for inline content. - Obvious but subtle - Open and close are single characters - Would just look like a textural mark up without custom wiki text plugin. - Provides two/tree pairs for different applications The use of the Greek delta to represent change may be useful at some point as a glyph. *Question - See diacritical markers <https://www.w3schools.com/html/html_entities.asp>* - Could we have any clashes with these? *Question - customised Glyphs, a glyph too far?* - As you can see the wide range of glyphs available that have meaning or structure makes me wish to ask if we could allow the user to nominate glyphs either single (line/para/blocks) or pairs for inline or block. ie customise the customise glyphs. - This would mean we only choose a few and let the user define extended glyphs (only if they want to take the red pill), this could reduce some missuses if people must add more to get more complex - The EditorToolbar buttons would then apply a currently selected glyph or can be cloned to create a new set of buttons for another glyph/or pair. - Using either the actual glyphs for the button or an svg version (below) - I realise this level of customisation may be problematic but it will solve other problems like forcing us to choose glyphs. I only ask because of its desirability, but have know Idea if coding wizardry permits, even if a reload is necessary. <svg height="26px" width="24px"> <text x="0" y="24">⁽ ⁾</text> </svg> <svg height="26px" width="24px"> <text x="0" y="22">₍ ₎</text> </svg> Note 'y="22"' here, lest it be "trimmed" at the bottom. *So to my thinking about glyphs * This is done without a detailed response to existing uses and I stand to be corrected, they are suggestions only, more to share the organising principal than the specific glyphs. In this case the glyphs differ by their default scope ie where they terminate *Pre-prevision two inline braces glyphs* - ⁽ ⁾ superscript additional braces open and close defined - ₍ ₎ subscript additional braces *Pre-provision beginning of line glyphs* - › suggests, one end of line (eol) which is terminated with "\n" by default - A single line glyph like * and # - » suggests, two eol, which is terminated with "\n\n" by default - A paragraph responsive Glyph - An alternative or additional paragraph responsive glyph "¶ pilcrow sign" is still in my view a valuable one and could be used with ⁋ REVERSED PILCROW SIGN to wrap a block and force a paragraph element. - ´ tick like "›" but ´ suggests special mark-up follows, which is terminated with "\n" by default, or /symbol if symbol is used (an no alternative given) ie if symbol is used can be used as a block, only terminating on /symbol - Useful with html and widget matching symbols eg ´div.classname some text or lines /div (if necessary we could use ⁄ instead of / - ° which is terminated with "\n" by default - but can be terminated prematurely with /° (or °/ allowing one to just use the content before /° as the src in the custom, leaving the rest of the line to be wikified as normal. Main glyph used for parameter passing - The use of ° then °/ implies the use of /° content °/ where the ° operates inline, perhaps to support this we allow / to proceed a glyph without altering it - eg °trans:p1 tiddlertotransclude °/ Futher wiki text /° the / is ignored here but does allow a glyph to proceed it to be used as it it was the first character on the line °/ But given this then /´ may imply ´/ may be used to prematurely close tick. (suggested as \n by default as a line based glyph) *Pre-provision block focused glyphs* - ≈ Suggests multiple lines, and expects closure, perhaps /≈ by default? ie /glyph, rather than /symbol - ≋ Or similar could be used to represent larger blocks, and expects closure, perhaps /≋ by default? ie /glyph, rather than /symbol *On entering the glyphs in wikitext* - Perhaps a special toolbar button with short cut eg: alt-insert N (then a OL list) N were hitting a number key will insert that glyph (in a fixed order) - no other special handling like your current solution. - No space or otherwise, this is the users responsibility, including closure. - At least the glyphs will always be at hand with a simple set of keys - An additional button and short cue eg ctrl-insert for a user selected list of "symbols" could be provided that could be used to access any symbol for customise and other applications. - The current solution could be changed to be used only for "canned" and prepared customise strings. *Fullwidth characters* - There is a set of uni-code characters called fullwidth <https://www.compart.com/en/unicode/search?q=fullwidth#characters> - Tilde curly braces, square and parentheses and bar, including broken bar, punctuation and alpha-numerics that are all unique and separate characters. - I am confidence tiddlywiki supports this, but the worst case is customise comes with a raw tiddler loading an appropriate font. - "ｌ" list is an example lowercase l *A random Idea* - I used to use a character combination to annotate lines on personal hand written notes, I have found unicode versions, they always live at the end of a line - ? a question (A question) Special forms of these also exist. - ! an answer (asserted / definitive answer) - ⁇ Question this, it is unlikely to be true - ⁈ You must question this, question - asserted - ⁉ Believe it to be true - asserted but could question - So I wonder like your prior work on <space><spaces>\n if we could introduce a end of line type of custom pragma. ie it has no beginning of line, or inline or block characteristics (by default) - In a sense inline but only end of line (\n). Used inside ⁉ means nothing. - This also means it would typically not have any input (other than symbol, class or :p) unless it detected \n vs \n\n *Perhaps another random and radical idea?* - As you may know there are special spaces such as U+FEFF <http://jkorpela.fi/chars/spaces.html> ZERO WIDTH NO-BREAK SPACE <http://jkorpela.fi/chars/spaces.html> - These is used as glyphs will be invisible both in the editor and rendered output with or without the customise plugin. - Suggests interesting possibilities and if not using "customise plugin". symbols or .classname or :parameter will be invisible anywhere. Makes for highly transferable text. Ie no impact when copied and exported elsewhere. - Arguably we could do something to make them appear visible only in the tiddlywiki editor. eg a font character remap. In closing; - In truth once again I am straying into further extensions of possibilities in these notes. - However it seems to me this is a valuable "look ahead" in an attempt to inform the current project to achieve the best outcome. - If we are using Extended Unicode as our glyphs, and possibly symbols, this does suggest we need to be well informed in Unicode, hence my explorations here. - Extended Unicode do need a font that will represent them, however it seems most are covered already with default fonts, and if it were necessary adding a full back font is trivial, to include with customise. - I do declare as per posts elsewhere, what I am learning from this exploration of Unicode has very interesting design implications as raised here <https://groups.google.com/forum/?oldui=1#!topic/tiddlywiki/OElkElXfG7Y>. The use of additional character sets within tiddlywiki as it stands, without customise or special fonts provides a whole set of namespaces. This has implications for the designer especially if they limit the use of these characters to their own code and tiddler titles. and example is the word *description* is an existing field but the word *description* in another character set could be the name of a tiddler that defines the description field and how to view or edit it. - In many ways these lessons make sense to raise within this project because it is all about glyphs and symbols, which are critical to the success of the customise wiki text solution. - My experiments so far suggest making use of extended Unicode is already effective and operational in tiddlywiki by virtue of its standards based implementation. Regards Tony On Wednesday, 28 October 2020 04:04:13 UTC+11, PMario wrote: > > Hi, > > V 0.7.0 - 2020-10-23 > > - New Inline functions > - _symbol.class.clsss:param:param some text__ > - .class and :param work the same way as "block" definitions > - Removed underscore from "block" definitions, because it's used by > "inline" > - Added: \\ pragma comments > - It's faster than HTML comments <!-- comments -->, since it can be > used outside macro \define x() blocks > > > > *NO \customize inline functions yet. * > > Have a closer look at the tiddler code: > https://wikilabs.github.io/editions/custom-markup/#tick-inline-simple > > > As you can see in the code below there are 4 possibilities atm. I intend > to reduce them to 2 if possible! > > a) > - start: 2 underscores: __ > - end: 3 underscores or 1 underscore slash : ___ or _/ > > b) > - start: /° > - end: °/ > > c) > - start: ⠒ > - end: ⠶ > > d) > - start: ﹙ > - end: ﹚ > > a,b,c are nestable if using them again. > > d) is only nestable if one of the others is used. I'm not sure, if I like > this behaviour. ... > > -mario > > switch (this.match[1]) { > case "__": > reEnd = /___|_\//g > break; > case "/°": > reEnd = /°\//g > break; > case "⠒": > reEnd = /⠶/g > break; > case "﹙": > reEnd = /﹚/g > break; > } > -- 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/6e6fed4f-b407-4541-a915-e9c22d98710do%40googlegroups.com.
