The problem with "custom solutions"

I feel this thread so hard, lol. My JsonMangler plugin is stuck back in 5.1.23 (? I’d have to check), and while it didn’t get very widely adopted, those who have used it have felt the pain of it not being compatible with the current 5.2.* releases. This is because I chose to literally patch functions in the $:/core during startup, and this is a terribly brittle thing that doesn’t survive a core TW release unless I’m right there to update the patch-tiddlers and do bug testing.


Yes. With so many projects, each with distinct customizations, and widely varying degrees of urgency for keeping up with upgrades to core, I often struggle to track what’s where and why.

One small point to add is that there’s an analogous challenge with edits to plugins. For example, I always hack telmiger’s otherwise-lovely details plugin, and also Shiraz, so that the colors come from palettes rather than being locked into hexademical values. I also always modify Shiraz (as well as the core’s language hint) to remove “Missing” and “empty” messages, so that ViewTemplate elements don’t waste space and attention when they’re not needed. Each time I upgrade a plugin (as well as the core), there’s the slow reconstruction of what needs fixing.

Something that automatically tracks not just WHICH shadow tiddlers have changed, but gives an instant overview of where and how, would be great. Of course, it would be a “best practice” for me to have some consistent flag, across wikis, for such edits. Perhaps I should add a custom “override-explanation” field – the contents of which can be neatly viewed with a Shiraz dynamic table. :wink:


1 Like

It will be interesting have a tool for custom solutions but I see one small and one big doubts/problems.

  • The first is having a source tiddlywiki for create the bundles.
  • The second is how avoid problems when several tiddlers do changes in the same core tiddler or other customizations that “overwrite” the anterior solutions (for example, in CSS)

A great power comes great responsability.

I think that something similar how the filter advancedsearch works and the button to export. Having list/s with checkbox to add tiddler to a temp tiddler. I don’t know if it is better a direct filter search (how @stobots does) or create tabs with custom list, basically they are the same but with different UI concept.

I feel we need some extencions to help us all handle selection in the face of larger lists. demonstrates grouping well but we need to support interactive filtering.

Tiddlywiki has strengths in listing and selection which allows us to push it along way. As a result we do push it along way with large and sophisticated lists and relationships. As a result we hit new barriers to interactive selection and it is there we need to improve the options. Such improvements should be available to all expierence levels.

The <<edit-list>> macro combines features of an <$edit-text> text input widget and a <$select> selection list widget. It operates similar to the combination of HTML <input list="listname"> and <datalist id="listname"> elements, and permits you to enter text or select from a list of pre-defined values that are determined by a specified filter.

The find:... parameter progressively filters the selection list contents as you type into the text input control so that it only lists those items that contain the current input text. You can use it to find an exact match, or find combinations of space-separated keywords

  • Use find:match to show only items that contain the exact text, including whitespace.
  • Use find:or and enter several space-separated keywords to show only items that contain any of the keywords, in any order.
  • Use find:and and enter several space-separated keywords to show only items that contain all of the keywords, in any order.

By default, upper/lower case letters are considered identical for matching purposes. To indicate that upper/lower case letters are to be considered different from each other, use capitalized parameters: find:MATCH, find:OR, or find:AND.

For example, enter the following in the “Try it now” syntax input (at the bottom of the Info tiddler)

<<edit-list tiddler:"TryIt" filter:[all[tiddlers+shadows]tags[]sort[]] find:or show:yes>>

Then, in the Try it now “Result”:

  • Blank input shows all tags on tiddlers or shadows (57 items)
  • “v” shows only items containing the letter “v” (14 matches).
  • “vi” shows only items containing “vi” (7 matches)
  • “vin” shows only items containing “vin” (1 match)
  • “vi ad” shows items containing “vi” or “ad” (12 matches)
  • Changing “find:or” to “find:OR” (i.e., case-sensitive matching) and entering “Vi Ad” shows only 8 matches

There’s LOTS of other optional parameters available with the <<edit-list>> macro, such as support for multiple-selection (multiple:yes) and modal confirmation of input (confirm:yes)


1 Like

Ciao @twMat, my 2 cents …

After thought your post motivated me to look at what I’m doing in maintaining my TW. I realised it was sloppy!

My point? I think your post is very rich. To me it is pointing in two (useful) directions …

  1. Tools to ease handling customisation

  2. Getting your brain & ass in gear to properly track and document what one did

For the single best existing practical approach to address both issues is use of @pmario’s Bundler plugin, I think. I noticed others in this thread use it and promote it. Rightly.

What they don’t say so clearly is how far PMario has gone with it to make it the premiere import/export tool. It deals with near all of the Transportation & Documentation issues that bespoke configurations have.

