[twdev] Re: Custom markup (continued 3)

2020-10-28 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-28 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-27 Thread TonyM
Mario, This is a nice resource. I note the special page Mirrored characters https://www.compart.com/en/unicode/mirrored But in this set I cant see the Maths alphanumerics https://www.unicode.org/charts/PDF/U1D400.pdf Tones On Tuesday, 27 October 2020 00:37:08 UTC+11, PMario wrote: > > On

[twdev] Re: Custom markup (continued 3)

2020-10-27 Thread PMario
Hi folks, Please continue discussions here: Custom markup (continued 4) -m -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving

[twdev] Re: Custom markup (continued 3)

2020-10-27 Thread PMario
On Tuesday, October 27, 2020 at 6:19:56 AM UTC+1, TonyM wrote: ... > ﹙symbol.class:param some text﹚ > > Where if you use ﹙ as the glyph, the end string is "﹚" for inline. The > symbol remains free for other configurations > > A specially formatted quote ﹙q.large some text﹚ in line ﹙ the default

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread TonyM
Mario, On Tuesday, 27 October 2020 00:26:49 UTC+11, PMario wrote: > > On Monday, October 26, 2020 at 2:21:44 AM UTC+1, TonyM wrote: > > so we could use ﹙ to mark inline ﹚ then continue >> >> compare with (﹙ ﹚) so we could use (﹙ to mark inline ﹚) then continue >> > > Looks interesting. But you

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread @TiddlyTweeter
> > 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

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread PMario
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

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread PMario
On Monday, October 26, 2020 at 2:21:44 AM UTC+1, TonyM wrote: so we could use ﹙ to mark inline ﹚ then continue > > compare with (﹙ ﹚) so we could use (﹙ to mark inline ﹚) then continue > Looks interesting. But you have to test like so: (﹙symbol.class:param some text﹚) or

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-26 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-25 Thread TonyM
See also Unicode discovery additional alphabets and tiddlywiki, and a keyboard Question Tony On Monday, 26 October 2020 12:21:44 UTC+11, TonyM wrote: > > Folks, > > Just sharing some Unicode exploration > > The best

[twdev] Re: Custom markup (continued 3)

2020-10-25 Thread TonyM
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 ⦅

[twdev] Re: Custom markup (continued 3)

2020-10-25 Thread TonyM
Mario, This is but an example, and yes in this simple case a macro may be the answer. But it is the idea in general and as I said us we may just want to use it for shortcuts. Remembering it is easy for me to apply classes "inline" to my signature with a custom pragma than with a macro. Sure

[twdev] Re: Custom markup (continued 3)

2020-10-25 Thread PMario
On Sunday, October 25, 2020 at 12:59:38 AM UTC+2, TonyM wrote: \customise tick=sig _element="$text" text="Anthony Muscio" > > ´sig > > But inline This is some text written by ´sig the author > > IMO it should be done "the old way" with: \define sig() Mario Pietsch <> But inline This is some

[twdev] Re: Custom markup (continued 3)

2020-10-25 Thread PMario
On Sunday, October 25, 2020 at 1:03:50 AM UTC+2, TonyM wrote: On saving https://wikilabs.github.io/editions/custom-markup/ locally and > dropping a plugin on it I get > Which plugin did you "drop". I can't recreate the problem. mario -- You received this message because you are subscribed

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread PMario
On Saturday, October 24, 2020 at 1:35:47 PM UTC+2, @TiddlyTweeter wrote: > > *Final Plea for TWO Inline markers* > I was thinking about that too, because underscore make much more problems as I thought. -m -- You received this message because you are subscribed to the Google Groups

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread TonyM
Mario, On saving https://wikilabs.github.io/editions/custom-markup/ locally and dropping a plugin on it I get Internal JavaScript Error Well, this is embarrassing. It is recommended that you restart TiddlyWiki by refreshing your browser Uncaught TypeError: Cannot read property 'configTickText'

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread TonyM
Folks, In relation to inline use with custom pragmas we have being focusing on applying styles etc to some text delineated with open and close. Keep in mind that with the wealth of things customise can do for us we may just want to use it for shortcuts \customise tick=sig _element="$text"

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread TonyM
TT, Perhaps this quick answer demonstrates what you are after? \customize tick=q _element="$macrocall" $name=display-macro _srcName= "wikitext" display="block" \customize tick=a _element="$macrocall" $name=display-macro _srcName= "wikitext" display={{!!display-answers}} \define

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread @TiddlyTweeter
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"

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread @TiddlyTweeter
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.

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread TonyM
Edited in Forum On Saturday, 24 October 2020 17:22:26 UTC+11, TonyM wrote: > > My Response [edited] > > On Saturday, 24 October 2020 13:46:22 UTC+11, PMario wrote: >> >> On Saturday, October 24, 2020 at 12:46:49 AM UTC+2, TonyM wrote: >>> >>> Mario, >>> Inline syntax defaults to a SPAN. The

