I made and quickly deleted a post asking about using a prefix ore template for tiddler naming.
I found the answer in the tiddlymarks options page. You can construct the fields as you wish in the Formatting section. Here is an example of using a system tiddler for the bookmark tiddler: [image: 2020-10-15_195926.png] On Monday, June 8, 2020 at 2:57:24 AM UTC-4 Yestin Harrison wrote: > Well, 0.3.0 is live on AMO. Besides fixing a rather nasty bug that > rendered the popup inoperable under certain circumstances, I took it > as an opportunity to make the download dialog opt-in (default off), > and add an explanatory label to the server URL. > > As far as large features are concerned, there's one primary issue – > there are rather strict requirements on what execution context can > trigger the popup. This is ostensibly to protect users from surprising > behaviour, but the long and of it is that as soon as I await something > (such as making sure a tab is opened and then loaded, as would be the > case for a context menu item to bookmark a link), I no longer have the > ability to bring up the popup. That is to say, anything that depends > on a resource that is not the current tab would have to either > unconditionally run in “quick mode” with no ability for the user to > edit anything, or instantiate some different mechanism within the page > (i.e. port the popup to instantiate in a content script). > > The latter would work with some effort, but it has the unfortunate > property that it would all be for *just* links. The lovely thing about > the context menu API is that among its supported contexts are native > browser bookmarks, which would be *incredibly* convenient for porting > over existing bookmarks. Frustratingly enough, though, doing anything > meaningful with those is just out of reach. With no corresponding page > context to run in, and no way to signal anything important before > bringing up the popup in a manner programmatically indistinguishable > from an ordinary click on the extension button (!), it would have no > way of presenting any user interface. > > I've already had to hack around this strict behaviour to get the popup > to be whatsoever conditional, but I believe that's the most I can do > there. If there are any JS gurus reading who know some reason what I > wrote might be wrong, please do let me know – I'd love to implement > something like this if the extension APIs allowed me to. > > With the disappointing technical bits out of the way, some good news: > page previews are actually incredibly easy to get from the tabs API, > so some form of support for that would be doable. I'm mulling over > ways to make favicon formatting more customisable. One potential > solution is to just expose a snapshot of the whole tab data structure > to both formatting functions and throw the user a link to MDN if they > want to mess around. Another is to split the favicon title into its > own formatting function, and evaluate it at slightly different points > than where the current two are, so it could be intercepted when the > popup is brought up. > > Either way, the addon is in quite a healthy state at the moment, and > should get even handier and more flexible very soon. > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" 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/tiddlywiki/2dd8c6ef-3ab5-428a-94bc-9106b7e3e1e2n%40googlegroups.com.