In brief, the Bundler …

  • Let’s you add comments in the normal Bundles. This is great as the source and the comments go together. It is a minimalist approach. That makes it maintainable.

  • Provides a mechanism via the Info Panel of every bundle to see what is in the package, determine if anything is missing, delete any item.

  • For Filter Bundles, it can also pass the filter to Advanced Search for good integration into normal use.

  • Unlike other import/export options it allows you to transport state tiddlers. That is very helpful when your setup/config uses them.

  • Option to permanently record all imports to an Import Bundle. That allows both tracking of what you did and enables easy archiving of all imports to a JSON output. It is editable.

  • Interestingly, the Bundler and any bespoke settings for it can be bundled into a bundle so you can transport the Bundler along with the other transportees.

Here is an example of a bundle’s contents I have …

Promo over. I will make one more comment, shortly.

Ciao @twMat My swan song to this thread.

Thinking about it over a few days I kinda thought, well @twMat is right, TW is amazingly configurable!
But with that comes complexity of use!

What is the primary solution to managing with that complexity?

Just answering for myself to myself: Get Your Ass In Gear & Record Changes As You Make 'Em!

It is interesting as I do think that as you get further into Bespokeism the need for using TW self-documentation exponentiates.

Practically, for users, it might, longer term, be worth somehow documenting how to document user changes and emphasising its importance.

  • The first rule of TW being: Backup!

  • The second being: Note your Changes!



(if it says there is a deleted post by me on this thread, it’s because i accidentally hit reply on an unfinished version of this post)

I’m not exactly sure how feasible this is, and this is only a possible solution to a small part of this problem, and i’m not entirely sure if there are any problems I couldn’t think of, but has there been any talk about using diffs and patches for modifying shadow tiddlers?

On my failed attempt at trying to prototype this, I found out that TW already bundles and uses diff-match-patch, which should be able to do what I’m proposing.

The idea is that, instead of the edit button on shadow tiddlers (or some other interface) completely copying the contents over, TW (or more likely, a plugin) could extract those edits into a diff, and TW could automatically apply these patches when reading a tiddler (because I don’t think plugins have the hooks necessary to do this yet).

And instead of only making a single patch tiddler, TW could let people create multiple patches that could be applied in a specific order (say, with tags).

And TW could let plugins supply their own patches to other shadow tiddlers (core, other plugins, etc)

Aside from the customization benefit, this method means that customizations could even survive updates, assuming the patched lines (and the few lines around them to provide some context to the patch tool) haven’t been changed.

(The ideal method wouldn’t be “patching text” (what diff-match-patch does, and what I’m proposing right now), but a patch system that’s aware of code works (for example: Mixin, which is used on parts of Minecraft modding) which would allow patches to overlap and modify the same places without major problems, but I am not aware of any tool that can do this on JS, not to mention the extra complexity it might bring.)

As initiators, maintainers and users of FLOSS digital commons come and go, I wonder about the sustainability of such commons. It’s a multifaceted problem regarding governance, learnability, legacy, economy and that would be my main concern on custom solutions. It is not so much regarding the core and plugins approach, which I think is one of the biggest strengths in TW, but what happens in the middle.

For example, we used Nico’s Projectify to create our own mod, ProjectifyMod, which is mainly a curation of extra plugins and added macros. I’m pretty sure TW will be here in the years to come, but Nico has closed the repository for further contributions, left it read only. I imagine we will need to learn and deconstruct Projectify to keep it evolving and customizing. BTW, this informal community spaces for learning are an important resource on making FLOSS commons sustainable. I think that more formal and structurated like @sobjornstad’s Grok TiddlyWiki — Build a deep, lasting understanding of TiddlyWiki written from a more pedagogical perspective are an important addition to TW sustainability. Connecting formal and informal learning resources and practices will be key for that also. And for sure TW newbies and relapsing users like myself :-P, could help by participating more actively and making more questions.

Ps: A deeper concern about the sustainability of digital commons would be related with the economic commons, but that’s another (related) topic for another time. We will launch some TW powered early draft and prototypes on that, hopefully this year. I’ll keep you posted, if that happen.


Perhaps there could be a mechanism for someone closing a GitHub project to hand it to the commons or to at least get a “clone a branch”. This would allow the development to continut in the commons. If licencing permits this can be done as needed.

This is the case of Projectify. It is stored as read only, but it can be forked, cloned and so on. My main concern is about the social dynamics that allow a project to be stewarded in a plural way. I’m not only saying that because of Projectify, but in my own case. We have done a lot of workshops (700+ hours since 2015) but making a digital commons understandable and cared by several is a big concern of a lot of projects. I think that we need to build explicit curriculums and communities of learning around them.


