[twdev] Re: Custom markup (continued 2)

Mario, I don't think very specific id's are a problem if the result is of substantial utility. I have a larger concern about the symbols which have a wider applicability, because I think they need to be given a default purpose, kind of defacto standard for each of them, to encourage some consi

[twdev] Re: Custom markup (continued 2)

On Friday, September 25, 2020 at 12:42:07 PM UTC+2, @TiddlyTweeter wrote: There are two issues in our context ... > > 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 s

[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 > angel »|« , with some phantasy.

[twdev] Re: Custom markup (continued 2)

Hi folks, We should go on here: Custom markup (continued 3) have fun! -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving email

[twdev] Re: Custom markup (continued 2)

On Friday, September 25, 2020 at 1:26:12 PM UTC+2, PMario wrote: ... Tony wanted the possibility to add more key=value _params. .. And I think > it should be possible, in the _params section and calling it. eg: > > °☐:a This is a Test > It should be also possible to use the Ballot Box

[twdev] Re: Custom markup (continued 2)

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 angel »|« , with some phantasy. I'll think about it, since there may be some "religious" concerns too

[twdev] Re: Custom markup (continued 2)

On Friday, September 25, 2020 at 12:00:22 PM UTC+2, @TiddlyTweeter wrote: > > To clarify my last point about TWO configs, nasty & irritating as the idea > is :-(... > > I think it very LIKELY that PMario's Custom Markup system will be, > eventually, widely used by AUTEURS (originating author geek

[twdev] Re: Custom markup (continued 2)

Ciao PMario Right. But beyond 16 it looks like *A* character it isn't exactly that. But glad you'd be happy with that. Sure there are many pairs not to use because of common usage already. That still leaves a lot of Unicode pairs available. There are more than I pointed too. My POINT, I think

[twdev] Re: Custom markup (continued 2)

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. > See, for instance, *some *of them: > https://www.compart.com/en/unicode/mirrored > For javascript, it's not necessary, to use UTF-1

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

To clarify my last point about TWO configs, nasty & irritating as the idea is :-(... I think it very LIKELY that PMario's Custom Markup system will be, eventually, widely used by AUTEURS (originating author geeks). I am NOT convinced that a TW that uses that brilliant system should expose it t

[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 > > As ever from

[twdev] Re: Custom markup (continued 2)

This for PMario & TonyM Its a thought. *TWO config modes ...* Config 1 - that adds the editing tools to enable the PMario Custom Markup explicitly (i.e for any user) Config 2 - that adds the tool BUT adds NOTHING to the editor. I'm thinking of cases where USER needs basic usage but NOT to eve

[twdev] Re: Custom markup (continued 2)

Ciao TonyM As ever from you an inclusive, broad reply. I'm actually wondering a slightly different way. Narrower. But very real. ... For instance ... *Does it matter if an end-user on web has the markup character in a font?* Personally I like to use glyphs from any of the UTF-16 doable Unicode

[twdev] Re: Custom markup (continued 2)

TT, > But, as I work with it myself I sometimes struggle with the PERMUTATIONS > possible. > This is so often the case in tiddlywiki, the customisations and possibilities are virtually infinite in many directions. This is just another few dimensions of control. > My main wondering is WHO i

[twdev] Re: Custom markup (continued 2)

Ciao PMario I read through all the threadd from the start again. *Doing that is interesting! The evolutions!* I'm looking at it thinking "is this for MAKERS of Wikis mainly?" It would certainly enable me to make BESPOKE solutions much more easily. Why? Simpler leverage of HTML & CSS. Your a

[twdev] Re: Custom markup (continued 2)

Comments as I work on a concrete example for PMario to see. UPSIDES 1 - I think use cases will be able to BETTER leverage the more modern usefully semantically supportive HTML5 elements, like ... *nav* *main* *article* *section* *header* *footer* 2 - open-up much EASIER use of CSS because ...

[twdev] Re: Custom markup (continued 2)

Mario, Is it not your bed time? > > There is a typo: you need to close the first widget element: `<$count > filter="[prefix[$:/state]]">` > > Not really. The string is like the _endString parameter for > the standard TW parser. So it doesn't need to be created. > My mistake again. However

[twdev] Re: Custom markup (continued 2)

On Wednesday, September 23, 2020 at 11:13:10 PM UTC+2, TonyM wrote: > However, without customisations > Count: `<$count filter="[prefix[$:/state]]"/>` works > Count: `<$count filter="[prefix[$:/state]]"` does not > There is a typo: you need to close the first widget element: `<$count filter="[

[twdev] Re: Custom markup (continued 2)

Hi I did update the page and the pluginlibrary 5 minutes ago -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 tiddlywikidev+unsubscr...@googlegroups.com. To v

[twdev] Re: Custom markup (continued 2)

Mario, Yes I was erroneously using the 4.1 version while testing 5.1 (my Bad) Every widget that is used "self closing" like <$count /> there should be > _no_ problem. They should all work. _And with the _srcName you have *one > parameter*, that can be defined in the "user line".. > > However, w

[twdev] Re: Custom markup (continued 2)

On Wednesday, September 23, 2020 at 1:20:52 PM UTC+2, TonyM wrote: > I think you suggested this before, but our use of widgets is limited by > those who do not honour the close part of <$wiggetname > params>content rule > It needs to be content or template in the body. > A case in point i

[twdev] Re: Custom markup (continued 2)

On Wednesday, September 23, 2020 at 12:22:54 PM UTC+2, TonyM wrote: > Especially the use of src > > Do I understand correctly the _srcName=filter effectively says, assign > the value found in the line, to the parameter filter, in this case that is > in the list? > Right! If _element is a wi

[twdev] Re: Custom markup (continued 2)

Mario, I think you suggested this before, but our use of widgets is limited by those who do not honour the close part of <$wiggetname params>content rule A case in point is the <$count widget, as it can only be closed with /> not Going forward - Perhaps we should raise this as a fix, for

[twdev] Re: Custom markup (continued 2)

Mario, Thanks, there is a lot of good news there. Especially the use of src Do I understand correctly the _srcName=filter effectively says, assign the value found in the line, to the parameter filter, in this case that is in the list? FYI only With TocP I noticed I can create the child field

[twdev] Re: Custom markup (continued 2)

On Wednesday, September 23, 2020 at 10:49:18 AM UTC+2, TonyM wrote: \customize tick=children _element="$list" filter="[parent]" > > > And the last one children has set me of on a one and many to many > relationship solution > * now that what TocP is no longer magical to me :) > I see :) -m --

[twdev] Re: Custom markup (continued 2)

On Wednesday, September 23, 2020 at 10:49:18 AM UTC+2, TonyM wrote: This example not only shows that the customise pragma can be used to store > a canned filter for reuse, but also shows how the first in a nested list > can be concealed behind a helpful name like system-shadows > \customize tic

[twdev] Re: Custom markup (continued 2)

On Wednesday, September 23, 2020 at 8:46:08 AM UTC+2, TonyM wrote: A little experimental fun; > :) > This method uses the vars widget to pre-define a set of variables for use > inside the custom markup. As in this examples we have all out standard > address details using well known names. Yo

[twdev] Re: Custom markup (continued 2)

Mario and Folks, This example not only shows that the customise pragma can be used to store a canned filter for reuse, but also shows how the first in a nested list can be concealed behind a helpful name like system-shadows \customize tick=system-shadows _element="$list" filter= "[all[shadows]i

[twdev] Re: Custom markup (continued 2)

Folks, A little experimental fun; This method uses the vars widget to pre-define a set of variables for use inside the custom markup. As in this examples we have all out standard address details using well known names. You choose which to use and how to arrange them. Of course the variable are

[twdev] Re: Custom markup (continued 2)

On Tuesday, September 22, 2020 at 8:46:25 PM UTC+2, Mat wrote: > > So, if the CSS is defined elsewhere, do I understand it right that the > user has to insert the following bit in every tiddler that he wants to make > such styled notes in? > See the \importcustom pragma https://wikilabs.github.

[twdev] Re: Custom markup (continued 2)

PMario - thanks for replies. Some questions and thoughts: So, if the CSS is defined elsewhere, do I understand it right that the user has to insert the following bit in every tiddler that he wants to make such styled notes in? \customize angel="note" _element="div" > _params=".note.notop.cbox.

[twdev] Re: Custom markup (continued 2)

Ciao PMario I been working on a sample case for you to see later. One issue came up is related to the complexity of some the \cstomize rules. Basically the need, ideally, to be able to add COMMENTS so the author can note what they are doing ... Lets take this as an example... PMario wrote >

[twdev] Re: Custom markup (continued 2)

Hi, If you have some text from the book, ASIDE would be an option too. https://wikilabs.github.io/editions/custom-markup/#test-aside-without-pragma:test-aside-without-pragma%20test-aside-clearfix So your comments can be the aside element. -mario -- You received this message because you are

[twdev] Re: Custom markup (continued 2)

On Tuesday, September 22, 2020 at 2:20:08 PM UTC+2, PMario wrote: »note ´page [[book]] 1-5 > your comment! > -- > You can define a stamp of the above text to be quicker. Just some thoughts. -mario -- You received this message because you are subscribed to the Google Groups "TiddlyWikiD

[twdev] Re: Custom markup (continued 2)

Hi Mat, I think it can be done in a similar way to the html DETAILS element. I'd go with something similar to this: BUT the section should be in a separate CSS tiddler \customize angel="note" _element="div" _params=".note.notop.cbox.cbox-primary.hard-linebreaks" open _mode=block _endStrin

[twdev] Re: Custom markup (continued 2)

On Tuesday, September 22, 2020 at 12:04:52 PM UTC+2, Mat wrote: > > I'm unfortunately swamped with work, thus my absence here. Sorry for that. no problem. I have to go through several books and in doing so I take out notes and > quotes. I want to refer to these snips by the page they can be fou

[twdev] Re: Custom markup (continued 2)

TonyM wrote: > For the minute a macro seems the best. > Sorry, missed this point. The problem with a macro is that it is too finicky to use for quick note taking. It demands too many characters. <> <:-) -- You received this message because you are subscribed to the Google Groups "TiddlyWik

[twdev] Re: Custom markup (continued 2)

Thanks for reply Tony. OK, so there are actually some more nuances and bits but what I noted above is a "base case": Here is the most simple example from my own notes. It is an arbitrary snip from a tiddler named "The Thomas Sowell Reader, Sowell" : pp336 When people put up dogmatic ideas, ask

[twdev] Re: Custom markup (continued 2)

Mat, Can you give me a quick sample of what details you will give and how you want it to appear. For the minute a macro seems the best. Regards Tony On Tuesday, 22 September 2020 at 20:04:52 UTC+10 Mat wrote: > I'm unfortunately swamped with work, thus my absence here. Sorry for that. > > How

[twdev] Re: Custom markup (continued 2)

I'm unfortunately swamped with work, thus my absence here. Sorry for that. However, as part of my work I found a use case that I figured is worth reporting because it should be a rather common one: I have to go through several books and in doing so I take out notes and quotes. I want to refer t

[twdev] Re: Custom markup (continued 2)

TT, I understand your concern, its correct to raise it. I think you need a explanation from me who is pushing this capacity, is warranted. - What I am doing is pushing the solution to its logical conclusions, not to necessarily expand the features (although that is good), but explore

[twdev] Re: Custom markup (continued 2)

On Monday, September 21, 2020 at 7:42:38 PM UTC+2, @TiddlyTweeter wrote: BUT are we seeing a version of Advanced Yoga (bloke was able to twist his > leg behind his head)? > Probably yes. ... > My concern is it will confuse adding macros. Let's see. > With TW5 Jeremy invented the widgets. W

[twdev] Re: Custom markup (continued 2)

PMario wrote: > > @TiddlyTweeter wrote: >> >> The more I hear about "macros" in this the worse I feel. >> > > Why? ... It works now, which is a big win. > Right. More power to you. BUT are we seeing a version of Advanced Yoga (bloke was able to twist his leg behind his head)? My concern is it w

[twdev] Re: Custom markup (continued 2)

@Tony, If you drag & drop import the WikiLabs Plugin Configuration tiddler into your wiki, you can update with the default TW plugin update workflow. -mario -- You received t

[twdev] Re: Custom markup (continued 2)

On Monday, September 21, 2020 at 6:13:28 PM UTC+2, @TiddlyTweeter wrote: > > The checklist example TonyM gave I don't think adds anything that does not > exist already. > > As PMario implied before, the Grossinger plugin IS using markup > intelligently to deliver live. > > Dimmi (tell me) the add

[twdev] Re: Custom markup (continued 2)

On Monday, September 21, 2020 at 6:06:56 PM UTC+2, @TiddlyTweeter wrote: > > The more I hear about "macros" in this the worse I feel. > Why? ... It works now, which is a big win. > I don't care if the device lets you skip over the moon. I DO care that > mortals can understand it. OR totally av

[twdev] Re: Custom markup (continued 2)

Hi Latest version is now at: https://wikilabs.github.io/editions/custom-markup/ V0.5.1 @ Tony your "macro" call works now. And there is a new _srcName parameter. Mario -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from th

[twdev] Re: Custom markup (continued 2)

The checklist example TonyM gave I don't think adds anything that does not exist already. As PMario implied before, the Grossinger plugin IS using markup intelligently to deliver live. Dimmi (tell me) the added value, please! Regards TT On Monday, 21 September 2020 18:06:56 UTC+2, @TiddlyTwee

[twdev] Re: Custom markup (continued 2)

The more I hear about "macros" in this the worse I feel. I don't care if the device lets you skip over the moon. I DO care that mortals can understand it. OR totally avoid it. IMO "macro use" within this tool is a *highly advanced *feature. I am very UNCLEAR of the added value. I need examples

[twdev] Re: Custom markup (continued 2)

On Monday, September 21, 2020 at 10:54:48 AM UTC+2, @TiddlyTweeter wrote: ... > I also read the detail on discussion of using it for macros. I'm slightly > nervous about that. > The GAINS on HTML insertion and CSS styling are very substantial. I would > not want handling macros to confuse the b

[twdev] Re: Custom markup (continued 2)

On Monday, September 21, 2020 at 6:05:06 AM UTC+2, TonyM wrote: *The macro(s) just for completeness* > \define done-check(tiddlername) > \whitespace trim > <$set name=tiddlername value="""$tiddlername$""" > emptyValue=<> > > <$list filter="[!done[yes]!done[cancel]]"> > <$button tooltip="click to

[twdev] Re: Custom markup (continued 2)

On Monday, September 21, 2020 at 6:05:06 AM UTC+2, TonyM wrote: I expect it is too late in the rendering process; but it seems common sense > (does not mean it is) that some pragma could read as such; > °☐ "This is a todo line" > This will work with *V0.5.1*! There was a bug in my praser _and_

[twdev] Re: Custom markup (continued 2)

Hi Tony, I did find a bug, that made it impossible to use \customize _element="$xxx" properly. ... There was a problem with the parameter parsing. It will be fixed with the next version. I did also have a look, which widgets can be customized. .. It seems all of them should work. But I'm no

[twdev] Re: Custom markup (continued 2)

Mario, The need for an endString, although may be valid in other use cases is a good way to recognise when a multi-line block or inline text is in use, rather than the line based approach. Many of the current wiki text is line based. It seems to me that making use of a method like °/.classname

[twdev] Re: Custom markup (continued 2)

> > @TiddlyTweeter wrote: > >> >> I do have issues with INLINE markup (°) in that there is no way to nest >> at the moment. It is also "verbose" having to do °°match°°. >> > > PMario wrote: > Yea, Inline needs more love. It's the basic function only. similar to > @@match@@ So we don't win anyt

[twdev] Re: Custom markup (continued 2)

On Monday, September 21, 2020 at 10:54:48 AM UTC+2, @TiddlyTweeter wrote: I had an example Use Case to show but things changed so much in your tool > I'm revising it. Hopefully I have time soon. > Yea, It was alpha as we started. It is beta now. So I think we settled on the naming conventions.

[twdev] Re: Custom markup (continued 2)

PMario Regarding B*F matching on closure. I think its fine you COULD do it (might be needed in some off-beat use cases). Just don't document those :-). TBH closing "»" a default of "«" looks good to me. TT On Friday, 18 September 2020 14:03:01 UTC+2, PMario wrote: > > On Friday, September

[twdev] Re: Custom markup (continued 2)

Ciao PMario I had an example Use Case to show but things changed so much in your tool I'm revising it. Hopefully I have time soon. I think, over-all, your approach is really good. It is somehow managing to balance existing TW coding with extensions AND innovations well. I can see it got comple

[twdev] Re: Custom markup (continued 2)

Mario, Thanks for your responses. I built a macro for "active todo items" for the checkbox idea and more; below; It is clear the processing of pragmas is a black box I cant see in. So thanks for being patient with my suggestions. - The following does work as a pure macro, it is simply to gi

[twdev] Re: Custom markup (continued 2)

On Sunday, September 20, 2020 at 6:02:43 AM UTC+2, TonyM wrote: > > Mario, Et al. > > More review and research into the extensibility on top of Version 0.4.1 > > I just did this in a tiddler > \customize degree="button" _element="$button" mode="block" > \customize tick="kbd" _element="kbd" > >

[twdev] Re: Custom markup (continued 2)

On Sunday, September 20, 2020 at 1:12:12 AM UTC+2, TonyM wrote: This idea is very powerful from a user perspective, but I have no idea how > achievable technically, please give it some thought. > >- If feasible it only needs the development of one new customise >feature reference the co

[twdev] Re: Custom markup (continued 2)

Mario, Et al. More review and research into the extensibility on top of Version 0.4.1 I just did this in a tiddler \customize degree="button" _element="$button" mode="block" \customize tick="kbd" _element="kbd" °button Content ´kbd This is > [[A List]] > of items another However I am confu

[twdev] Re: Custom markup (continued 2)

Mario, This idea is very powerful from a user perspective, but I have no idea how achievable technically, please give it some thought. - If feasible it only needs the development of one new customise feature reference the content - My thought is a variable such as currentContent, idea

[twdev] Re: Custom markup (continued 2)

I need to clock Off, almost midnight here, Great work, The revolution is Brewing :) Tony On Friday, 18 September 2020 at 23:44:48 UTC+10 TonyM wrote: > > Mario, > > >> The Usage string is: ° » ´ › - -- --- >> > > Lol > > Actually finally we have a way to obfuscate! for good I mean, like har

[twdev] Re: Custom markup (continued 2)

Mario, > The Usage string is: ° » ´ › - -- --- > Lol Actually finally we have a way to obfuscate! for good I mean, like hard to find strings. Or user or password details? Regards Tony -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 2:18:47 PM UTC+2, TonyM wrote: > > In the new Google Groups I can edit an existing post :( again > *Additional Content* > > In the below it demonstrates how convention allows the Capital to be used, > eg Big X refers to Close all > >- Close all works, but not c

[twdev] Re: Custom markup (continued 2)

It would be used mainly for documentation purposes -m On Friday, September 18, 2020 at 2:27:27 PM UTC+2, PMario wrote: > > That's a nice example. > > But what I wanted is a "partial" copy-to-clipboard, which isn't possible > atm. The <$button> body is used to create the button-text > instead of

[twdev] Re: Custom markup (continued 2)

That's a nice example. But what I wanted is a "partial" copy-to-clipboard, which isn't possible atm. The <$button> body is used to create the button-text instead of defining the text, that should be copied. So the widget I'm imagining is more like this <$clipboard buttonText="copy to clipboa

[twdev] Re: Custom markup (continued 2)

Hi, I think the following works well out of the box for me. ».hl several lines of paragraph text with single line breaks where onyl 1 indicator is needed just a thought. -m -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe fro

[twdev] Re: Custom markup (continued 2)

In the new Google Groups I can edit an existing post :( again *Additional Content* In the below it demonstrates how convention allows the Capital to be used, eg Big X refers to Close all - Close all works, but not copy to clipboard? - Again this shows how rather than write a macro you can

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 1:39:42 PM UTC+2, TonyM wrote: Example (just a brainstorm) may be inaccurate as I learn still to memorise > the existing, its just the concept. I am still to learn how some simple > defaults will lend them self to each character. But publishing firs as just > a

[twdev] Re: Custom markup (continued 2)

All, In the below it demonstrates how convention allows the Capital to be used, eg Big X refers to Close all - Close all works, but not copy to clipboard? - Again this shows how rather than write a macro you can use _element="$widget" to simply code a shortcut for a button - I i

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 1:45:12 PM UTC+2, TonyM wrote: These answers of yours really are demonstrating the flexibility. We need > some how to capture this knowledge, without making it too complex for > users. > Yea, I try to build a "story" around the possibilities. ... I did try to s

[twdev] Re: Custom markup (continued 2)

Mario, I think this could be an independent solution. ANd alias may be away to go, but I am thinking more with a view to core one day, perhaps that's where a simplified alias should go as well? Regards Tony On Friday, 18 September 2020 at 20:55:56 UTC+10 PMario wrote: > I'll give it an -

[twdev] Re: Custom markup (continued 2)

Mario, These answers of yours really are demonstrating the flexibility. We need some how to capture this knowledge, without making it too complex for users. Tony On Friday, 18 September 2020 at 21:11:32 UTC+10 PMario wrote: > On Friday, September 18, 2020 at 4:21:21 AM UTC+2, TonyM wrote: > >

[twdev] Re: Custom markup (continued 2)

Sorry, Not sure what you mean here, but its intriguing. Tony On Friday, 18 September 2020 at 20:58:13 UTC+10 PMario wrote: > On Friday, September 18, 2020 at 3:40:10 AM UTC+2, TonyM wrote: > > In the process of us developing this solution I see the value in the use >> of templates, but this ma

[twdev] Re: Custom markup (continued 2)

Mario, Some responces; > > That will be a ToDo, since we will need to improve the TW doc quite a bit, > so we can link to it. The existing docs > >

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 4:21:21 AM UTC+2, TonyM wrote: As I said before, I love the "details" example of yours. However I just > wanted to let you know, I do not resonate with you use of multiple hyphens > -- and --- etc, perhaps because of my eye-site or the difficulty matching > or r

[twdev] Re: Custom markup (continued 2)

Mario, *Like Tail winds says;* *Most CSS frameworks do too much. They come with all sorts of predesigned components like buttons, cards, and alerts that might help you move quickly at first, but cause more pain than they cure when it comes time to make your site stand out with a custom design.*

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 3:40:10 AM UTC+2, TonyM wrote: In the process of us developing this solution I see the value in the use of > templates, but this makes me baulk, because the standard naming needs to be > a system tiddler, then as a result it needs another prefix such as in my >

[twdev] Re: Custom markup (continued 2)

I'll give it an OT - marker. But it is slightly related. You are right. "readable" wikitext shouldn't contain the $:/xxx/yyy/ namespace. I was already thinking about the possibility to use my uni-link plugin

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 12:16:03 PM UTC+2, PMario wrote: At the moment the only way to influence the parser is \importcustom per > tiddler and per macro. BE AWARE > > \define x() > \importcustom [[pragma-details]] > °d °s Details - Summay > --- > line 1 > line 2 > -- > \end > > <> >

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 3:20:37 AM UTC+2, TonyM wrote: ... > View on top of V4.1 > >- I think you could delegate the historical methods to a link rather >than have them complicate the documentation from the beginning. How to >style a Paragraph > >

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 2:34:16 AM UTC+2, TonyM wrote: I have to download your new versions so I can save changes. Then you > release another. Could you add the local storage plugin (not enabled) so I > can activate it install other plugins is needed? I will export local > storage, the

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 11:24:01 AM UTC+2, PMario wrote: >>- Perhaps the short form of color boxes ".cbox-primary" should be cbp >>cbs etc... this leaves .cb available for simple color Blue >> >> OK .. I'll make them .cb .. for the box definition and .cbX for the color > defini

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 2:28:28 AM UTC+2, TonyM wrote: Related notes > >- An interesting observation is if you select and copy a *rendered >tiddlers text* and paste it into a new tiddler, the result really >needs this custom formatting help. > > I think this could be done wi

[twdev] Re: Custom markup (continued 2)

On Friday, September 18, 2020 at 2:28:28 AM UTC+2, TonyM wrote: [...] > >- I notice if I have the cursor anywhere in a line and apply the ID it >works however the cursor jumps to the end of the line > - If the cursor could remain where was, or perhaps be placed just > after t

[twdev] Re: Custom markup (continued 2)

Version 4.0.1 Review continued; Advanced custom markup As I said before, I love the "details" example of yours. However I just wanted to let you know, I do not resonate with you use of multiple hyphens -- and --- etc, perhaps because of my eye-site or the difficulty matching or remembering how

[twdev] Re: Custom markup (continued 2)

Mario et al, minor related diversion. In the process of us developing this solution I see the value in the use of templates, but this makes me baulk, because the standard naming needs to be a system tiddler, then as a result it needs another prefix such as in my last example $:/core/ui/ListIte

[twdev] Re: Custom markup (continued 2)

Mario, View on top of V4.1 - I think you could delegate the historical methods to a link rather than have them complicate the documentation from the beginning. How to style a Paragraph Misusing s

[twdev] Re: Custom markup (continued 2)

Mario, I have to download your new versions so I can save changes. Then you release another. Could you add the local storage plugin (not enabled) so I can activate it install other plugins is needed? I will export local storage, then clear local storage and reload when you release a new version

[twdev] Re: Custom markup (continued 2)

Mario More notes - I notice if I have the cursor anywhere in a line and apply the ID it works however the cursor jumps to the end of the line - If the cursor could remain where was, or perhaps be placed just after the symbol I could then type a .class or something, but this wa

[twdev] Re: Custom markup (continued 2)

Hi New Version 0.4.1 https://wikilabs.github.io/editions/tick-text/ with more docs! @Mat, there should be enough Basic, Advanced and Reference material now, to test it! No new functions have fun! mario -- You received this message because you are subscribed to the Google Groups "TiddlyWi

[twdev] Re: Custom markup (continued 2)

OT On Thursday, September 17, 2020 at 12:20:40 PM UTC+2, @TiddlyTweeter wrote: > Revert to "Classic" (on Desktop). This will also let you complain to > Google as it will ask you why you are reverting ... > I did create a template, what to write: https://groups.google.

[twdev] Re: Custom markup (continued 2)

Revert to "Classic" (on Desktop). This will also let you complain to Google as it will ask you why you are reverting ... TT On Wednesday, 16 September 2020 19:59:23 UTC+2, Mat wrote: > > Annoyingly I can't "reply privately to author" anymore so must post this > publicly: > > @PMario - could you

[twdev] Re: Custom markup (continued 2)

On Wednesday, September 16, 2020 at 12:22:05 PM UTC+2, PMario wrote: > > Hi folks, > > This is the continuation of Custom markup > > [1] and Custom markup (continued) [2] >

[twdev] Re: Custom markup (continued 2)

Annoyingly I can't "reply privately to author" anymore so must post this publicly: @PMario - could you edit the first post in this thread to include the main link you recommend for testing things? Tx <:-) On Wednesday, September 16, 2020 at 12:22:05 PM UTC+2 PMario wrote: > Hi folks, > > This

[twdev] Re: Custom markup (continued 2)

New Version 0.4.0 uploaded: It contains the fixes, that Tony mentioned in the last 3 or 4 posts at: Custom markup (continued) [2] I did remove the "comma", since it didn't work out for me at the start of the line eg: ,.some