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 to these snips by the page they can be found at. It is common practice to refer to a page using the abbreviation "p." or "pp." (not sure what pp stands for?). It would thus be convenient if one can someone use this for the markup. I'm not sure about the latest developments here but the natural way to document such snips would be either of e.g: pp30 Subsequent text p30 Subsequent text pp.30 Subsequent text p.30 Subsequent text - or for multiple pages - pp30-35 Subsequent text p30-35 Subsequent text ...etc The "output" needs to display the Subsequent text but also the page number/s. Maybe the current implementation in this thread is spot on, I don't know because I have lost track (again, sorry). I'm just reporting this because it is a use case we can expect. Because it is note-taking, it has to be really smooth and minimally distracting to make the actual note. (Some may argue that such snips ought to be individual tiddlers. Not only is that another discussion so let's not get in to it - but the (native) UI for creating individual tiddlers is definitely not smooth enough for live note taking.) OK, just a report from IRL. <:-) On Tuesday, September 22, 2020 at 1:31:33 AM UTC+2 TonyM wrote: > 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 > its consequences. > - We are not offering macros here, we are offering customised wiki > text. If we keep its documentation clear and concise it will be written in > a systematic way. > - The result of a concise systematic solution will be designers > will abstract and experiment. I am running down these paths to test the > validity. > - I am also doing this for issues that I perceive to be existing > limitations, > - By voicing these Mario looks at the "what if's", now if he > discovers with a tweak they can be made to work, we do not need to > document > exceptions, exceptions make a solution more complex > - To me to exclude macros, perhaps even transclusions (not raised > yet) will actually add exceptions and complicate the solution. > - users and designers bring with them a complex set of assumptions. > - We may need to document some warnings, what are the warnings if we > do not discover them? > - This solution is by its nature is handed to us by our Yogic teacher, > the Yoggy is empowering us to explore all the branches of our being. > > Not withstanding this desire, "not to limit" the possibilities (unless > identified as necessary) > > - I expect customised wiki text is going to be a method to an end, > basically with small group of designer and users actually writing > customise > pragmas for themselves > - A common use may be just the defaults > - I expect for example a writers wiki to be designed, with this plugin > and a set of prepared customisations to be included. > - The writer's wiki will not document the customisation plugin so > much, but the resultant set of custom markup that the writer will use. > - That is, there will often be an abstraction layer introduced, > between the specific implementation and the customise pragma. > - If however if someone goes down the customise pragma writing > themselves, the more they can leverage this commitment to a sophisticated > solution, and the more they will care about the capabilities. > > In short, the use of the customise pragma will be as complex as the user > wishes to make it. As is already the case for standard wiki text. > > Regards > Tony > On Tuesday, 22 September 2020 at 03:42:38 UTC+10 @TiddlyTweeter wrote: > >> 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 will confuse adding macros. Let's see. The issue is you >> will have to find a way to document BOTH major layout change AND the >> indefinable scope of macros (not all though) elegantly. >> I'm concerned its getting too complicated. BUT let us see. >> >> TT >> >> >>> >>>> 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. >>>> >>> >>> If you don't need it, don't use it. ... The problem was, that the >>> implementation had a bug, that's why something which should have worked .. >>> didn't. That was confusing for Tony. >>> >>> >>>> IMO "macro use" within this tool is a *highly advanced *feature. I am >>>> very UNCLEAR of the added value. >>>> >>> >>> It has the same value as "abstracting" widgets. For some "special" >>> usecases it will be possible to use wikitext to activate all kind of UIs, >>> without the need of "alien" widget names. >>> >>> I need examples to see the added value!!! >>>> >>> >>> There are a lot of test-xxx tiddlers, where I do test the code and the >>> TOC contains the beginning of the docs. >>> >>> -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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/6cd2fab5-6ff9-4ab2-a4b1-ea610c5ef9cfn%40googlegroups.com.
