This is what it output. It didn’t complete the task such that umami_dashi_wiki.htlm actually worked with the images and tiddlers.json
Any ideas on what I would put in a prompt to create a node.js version which would be able to read folders of .tid files ?
I’d like the back-ends for getting at the OS to be configurable per machine that I might sit down at with a relatively simple way to configure them.
For example I have previously wittered on about email Message-Id URLs which should of course follow the standard. One could use the OS’s handler which in turn goes to Mail.app or Thunderbird. Or fall back to gmail.com on somebody else’s computer.
Then there’s opening files and directories.
Perhaps I’ll have a macro in my notes that refers to <<source_file file:“project_A/create_problems.c” line:“389”>> and I’d have my back-ends translate that to a Windows UNC path on my Windows machine, an automounted UNIXy path on UNIXy (inc. MacOS) machines and some URL on anything else (following the gmail above) .
Something I have experimented with recently is having the EDITOR environment run a script that fires the file spec through a reverse SSH TCP tunnel to my client machine’s editor (well emacsclient). That allows me to run for example cscope efficiently on the server. But I could also imagine an http request to my server hosting the wiki using some mechanism to make my local editor (or Finder or file explorer) do something.
TiddlyWiki and I have had quite a history together. I first started experimenting with TiddlyWiki with classic trying to start a Getting Things Done system and later as a game engine through Twine. But once I discovered what TiddlyWiki was at its core I found that it was the perfect tool to dumb brain ideas into. Anytime I found or thought of a tip, trick, idea, or link I didn’t have to worry where I should store that. Unlink a raw file system where I had to worry about what directory to organize it into or how to manage separate files that are actually related (linked). Searching would need a structured data system. Presentation would need some kind of build system. Web ages needed a server. None of that worked will in the sneaker net that I used to be stuck in long ago.
Like most systems my GTD setup floundered and my use of TW faded. But I revived later when I needed a working static website generator and I knew a normal blog was too much structure for me to keep going. Instead I needed a dumping ground of random stuff big and small that I could have generated to a basic personal home page. TW came to my rescue now at version 5.
The more I used it the more I discovered how flexible it was and how useful it was to have a single HTML file I can place anywhere/anytime. I started using TW for all kinds of things like Minecraft Tutorials and Résumés (CVs). I learned just how many features come built-in from the core modules. And anything that wasn’t in the core modules I could add myself. I started using TW as a base framework to add my own features including image processing build tasks.
Eventually I needed a way to track my daily habits at work. The field I work in needs strict approval for installing applications. It is close to (but not really) air-gapped. I thought TW was perfect for this kind of situation since it just an HTML file running in the browser. Then since we use Node for our development build tools it was not a hard jump to vet the source and run TW under Node. Now with a localhost server I can pin a tab in my browser and have a daily brain dump wiki with daily journalling.
For whatever reason, this has been the only tool I’ve ever tried that has remained in daily use for six years now.
It is for these reasons I find TW to be invaluable for me. I hope these core ideas remain.
Right.
That way would ensure security AND freedom. An opt-in backend connection.
I fear on browsers now it would still be very difficult.
One way around it would be to run a daemon in the background that could detect any file written to disk by a TW.
So … In TW have an action to save a batch command file (I.e. a “command tiddler”) to disk that a daemon can detect and execute.
Not ideal, but still workable atm.
TT
Yes. A beautiful one.
Thank you to everyone for the thoughtful and interesting feedback. I have now posted a longer thread about v5.4.0, but do feel free to continue to post here.
I may not be able to envisage the scope of your aspiration but as a single file TW user who is highly dependent on TW on my tablet, phone and laptop I very much appreciate the current role of the browser.
On my android phones I use Tiddloid and on my Unix laptop I use Tiddly desktop, I have a small keyboard for my tablet which means I can work when I am in transit. I use TW as my central knowledge base which is large and the product of hours of work every day for a number of years.
For me the browser is rarely a fundamental limitation and a lot of problems have a manual work around - what it delivers in return is that the browser is my access to TW on any device, its like a passport that means I float above the OS problems, all in return for very little inconvenience.
There are device issues for sure, for example on Android I need to access my TW on a device local server because of the way the Android security and filing system limits the ability of a browser to access locally stored videos and so on.
In terms of liberating people on different machines and platforms, in principle it might be a great thing, one of the reasons I am on Linux is because I could not tolerate Microsoft updating my machine when ever they felt like it - they always messed up my custom device drivers and thought they knew my needs better than I did and I have already mentioned a limitation of Android and of course there is Apple - the pinnacle of user tie in or coercion depending on your point of view. Against this viewpoint many users out there don’t want to understand their machine or software they just want something that works most of the time (Apple?) - as a linux user I sometimes forget all the fears about viruses and so on. I think a truly open system would have to come up with some new ideas about security balancing open-ness with safety - not an easy balance.
I think that is right.
Part of the issue is that back-end-geeks, informed users etc. can perfectly well understand the potential issues and address them.
Meanwhile the “let me only do anything safe but stop me otherwise” is the standard browsers’ norm.
There are good reasons both ways!
But, I do think a v. good case can be made to get round browser limits In Cases where the user needs interact with calls to the O/S.
A simple example would be “invoke a local search of all my docs mentioning ‘Ruston’ and build an external tiddler listing them.”
Implementations such as Tiddlydesktop, tiddlywiki-app do this by using a custom (Chrome) browser and do give you access to local resources. Also the antequated and limited hta method.
Wouldn’t it be great if instead of making custom browsers it were possible to configure regular ones to allow certain pages to interact with operating systems in the ways we want.
Could browser producers (roughly MS, Google and Mozilla) be convinced this would be good or can plugins achieve it including for mobile devices ?
Chrome and Edge (desktop) did implement a native file-api lately. There even is a TW plugin which is a bit clunky to use for security reasons.
Safari and Mozilla did not implement it (probably) for security reasons. They are not even considering it atm.
I think none of the mobile browsers will ever implement it, since mobile phones do not really have a file-system. They have storage, which is heavily sandboxed, for obvious reasons.
-m
PS: I think we should give our TW browser-storage plugin a bit more love, since it works out of the box on all browsers.
There actually is a proper filesystem on both iOS and Android, it’s just not exposed to users very often. That said, I’m also skeptical at this point that the File System Access API will move beyond Google Chrome Desktop.
Right. I use Chromebook. It’s whole thing/k is wooden.
To the point here: HOW, practically, can we legitimately get TW to act beyond The Standard Browser?
I keep meaning to comment here, but I’ve never had much to say. But I wanted to share what I just sent to a co-worker:
There is something very uplifting about being involved in a project—TiddlyWiki—which has recently started planning for its next major version release… in 2036. TW5 was released in 2011, with the tag line "a reboot of TiddlyWiki for the next 25 years. Since then, there have been three point releases with only minor backward incompatibilities. We’re about to release
5.3.7and are planning5.4.0now, but we’re also starting the6.0discussions, for when backward compatibility can be deemphasized.I don’t have a conceptual problem with Agile development (although corporate Agile is mostly an oxymoron), but it feels great to be thinking on such timescales.
Thank you @jeremyruston and everyone for a wonderful tool and an amazing community!
Oh but you’re wrong, Scott. You should apologize to your co-worker for that terrible mistake, forthwith.
Corporate Agile is an oxymoron.
There. I feel much better now. 
You’re absolutely right. Apology sent.
I use something like this in the sidebar for editing, with a button to detach. Type or paste the tiddler title and the markup appears. A major time-saver for me, now I only use the regular editor for tags and fields. Very simple though—no toolbar & bypasses the “Draft of” state.
In a tiddler titled “Edit Tiddler” tagged $:/tags/SideBarSegment, positioned just below $:/core/ui/SideBarSegments/site-subtitle:
<style> .wide1 { width: 100%; } </style>
<details>
<summary>''Edit Tiddler''
<$button class="tc-btn-invisible">
<$action-sendmessage
$message="tm-open-window"
template="Edit Tiddler"
windowTitle="Edit Tiddler"
width="500"
height="645" />
<span>{{$:/core/images/open-window}}</span>
</$button>
</summary>
<p>''Tiddler Title''</p>
<p><$edit-text tiddler="Edit Tiddler" field="TiddlerTitle" size="35" /></p>
<p>''Tiddler Body''</p>
<p><$edit-text tiddler={{Edit Tiddler!!TiddlerTitle}} class="wide1" /></p>
</details>
But experimenting with the contenteditable attribute in TW was very cool, made me really wish I had the ability to edit directly as well.