[twdev] Re: Migrating to GitHub discussions

Ciao Jeremy Good idea. (1) GG is becoming a big pain to use. Especially if you need to add code blocks or edit messages. (2) Github style Discussion IS approachable even if you are not a dev. Best wishes TT On Thursday, 10 December 2020 at 16:18:54 UTC+1 Jeremy Ruston wrote: > We are

[twdev] Re: Custom markup (continued 4)

iscellaneous Mathematical Symbols-B 128 glyphs > U+2A00–U+2AFF Supplemental Mathematical Operators 256 glyphs > Glyph Variants (not all math) 1353 glyphs > > > Regards > Tony > On Friday, 11 December 2020 at 06:02:52 UTC+11 @TiddlyTweeter wrote: > >> *Problems Of Working I

[twdev] Re: Custom markup (continued 4)

TonyM wrote: > Here is a summary of the existing glyphs > I established this with this site https://unicode-table.com/en/ > Just FYI I use the program BabelMap on Win to investigate Unicode Font Support. Excellent program that has no registry

[twdev] Re: Custom markup (continued 4)

*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

[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

[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

[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

[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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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 G

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

*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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

*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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

*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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

t; >- 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?. > > Regard

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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 >

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

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

[twdev] Re: Custom markup (continued 4)

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

[twdev] Re: Custom markup (continued 4)

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 b

[twdev] Re: Custom markup (continued 4)

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

[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"

[twdev] Re: Custom markup (continued 4)

ber 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

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

[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 i

[twdev] Re: Custom markup (continued 4)

ay, 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 Glyp

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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:

[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

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

[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

[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

[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

[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

[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

[twdev] Re: Custom markup (continued 3)

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

[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

[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

[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

[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

[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"

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

[twdev] Re: Custom markup (continued 3)

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)

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)

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)

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

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

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

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)

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)

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

[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

[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

[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

[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

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

[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

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

[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

[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

[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

[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 Uni

[twdev] Re: Custom markup (continued 3)

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)

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)

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)

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)

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)

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)

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

[twdev] Re: Custom markup (continued 3)

tuck 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"

[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

[twdev] Re: Custom markup (continued 3)

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)

> > @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: &

[twdev] Re: Custom markup (continued 2)

On Friday, 25 September 2020 13:35:17 UTC+2, PMario wrote: > > On Friday, September 25, 2020 at 12:13:08 PM UTC+2, @TiddlyTweeter wrote: > > Can you PLEASE correct angel to angle. >> > > I knew, that someone would have a problem. But for me this looks like an > ang

[twdev] Re: Custom markup (continued 2)

them supported by a font. Thoughts TT On Friday, 25 September 2020 12:20:12 UTC+2, PMario wrote: > > On Friday, September 25, 2020 at 11:11:56 AM UTC+2, @TiddlyTweeter wrote: > > Unicode does provide many *paired glyphs*, albeit some are outside the >> UTF-16 range. >>

[twdev] Re: Custom markup (continued 2)

Ciao PMario Can you PLEASE correct angel to angle. You may not realise the cognitive dissonance it causes. In English my life partner was Angela (German, deceased), I am godfather to the child Angelo (Italian, male) & friend of Angelo (an Italian policeman). Add in the generic issue that

[twdev] Re: Custom markup (continued 2)

pose it to every user. I think it would be a support issue of scale to do so. Ongoing thoughts. Just thoughts. Best wishes TT On Friday, 25 September 2020 10:59:08 UTC+2, @TiddlyTweeter wrote: > > This for PMario & TonyM > > Its a thought. > > *TWO config modes ...* > >

[twdev] Re: Custom markup (continued 2)

PMario & TonyM Unicode does provide many *paired glyphs*, albeit some are outside the UTF-16 range. See, for instance, *some *of them: https://www.compart.com/en/unicode/mirrored Best wishes TT On Friday, 25 September 2020 10:26:40 UTC+2, @TiddlyTweeter wrote: > > Ciao TonyM > &

  1   2   3   4   >