[twdev] Re: Custom markup (continued 3)

2020-10-24 Thread TonyM
On Saturday, 24 October 2020 13:46:22 UTC+11, PMario wrote: > > On Saturday, October 24, 2020 at 12:46:49 AM UTC+2, TonyM wrote: >> >> Mario, >> Inline syntax defaults to a SPAN. The inline wikitext syntax doesn't >> care about linebreaks. >> > > So it can /° start in the middle of the line,

[twdev] Re: Custom markup (continued 3)

2020-10-23 Thread PMario
On Saturday, October 24, 2020 at 12:46:49 AM UTC+2, TonyM wrote: > > Mario, > > So ⠪.class:param Braille 246 and Braille 2345⠞ may be an option. >> >> > I understand open and close needs to be asymmetric to see which is which. > But the solution such as > /glyph content glyph/ - inline > or >

[twdev] Re: Custom markup (continued 3)

2020-10-23 Thread TonyM
Mario, So ⠪.class:param Braille 246 and Braille 2345⠞ may be an option. > > I understand open and close needs to be asymmetric to see which is which. But the solution such as /glyph content glyph/ - inline or glyph content /glyphline - para or block Still retains a degree of symmetry and is

[twdev] Re: Custom markup (continued 3)

2020-10-23 Thread PMario
On Friday, October 23, 2020 at 1:06:15 PM UTC+2, PMario wrote: Writing all the above text I was thinking: . . . . > > What about: *_symbol.class.class:param:param some text__ _ some more > text__* > hmmm. It doesn't work out with a "single" start char. Way to many problems with TW

[twdev] Re: Custom markup (continued 3)

2020-10-23 Thread PMario
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

[twdev] Re: Custom markup (continued 3)

2020-10-23 Thread PMario
On Friday, October 23, 2020 at 1:06:15 PM UTC+2, PMario wrote: Writing all the above text I was thinking: . . . . > > What about: *_symbol.class.class:param:param some text__ _ some more > text__* > IF: \customize inline="_" _element="u" ... is a default global definition it will do the

[twdev] Re: Custom markup (continued 3)

2020-10-23 Thread PMario
On Thursday, October 22, 2020 at 1:53:41 PM UTC+2, @TiddlyTweeter wrote: > > I'm very alive on what PMario is doing. It's very, very useful. > I did some development, but it won't be seen. .. I did use the TW test-framework, to create automated tests. That's super boring but has to be done,

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread TonyM
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

