I suspect you may not have noticed my CodeMirror note above, since it hasn’t gotten any engagement at all.
The incompatibility seems to revolve mostly around codemirror-6… But in the process of troubleshooting, I want to raise a GENERAL concern:
IF a plugin includes a shadow that replaces part of the core, such as $:/core/ui/EditTemplate/body/default … surely this should NOT happen without a clear breadcrumb trail. Both my (older) version of codemirror-6 and the @BurningTreeC resizer plugin had shadows trying to override this same core tiddler — and it was hard to tell which was active!
(It’s true that the “override shadow” warning text $:/language/EditTemplate/Shadow/Warning normally appears at the top of the edit window to indicate This is a shadow tiddler. Any changes you make will override the default version from the plugin... … This banner at the top of edit-mode window would have been helpful, but it was getting bypassed because codemirror and/or some other plugins had disrupted (wait for it…) the default edit template cascade )
When plugins override tiddlers in the core (or at least ones whose alteration might foreseeably disrupt a wiki), should they include a standard FIELD in that tiddler that identifies the source of this shadow, including a link to the plugin tiddler? (Maybe there’s some other metadata that we could have best practices about, for pivotal core-displacing tiddlers in a distributed plugin — such as “designed/tested for core v5.x.x through 5.x.x”.)
ANYWAY, back to Codemirror – Resizer conflict: Even on a stripped-down site, most recent TW, most recent version of plugins (where codemirror-6 v3.9.2 now no longer seems to be simply overriding that core shadow in parallel to the @BurningTreeC overwrite), I still see weird behavior (different versions of weird that seem to morph before I can reproduce them neatly — but none of them good). At the very least, it’s nearly impossible to get edit and preview to appear simultaneously (and edit pane was buggy the one time I was able to get it to draw to left of preview pane).
It’s probably inevitable that sometimes one plugin is ineffective in the presence of another. But someone who naively installs them together surely should not find that normal aspects of TiddlyWiki interface no longer work. So I hope one or both can be modified so that this risk is mitigated (and/or one or both need a warning about the incompatibility).
Sorry for not replying to that note. I’ll reply now.
Yes, my Codemirror 6 plugin overrides the $:/core/ui/EditTemplate/body/default tiddler and because @oeyoews cloned my plugin also his version does so.
Edit: I’ve seen that @oeyoews version does not override the $:/core/ui/EditTemplate/body/default tiddler. Something else must be going on
What I can do is adding a how to for these plugins.
I understand why you put time into this.
Thanks for pointing these problems out.
I’ll think about it and try coming up with a solution
I’ve found the problem of the CodeMirror 6 editor.
In its Stylesheet $:/plugins/oeyoews/tiddlywiki-codemirror-6/styles it sets grid-template-columns: ... !important; which should be removed or just remove the !important that will do the trick, too.
This important overrides the resizer styles and makes the editor unusable.
I just looked at your demo site again, and something that struck me, is that resizing images makes navigating and reviewing images really easy.
However I found myself trying to grab the intersection of two resize bars to enlarge an image. Of course it did not work, and I expect this would not be easy to implement. I just thought I would mention it if you had an idea how to implement it.
This in no way diminishes what you have presented, thanks.
It would be nice, if the code $:/plugins/BTC/resizer/procedures/panels and others, where possible have code-body: yes so the code can be read without opening it in edit mode.
With the list-before field containing $:/core/ui/EditTemplate/body/default
Your new edit Template Body will now be resolved and the core one ($:/core/ui/EditTemplate/body/default) will never be used. However anyone curious can look in the cascade and see this is happening.
$:/core/ui/PageTemplate/sidebar is another story.
You may still need to modify the core tiddler, but instead just remove its tag $:/tags/PageTemplate and tag your replacement tiddler $:/core/ui/PageTemplate/sidebar now with $:/tags/PageTemplate.
A quick experiment suggests the order of items with the $:/tags/PageTemplate tag is not importiant. Perhaps because they are positioned with CSS.
Now your side bar does not overwite a core tiddler someone looking at $:/core/ui/PageTemplate/sidebar will see all thats changed is you removed the tag.
You may wish to annotate your own tiddler with replaces $:/core/ui/PageTemplate/sidebar to permit $:/plugins/BTC/resizer to operate.
You may be able to design resizer differently so you just add your additional element via tagging with $:/tags/PageTemplate and not edit $:/core/ui/PageTemplate/sidebar at all (but here is where my skills are sketchy).
I’ve now followed your steps and the plugin doesn’t overwrite the core body/default Template anymore.
For the sidebar I’ll have to think about a solution.
I just got the idea to put the sidebar resizer into its own page template, maybe that works
Will that mean new page template means you need to switch layouts?
This is one of those areas where we could look to introducing some more hackability to the core, unfortunatly for me I dont know enough hardcore HTML/CSS to do this.
I would have thought we could add an element via $:/tags/PageTemplate but this may not be true.
No, not a different layout, just a new Tiddler tagged with $:/tags/PageTemplate that contains the resizer…
But that would make it far more complex to realize and wouldn’t be that smooth
)
