[twdev] Re: TiddlyWiki 5 Dev Hangout #105 will be on Friday 9th February 2018 at 3pm GMT

I'd like to add some more points. Just as a reminder. No offence intended. On Wednesday, February 7, 2018 at 10:08:12 AM UTC+1, Jeremy Ruston wrote: > > TiddlyWiki 5 Dev Hangout #105 will be on Friday 9th February 2018 at 3pm > GMT. > > This will be another developer-oriented hangout to discuss

[twdev] Re: Controlling plugin order

I'm actually not editing the stylesheets, but the configuration tiddler itself. (e.g. $:/themes/tiddlywiki/vanilla/metrics/storywidth) But I'll look at put a list-after on my plugin, see if I can control plugin-order via that. Thanks! On Monday, February 12, 2018 at 12:00:09 AM UTC-5, Simon

[twdev] Re: Controlling plugin order

So, I found this code , and tried setting the `plugin-priority` field on my plugin, but it doesn't seem to affect the ordering. However, renaming my plugin from $:/plugins/mklauber/... to $:/zzz/plugins/mklauber/... does

[twdev] Re: Controlling plugin order

Finally tracked it down. It seems like there's a bug in ordering plugins when one has a plugin-priority and the other doesn't. I've thrown a PR up for the fix here. https://github.com/Jermolene/TiddlyWiki5/pull/3113 @Jeremy, can you take a look? Matt On Monday, February 12, 2018 at 10:48:1

Re: [twdev] [TiddlyDesktop] in linux app stores

Hi Simon > I don't know if there's already been discussion about providing easier access > to TiddlyDesktop through app stores Great idea. Getting it in the Mac App Store is, I think, feasible, because nwjs explicitly supports it. I’ve no experience of the Windows app store, or the Linux equiv

[twdev] TiddlyWiki Mod-Loader Plugin (a safer way to change the core)

Hey, all — Introducing the *Mod-Loader Plugin*: https://evanbalster.com/tiddlywiki/formulas.html#Mod-Loader%20Plugin This plugin allows shadow tiddlers in a wiki to be patched at boot-time. This makes it possible to change the TiddlyWiki core without creating conflicts or errors when the wik

[twdev] Feature Request: high-priority "bootloader" module-type

Hey, all — *(I had a Twitter discussion with Jeremy yesterday about this topic which quickly overflowed the boundaries of that medium.)* To facilitate development of my Mod-Loader plugin

[twdev] Re: Feature Request: high-priority "bootloader" module-type

Addendum: If startup modules aren't collectively preloaded before they are run, boot modules may be unnecessary. However, this would force a change in the prioritization mechanism (using tiddler fields rather than export variables). I think there might also be a meaningful difference in scope

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hi Evan I worked up the technique I mentioned, and it may be suitable for you. Working in Node.js, create a file called “patchcore.js" in a test wiki with the following content: /*\ title: $:/PatchCore.js type: application/javascript library: yes Demo of patching the core plugin \*/ (function

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Here’s the .tid of the $:/PatchCore.js tiddler, too.Best wishesJeremy -- 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

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hey, Jeremy — So, as mentioned in the OP I'm pretty leery of the "pre-boot" approach here. The modloader process uses quite a lot of $:/boot library functionality to identify and inspect shad

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hi Evan We’ve got to the point where the changes you are proposing to the core are quite deep, and have lots of implications for the rest of the core. It’s going to mean a lot of work on verification and testing from me, even if somebody else writes the code. I don’t think that burden is justif

Re: [twdev] Re: TiddlyWiki 5 Dev Hangout #105 will be on Friday 9th February 2018 at 3pm GMT

Hi Mario * There are 100+ PRs pending ... > - I think about 10 are approved already, but not merged yet, >- IMO several "core devs" could speed that process up a lot. > That is indeed the primary driver for the move from github.com/Jermolene to github.com/TiddlyWiki; as you know, per

Re: [twdev] Feature Request: high-priority "bootloader" module-type

Hi Evan Apologies, the end of my reply got garbled in copy and pasting: >> In most cases, bootloader modules (including modloader) are going to want to >> generate any output to $:/temp or similar, where they won't create >> persistent changes in the wiki. My reply to this paragraph was missin

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hey, Jeremy — > Yes, but your proposed solution is just an escalation in an ongoing arms > race to be the first module to run. This is almost, but not quite, the issue. My modloader *is* the first module to have any method called on it. However, TiddlyWiki currently *loads* (via $tw.modul

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hi Evan Thanks, I’ll give your arguments more thought, and hope you can join the hangout tomorrow to discuss further. > This is almost, but not quite, the issue. My modloader is the first module > to have any method called on it. However, TiddlyWiki currently loads (via > $tw.module.execute)

Re: [twdev] Re: Feature Request: high-priority "bootloader" module-type

Hey, Jeremy — Bootloader modules feel a bit like an admission of defeat with respect to > the startup module mechanism. > Potentially this functionality could be an extension of the startup mechanism. Trouble is, in order to load and execute them one-by-one you'd need to be able to prioritize

[twdev] Re: TiddlyWiki 5 Dev Hangout #105 will be on Friday 9th February 2018 at 3pm GMT

> > Many PR are better off as plugins. > The new Mod-Loader could help, in cases where plugins need to change core functionality. I'm designing this facility to provide an option "in between" core-shadowing and pull requests, as well as easier distribution of branch functionality in the form