[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

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread TonyM
TT, If you create an _element using style you may be able to go someway to doing this. However you can also use any html tag and add the parameter class or style as it stands. I agree the glyphs (good name) should suggest a default function like inline block, style, etc... but then we can

[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

[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

[twdev] Re: Custom markup (continued 3)

2020-10-22 Thread TonyM
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

[twdev] Re: Custom markup (continued 3)

2020-10-06 Thread @TiddlyTweeter
*--- 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!

[twdev] Re: Custom markup (continued 3)

2020-10-06 Thread @TiddlyTweeter
*--- 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

[twdev] Re: Custom markup (continued 3)

2020-10-06 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-06 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-06 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-06 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-06 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread TonyM
Folks, I simply can't get over the power this adds to tiddlywiki. - Even just to use a symbol for a known or arbitrary html element name is immensely powerful. - Having a symbol and name simply replace a specific implementation of a widget and pre-set attributes - This

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread TonyM
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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread PMario
On Monday, October 5, 2020 at 11:05:20 AM UTC+2, @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 > I think it was the one with the space-space-enter, that

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread PMario
On Monday, October 5, 2020 at 10:03:40 AM UTC+2, @TiddlyTweeter wrote: > > *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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread PMario
Hi ´aside test asdf is already possible -- 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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread PMario
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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread PMario
On Monday, October 5, 2020 at 2:54:08 PM UTC+2, TonyM wrote: By the way I do nor think we shopuld say > > = > > Since to me the tick degree etc.. is a symbol > > This will be some docs changes only. I would be OK with this. > To me > > = > Would be better and note that name can be a single

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread TonyM
Mario, 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. As a starter I am reviewing first simple elements only eg; \customise tick=kbd _element=kbd _mode='inline' \customise tick=div _element=div \customise

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread TonyM
Sorry, To be a little clearer on my previous question answer You may use answers to display all answers at once; Otherwise 'q1 Question 1 'a1 answer 1 etc... Tony On Monday, 5 October 2020 23:54:08 UTC+11, TonyM wrote: > > Mario, > > I have returned to research after a short break, and realise

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
> > 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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
--- 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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread PMario
On Monday, October 5, 2020 at 11:34:48 AM UTC+2, @TiddlyTweeter wrote: I was suggesting tentatively that there be two ID's for inline markup ... > > degree "°" (entity = ) > > > and another ... (I can help you find one :-) maybe ... > I was thinking about °/ some text and /° ... Since start and

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
*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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
*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 >>

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-05 Thread @TiddlyTweeter
*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*.

[twdev] Re: Custom markup (continued 3)

2020-10-05 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

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread TonyM
Mario, Thanks for the progress and listening. Today is a public holiday and I am spending time with my partner, so may not feedback today. This project certainly has "energised me" both for its outcomes and what I perceive to be other key improvements we need in TiddlyWiki. It has also led to

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread PMario
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:

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread PMario
On Saturday, October 3, 2020 at 10:18:14 AM UTC+2, @TiddlyTweeter wrote: > > 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 >

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread PMario
On Saturday, October 3, 2020 at 10:56:44 AM UTC+2, @TiddlyTweeter wrote: > > 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.

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread PMario
On Saturday, October 3, 2020 at 11:56:54 AM UTC+2, @TiddlyTweeter wrote: > > 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

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread PMario
On Sunday, October 4, 2020 at 8:42:31 AM UTC+2, @TiddlyTweeter wrote: 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 >

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread PMario
On Sunday, October 4, 2020 at 8:42:31 AM UTC+2, @TiddlyTweeter wrote: > > 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

[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

[twdev] Re: Custom markup (continued 3)

2020-10-04 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-03 Thread PMario
On Saturday, October 3, 2020 at 12:57:31 PM UTC+2, @TiddlyTweeter wrote: *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

[twdev] Re: Custom markup (continued 3)

2020-10-03 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-03 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-03 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-10-03 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-09-30 Thread PMario
On Wednesday, September 30, 2020 at 5:10:49 AM UTC+2, TonyM wrote: I have published [RFC] Request for Comment and collaboration - Unique > renamable Tiddlers and children with any name, a total Database? > > Just now, the

[twdev] Re: Custom markup (continued 3)

2020-09-29 Thread TonyM
Mario, Yes Very interesting. Please keep this possibility alive, I agree the checklist plugin is great, and its very low complexity in wikitext one of its key advantages however I do like the ability to have a minimalist output or read only view of those we can build in custom wiki text

[twdev] Re: Custom markup (continued 3)

2020-09-29 Thread PMario
I did add a bit more colour to the examples, to visualize the data-flow a bit better. -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

[twdev] Re: Custom markup (continued 3)

2020-09-29 Thread PMario
Hi, I'm not 100% sure about the parameter names. So they may change. -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

[twdev] Re: Custom markup (continued 3)

2020-09-29 Thread PMario
Hi folks, I did just upload V 0.5.3 that contains 3 more very powerful parameters. It lets us do the following: \customize degree=☐ _element="$macrocall" $name="check" _1=tid \define check(src, tid) <$checkbox tiddler=<> tag=done class="db"> <<__src__>> \end °☐:a This is a test °☐:b This

[twdev] Re: Custom markup (continued 3)

2020-09-26 Thread TonyM
TT et al, Word of the day? "Nomenclature " The easiest way I could describe it is "*Private Shorthand Supporting > Public Messaging*". > > One advantage we have both by design and by circumstance is TiddlyWiki produces its results via

[twdev] Re: Custom markup (continued 3)

2020-09-26 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-09-26 Thread PMario
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

[twdev] Re: Custom markup (continued 3)

2020-09-26 Thread PMario
On Saturday, September 26, 2020 at 3:28:40 AM UTC+2, TonyM wrote: 2. Setting and using evaluated variables > \customize tick=ghost _element="$set" name=ghost > filter="""[all[current]addprefix[$:/ghost/]]""" _endString="/ghost" > > ´ghost <> > > And <> the value is here > > <$set name=new-var

[twdev] Re: Custom markup (continued 3)

2020-09-26 Thread @TiddlyTweeter
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

[twdev] Re: Custom markup (continued 3)

2020-09-26 Thread @TiddlyTweeter
TonyM (& PMario) TonyM wrote: > > Readability in programming languages has often simply come from a body of > work. You can write code in short or long ways. I imagin you choose > depending on the audience. For example your own shortcuts where at *most > *others > view the results can be as

[twdev] Re: Custom markup (continued 3)

2020-09-25 Thread TonyM
Folks, I continue researching the possibilities for these reasons - It is seriously exciting - To work with Mario and others (What a pleasure) - To discover the possibilities - To test the limits, and perhaps uncover minor tweaks that add great value - Lastly to solve long

[twdev] Re: Custom markup (continued 3)

2020-09-25 Thread TonyM
TT, Readability in programming languages has often simply come from a body of work. You can write code in short or long ways. I imagin you choose depending on the audience. - For example your own shortcuts where at more others view the results can be as brief as you want. - If

[twdev] Re: Custom markup (continued 3)

2020-09-25 Thread @TiddlyTweeter
> > @TiddlyTweeter wrote: 1 - does the end user need to see what the author used? My guess is that > they *don't.* > I mean we are doing this to make WRITING easier. But most READERS won't be > writers so will never need to see the markup glyphs. > > PMario wrote: > You are right, but 1