Welcome @Offray and thank you for sharing. I think we’ll have some more discussions about commons of all kinds this year.

Thanks @boris, @jeremyruston and everyone else for your welcoming words.

Boris I’m really glad we have connected over here. I have been enjoying your #ToolsForThought screencast series with Jeremy, Tudor and others, and in fact my introductory post about how we are already connecting both (GT + TW) was “urged” by seeing the your screencasts (but delayed until I was on proper long due vacations). I have some watching annotations that I have done on the series, but I would like to organize them before sharing them with you and the wider TfT community (I take quick notes as “conversations with myself” on Telegram)

On the several commons we need to bridge, one of the main divorces we experience right now is the one between the digital commons and the economic ones. So we try to make the former sustainable in a place where few players use the software commons to create data oligopolies, while extracting value of our day to day interactions. Digital commons are used to erode economical and ecological commons at a pretty worrying pace.

For such bridges between commons, what I call the “Hello World! introduction to informatics” is not good enough (as history has shown so far). We will need critical code/data literacy, that approach technology from a critical perspective and tries to deconstruct some divides that we have thought as “natural”: user/developer; OS / Programming Language / IDE / App / Document, among others. So while de developers are kind of empowered by being able to traverse the divides (while dealing with their incidental complexity), the “end user” just uses apps to create documents (if lucky) or (if not) to do a simple task (ordering a cab or pizza), as predefined by the devs.

That is why TW + Pharo/GT are so promising and empowering and such combination showcases how the most interesting stuff is happening at the margins, away from trendy, shiny “next big things”. Small/Simple is beautiful.

1 Like

My main issue with custom solutions is much more profane - it is css.
Sometimes in TW I encounter classes with poperties which do not really fit my needs.
My special friend here is tc-drop-down which I encounter in the search but also whenever I make a toolbar-dropdown.
The problems I wanted to cure here were divers:

  • The color-palette I prefer did not display well there,
  • It did not display well on smartphone screens,
  • The buttons have 100% width, which is not good for some usecases.

So I did some stylesheets and also inline style-definitions to get what I want.
Sometimes these custom styles sometimes stab me in the back.
Debugging why some class under certain conditions behaves strange has become so painfull that I often cure it with another short-sighted trick.
I would be happy if I knew a way out of my custom dead ends here…


Two months after… here a basic solution to do portable the customization.Customization Packer.json (4.7 KB)

To add a tiddler use the button (+), then the button change to (x) and color link also do it to indicate that this tiddler is selected. To remove a tiddler from the list to import use the button (x). In the blue bar (in de vanilla theme) there is a button to import the list of tiddlers, it will be disable while the list was empty.


Just to be on the right page here…

This ‘bundler’ plugin is the only way to save advanced search filter presets?

Can’t it just be sourced from some tiddlers? By perhaps overriding some shadow things?

Needing a plugin for that feels a bit like going past the ‘everything is a file/tiddler’ thing I thought was the core of this.

Guess some things that look like tiddlers have to be plugins…hmm.

I just want to save some filters, lol.

@Damnit take a look at this post

That works! Thanks a bunch. It also creates tiddlers that can be searched and edited, which is pretty sweet.

This shadow stuff is a bit awkward sometimes, but I suppose it does more good than harm. (it’s great to have it hidden until its not…)

Having templates and in depth typed documentation of the requirements and formatting guidelines for this might be a good way to future-proof plugins made for custom use. (Seems like a normal tiddlywiki kinda thing to me haha)

If we had a place to, users submitting their modifications to be peer approved and then officially approved could allow for other uses to have options to pick from in the plugins modal (maybe a community tab?), but for smaller, more niche use-cases, like generic buttons that do specific actions, or small stylesheets, etc.

Having an internal mechanism to record changes made to the TW would be a nice help not only in cases like this but also in telling you what changes you’ve done to get your TW to the point where you like it.

I end up doing this manually within Changelog tiddlers using @Mohammad 's KARA interstitial journal macro, as it timestampes each entry (with some modifications, of course, as I always do haha)

Going to be honest here, I’ve seen this a few times and never knew that’s what that stood for, I like the concept. think I might consider something like that, I’m thinking TUNA (TiddlyWiki Utilities, Notes, and Accessories), thank you for the inspiration :grin:

Ditto. I usually keep my tiddlers unpackaged, pushing changes when they have been made to plugins is just a bit too time consuming for me to justify it.

I find using CSS to make it scrollable helps with long dropdowns

Ah, similar to (I know, this is an odd assosiation) YouTube keywording in video descriptions.

Sorry in advance for the long body of text, I like talkin’ 'bout tiddlywiki things :sweat_smile:

1 Like

Yes. Go with this idea :fish:

1 Like