Tiddlywiki and VS Code?

Developers
#22

Hi @nolan great to see your progress on this. One feature I’d be interested in exploring is ways to have the TiddlyWiki instance respond to the context of the user in VSCode.

For example, if the focus is in a particular source file, the pathname of the file would be passed to TW via a magic tiddler $:/vscode/context/pathname which can be used to dynamically display documentation relating to that particular file. It may be possible to do it a the function/method level, depending on how much information one gets from VSCode.

As an option that would require some work on the TW side, I often think it would be useful to be able to scatter documentation tiddlers within the same folders as the JS/CSS/HTML modules/tiddlers that they document. As a simple example, readme.tid might be taken as the documentation tiddler for a source folder.

Taken together, those two features could make quite a nice general purpose documentation suite.

Yet another feature I’d love to see would be to able to click a button in the TW to execute a particular command in one of the terminal windows (opening it if required). That way I could use TW as a sort of dashboard for commonly used commands.

1 Like
#23

@jeremyruston … The VSCode plugin needs an SVG icon. Which one should we use there?

May be the blue favicon as an SVG? … If it’s part of the VSCode sidebar UIs, it will be greyed out. So some experimenting will be needed.

#24

Interesting ideas. They sound great, but my hope was that I could create something part design doc, part issue tracker, and save/manage the whole thing alongside my code. I don’t see myself using these interactive documentation features, and lots of them would require deep work in TiddlyWiki itself which I’m still learning.

I am, however, willing to figure out if or how the extension might support other extensions via some sort of API. It’s not hard to communicate to and from extension-hosted WebViews, so in theory it should be possible for this extension to manage the WebView while exposing APIs for other literate documentation extensions. I’m also willing to give commit rights to anyone who might be interested in doing this work in the context of this extension, as long as they’re willing to maintain it. I only ask that folks not lose sight of my intent to keep supporting the simper use case of just letting folks spin up wikis in their projects when they’d rather not use more complicated/less accessible project planning tools. :slight_smile:

As an aside, wouldn’t this magic tiddler approach change the wiki every time a file is visited? Seems like that’d create lots of git churn for folks like me just wanting to update the wiki when designs change or tasks are updated. Or is there some way to expose tiddlers internally without modifying the HTML document? If so, I’d consider at least adding APIs to push tiddlers into the wiki. Some sort of query API might be nice too, now that I think of it. With that I could design game entities as tiddlers, render their properties to tables to check out balance issues, then have VS Code query those tiddlers and write their properties to JSON which my game engine could load. Hmm.

#25

TW uses the $:/core/save/all template tiddler to save the wiki. It contains a filter, which excludes every system-tiddler which is prefixed with $:/temp/ … So if this prefix will be used, there won’t be any changes to the html file itself.

#26

hihi, … That happens once you start getting feedback. I hope I’ll have some time soon, to create a nice icon :wink:

#27

Yes indeed, I think you’ve arrived at a solid MVP, with nicely tight scope and clear vision. I’d be hoping to use it as a base to explore the other features I mentioned. I didn’t mean to imply that I was expecting you to implement those ideas.

A plugin architecture would be terrific.

Down the road, there may also be scope to share code and protocols with TiddlyDesktop, which is also based on Chromium but was developed before WebView was available, and so currently uses a special type of iframe to host the wikis…

As @pmario points out, we have the $:/temp/ namespace for ephemeral tiddlers that shouldn’t be retained during a save. There are other approaches: the core has support for executing action tiddlers by tag, so we could define a $:/tags/VSCode/ScopeChange tag that indicates tiddlers containing actions strings that should be executed whenever the VSCode scope changes.

Great idea.

#28

Interesting ideas.

Apparently extensions can export and access other extensions’ APIs. I’m certainly open to working with anyone wanting such an API, but for now I don’t know enough about either TiddlyWiki or VS Code extensions to figure out how such a thing should look and what would make sense.

One additional hurdle I hit today: is there some way to intercept and change how reloads are handled? I suspect the WebView doesn’t like its content asking that it be reloaded. The saver seems to be working, so what I think I need is for the wiki to request a reload so I can populate the view’s content with whatever’s on disk. I guess it can then reload and fail. Is this what I want? https://tiddlywiki.com/static/WidgetMessage%3A%20tm-browser-refresh.html If so, how would I catch it in a context where I can run JavaScript?

Also, for anyone who can see what’s going on, is the default panel size very small? I get a tiny edit area in my setup, which doesn’t make sense given my screen size. Not sure if I need to specify a different panel size or location, or if something is just odd with my setup.

Thanks everyone.

#29

On the first start, the wik is opened in the left sidebar area, that is used by the file tree panel. So usually it is the same size as the file tree, which is small.

With my settings it uses about 20% of the screen width and 80% is the text editing area.

Since the wiki is “just” an other panel, I did split the text editor and moved the wiki panel to the right of the text editor. So I have file-tree, text editor 40% and wiki panel 40%

I think in VSCode I also use a UI zoom level of 1. So everything is a bit bigger then normal. Which in turn makes the text of the wiki bigger as the text in the text editor. – That’s strange.

That’s why I did change the font-size and line-height settings in the TW config tab. So it fits the font-sizes in the VSCode text editor.

The problem with those settings seems to be, that they are not saved. … I’ll have to investigate that. …

#30

There are some more things that can be improved with the TW UI as a VSCode panel. eg: the TW story river has a left and a right gap, which is empty space.

With a custom theme, it would be possible to use the 40% space more efficiently. The sidebar could be hidden by default and a top menu could be implemented instead. …

I think a slimmed down UI may also be an advantage for screen readers. But I don’t have any experience with accessibility improvements.

So it’s good to have you on board!

#31

Thanks for the feedback. V0.0.3 moves the wiki view container out of the activity bar and into a separate panel alongside where the terminal and other larger elements live. It doesn’t matter to me where it goes–I put it where it initially made sense to me–but it now seems to use more space by default. If this current location doesn’t make sense then I can revert it. I don’t seem to have control over how these containers are sized, and while I know they can be resized manually, I want them to have sensible defaults.

#32

It took me some tweaking, till I found out how to reset to the initial location. … It’s right-click the “icon” and select the “Reset Location” option. The next time the wiki will be shown it will use the default location panel you defined. … It seems to be a sensible position. There is more space to start with and it’s easy to expand it to use full height. … So it looks good to me.

If you manually change the location, VSCode remembers it.

#33

I think that’s the case now. If a user ever used a terminal and did resize the height, VSCode will remember that setting anyway. So if the terminal was OK, the wiki should be OK too.

#34

Oooh, nice work. Can’t wait to try it.

#35

There Release v0.0.3+5.1.22 · ndarilek/vscode-tiddlywiki-integration · GitHub is a packaged version of the extension. If you download it, you can install it with

code --install-extension <file-name>

CTRL-ALT-W should start it in VSCode

#36

Some help with an icon would be appreciated.

#37

What are the requirements for the icon?

#38

In the package.json file, there are some links, but the icons are missing atm.

May be we will be good with the same format we use for our UI icons. So SVG-paths with some fill color definitions. … I couldn’t find anything in the VSCode docs yet.

#39

Here Publishing Extensions | Visual Studio Code Extension API it says: no SVG … So we may need transparent PNGs. with 256 x 256 px minimum. I saw the 256 number somewhere in the docs, but don’t know where

#40

That’s interesting too: vscode-extension-samples/product-icon-theme-sample at main · microsoft/vscode-extension-samples · GitHub … So SVGs should be possible … confusing