Mario, An Idea, to avoid us returning to a solution which has no additional glyphs config, could be solved by providing a packaging solution, not unlike the bundler plugin. We can just select tiddlers with customise and bundle the definitions and custom definitions to ensure transferability.
Of importance here though, I am suggesting giving the vast majority of users, an appropriate set of pre-defined glyphs, they may never know you can define more. Being able to customise them, apply parameters and classes, use symbols etc... "is more than enough rope". But we know and we can innovate via this new Glyph mechaisium. If we can define a way to distribute a new glyph definition, perhaps in a separate file or plugin then a level of modularisation occurs, even allowing us to build the default glyphs in the same way. There is no harm if it demands a reload, we can force it in a glyph definition plugin, with customise wiki text as a dependency. This customised wikitext solution is so powerful I think providing such an extencibility feature is wise, otherwise there will be too much pressure to update the core solution, and I do not want this to become a maintenance issue for you. As long as we can see what glyphs have being defined, it is possible to search for all tiddlers making use of that glyph, and advantage of using Unicode characters rarely found in content. If I go to export a tiddler with customised pragma, if I identify which defined pragma are in use in the current tiddler, and include their definitions, perhaps not the default (definitions), but also optionally the plugin as well. Then transfer becomes easy. Now, I must declare knowing what customise can achieve so far, and the wealth of shiny Unicode characters, I am taken by the possibilities for writing my own content with any custom wikitext I desire. I really don't care if its transferable, people can read the rendered results, I can capture static HTML or deliver customisations in any Wiki I want. I am already thinking about a glyph for footnotes or extreme semantics like ∴ This is the conclusion or therefore statement in my text ;This is another conclusion :This will be helpful ∴ review and extend these ideas. That my knowledge base can extract and I can globally reformat in one place. All by customising a meaningful glyph. Single line mark-ups for questions, answers, therefore, to do, details, references, errors, .... all triggered by glyph<space> With customise wikitext these can be used to trigger tasks, tiddlers, workflows and more all from insertion of a single glyph. By being able to choose the glyph we can customise meaningful single character mark ups in a highly semantic way, rather that having to remember a glyph/symbol pair. This is after all offering a personal productivity solution, sufficient to be wiki specific, as much as, a feature for tiddlywiki for lots of wikis. Regards Tone=y On Friday, 30 October 2020 03:15:20 UTC+11, PMario wrote: > > On Thursday, October 29, 2020 at 1:05:53 AM UTC+1, TonyM wrote: > > Just a thought, if the customise definition was to accept both glyph and >> symbol as parameters this may be an easier approach. >> \customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight >> _classes=".highlight" _mode=inline >> even an new \customise-def that accepts _glyphs and _glyphNames and >> \customise does not. >> > > Those definitions will need to be done at startup time. > > >> Then all the existing definitions would be transferred into this form, >> but could be altered. >> > > That's right. > > Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent >> use such as >> \customise openenc _classes=".highlight-green" >> In effect a redefinition, like the current customise. >> >> In the worst case there will need to be a start-up process that puts >> glyph definitions in a specific tiddler into a table, ie reload to add new >> glyphs. >> > > That would need to happen. ... When \customize definitions are parsed, the > whole initialisation process is in the past. So there would need to be a > configuration tiddler, that contains the necessary definitions. > > The problem is, that the user, which wants to define the config tiddler > would have to know exactly, how the parser works, to do the right things. > ... I think it will be an education / documentation problem. > > >> Forgive me for interfering in this aspect of coding, which I am as yet >> unable to contribute to myself. I wish you had another "coder" (or more) >> sharing your effort. >> > > I do have a little problem with too many different "glyphs". .. It may > also be a "tower of babel" problem, which could make interchanging content > much harder. ... So if something is hardcoded, all users have to use the > same "mechanisms". ... > > >> I would just add to the general discussion, whilst global customise is a >> valuable tool, I can see customise being added to the specific tiddlers >> that wish to use extended mark-up, so in many cases the scope will only be >> the current tiddler. If a text contains a glyph the editor can just choose >> another for their special mark-up, a small popup panel could list the >> glyphs found in a tiddler. >> > > If something is defined on a per tiddler basis, I don't see a big problem. > ... The problem for content interchange comes with global definitions. .. > If users forget to export the global definitions and the tiddler don't > contain any info, that there actually IS a global definition. > > That's why at the beginning there had to be an \importcustom [[abc]]. If > a tiddler contains this info. Everyone knows what to request. ... > > >> Another approach is using a custom type field, and the type which is >> equivalent to a mime type also permits providing the character set. >> > > At the moment the core TW doesn't know how to deal with custom mime-types, > which basically makes it impossible to use them. > > -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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/4e39e5a0-5d92-4e67-ac34-860fee88d38bo%40googlegroups.com.
