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,
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
*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
*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
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.
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"
*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
*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
*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
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
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"
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
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'
13 matches
Mail list logo
