Diff-match-patch. Feature Bloat?

#1

I’m working with the later versions of TiddlyWiki, and I’m seeing that there are filters to making and applying patches. These rely on a minified utility module of not-small size.

Every fiber of my being is screaming feature bloat. What was the rationale for adding this as core code? Because it’s not being used in core. I’m not trying to be a wet blanket about this. I’m just really concerned that some features are getting into the core code which should really have been left as a readily-advertised plugin.

I really feel the same way about some of those trigonometry filters too. They seem very esoteric to me, and could have been a “Math” plugin. TiddlyWiki has such a beautiful capability for supporting plugins, but it really seems like it’s not getting used like it should.

Are there serious talks about whether a new feature should go into core, rather than whether it could?

2 Likes
#2

I do think that the diff match patch library is unnecessary for the core, since it doesn’t have much use case in the core (We already have the difftextwidget for comparing, while applying diff files to tiddlers isn’t widely used ). Perhaps making them independent as a plugin and add some more features (like registering text/x-diff as a tiddler type) is better.

For trigonometry filters I think they are acceptable, since they don’t require a third-party library, and implementing it doesn’t require much code.

#3

I think both the dynannotate and the dynaview core plugin need this library as a dependency.

The diff-match-patch library was added 6 years ago, to be able to identify changes with the $:/Import dialogue. It is possible to show the difference between an existing and a new plugin or tiddler.

Also the “preview” dropdown in the tiddler editor uses the library. So we can show differences between a tiddler and a shadow tiddler, if there is one.

image

So the functionality was used by the core for a long time. The new filter operators have been added lately, because there was a lot of hidden and missed opportunities, because the library already was part of the core, but the functions have not been exposed.

#4

The difftext-widget uses the diff-match-patch library. So without the library, there would be no widget.

#5

Maybe AI edit will need it, like Github Copilot’s diff view

图片
图片2302×519 111 KB

or show diff when merging other client’s update.

Well, I think the only meaning of getting into core is providing concensus, so every plugin author follow same API. Surely many feature don’t need such a strong concensus.

1 Like
#6

All right, well, I guess the diff module just slipped me by. I am heartened to see that this diff-match-patch library wasn’t added as a whim, and that it does have serious use cases for the core code itself.

#7

Thanks @Flibbles for bringing this up. Managing the growth of the core is a vital part of the TiddlyWiki development process and is something that we need to keep under continuous review.

In the case of the diff-match-patch library, the original GitHub ticket from February 2018 includes the following comment:

We also need to decide whether this should go into the core, or be refactored as a plugin. I’m inclined to keep it in the core because I believe that the functionality that it offers is both fundamental and universal: every TiddlyWiki user edits tiddlers, and seeing visual differences is a critical aid to understanding those edits. Having said that, this patch adds approximately 30,000 bytes to empty.html, taking it from 2,016,354 to 2,047,137 bytes, so we should be asking the question.

I think both the dynannotate and the dynaview core plugin need this library as a dependency.

Just for the record, neither plugin uses the diff-match-patch library, either directly or via the widget/operator/macro wrappers.

#8

Thanks for showing that it was indeed discussed whether it was necessary or bloat. I guess I should probably do some git-log before opening discussions like this.

#9

“Fundament `& Universe”.

You can’t get much more Core (lest a neutrino or two) than that!

Back on Earth.

Diff-Match-Patch is super useful!

IMO there could productively be useful discussion that exposes that in reality it is less “patch” than “probe my reflexive nethers”.

A bit of the old, pre-AI, super-comparative tool.

1 Like
#10

Even if it was not “fundamental and universal”, I agree in the value of diff-match-patch being in the standard distribution. If someone implements a cross wiki tool then we need to rely on it being present, especialy when using it on read only wikis.

  • Here I choose my words carfully using “standard distribution” instead of the core or empty.

It also seems to be an example of something for which we may include documentation to remove it from the standard distribution, if someone is building a minimal wiki, however this is most likely less and less common.

  • I dont think we have generaly designed for removable componentes, more just additional components.

One example I am keen to build is a way to visit a read only site, make changes, review changes (diff match patch), then bundle and export the changes. The visitor can then email the suggested changes to the wiki owner who can then review and apply the proposed changes/patches.

  • This depends on a resonable level of dif match patch on most wikis

This could be used for large collaborations or to correct simple spelling mistakes.

The main value being read only, single file wikis, would also provide a mechanisium for multi-user collaboration via a moderated procedure.