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, otherwise it's much harder to find breaking changes. ... > 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 *@@text bits@@ *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 °text bits° for obvious typing a & visual readabilty > reasons > If we want to have nesting, we need to use at least 2 characters as a start and end sign. .. I was experimenting with: /° some text /° nested text °/°/ But I personally think, that's *confusing.* IMO °° some text °° nested text/°/° is easier to read and understand. The pragma will be: \customize inline=symbol ... other params as is ... Yes. There will be only 1 inline maker and it should be nestable! .. That's why we need to do it right! It my be used like this: °°symbol.class:param some text/° The symbol allows us to use the same possibilities as the block mode. > > 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. > At the moment *°textbit* will create an empty span. There has to be a closing sign. As shown above. I want to have the same possibilities as with block mode customisation. *°C* is valid prose text. We can't use a single starter like this. .. We need the possibility for <start>symbol.class.class.class:param:param some text<end> tick-tick ´´ is very close to backtick-backtick `` and will be confusing for most users. .. And we have ''bold'' which is very similar to double quoe " ..... So imo tick-tick is a _no_go. The same seems to be true for a single tick ... at least for me. > 3 - Point 2 *implies *that we need TWO inline markers. One for doubling > (e.g. *´ **text bits/´ *). One for solo (e.g. *°textbit*<space>) > It looks OK in your example, but if I use it like this: ´ text bits/´ there is a big difference. I think it's very hard to read, for users that don't use monospace text in the editor. 4 - IMO we should withdraw* ° *&* ´ * from block markup & replace them. > And RESERVE them for INLINE only. > The initial idea was named: "dot - paragraph" ... We couldn't use the dot at the start of the line, because that clashes with wikitext (dynamic) stylesheets. We used the tick ´ instead, because it is "almost" invisible if you read the prose text. > We need glyphs SPECIFIC for inline to ensure minimalism in design. > Those two characters are visually excellent for that job. > Writing all the above text .... I was thinking: . . . . What about: *_symbol.class.class:param:param some text__ _ some more text__ * I would have to make sure, that it doesn't clash with the __underline__ wikitext, but I think it may be possible. I personally would disable the "underline" wikitext to get this "inline thing" going. I would remove _ underscore from the block elements, because I didn't like it there anyway. But I think it looks good in _ inline text __. Start and end are easy to distinguish. ... right? And it doesn't do too much harm if no customize plugin is installed. I think the "underscore" character stand alone doesn't have a meaning in any language. ... I may be wrong here??? > I'm aware I'm giving a strong opinion to PMario as developer. > That's OK. ... I feel bad, that I have to say no to so many good ideas. ... But in one way or the other they clash with the initial idea or the requirements for the parser itself. > I think its good to be explicit when you can be. > That's right. -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/68f45cc5-62b5-43a0-a658-af68f5f3d440o%40googlegroups.com.
