The current implementation is still broken, and actually more broken than it was before a37d50166f.
It seems that we should be exposing the SSE events to the syncer so that the resulting updates can be handled by the syncers existing task scheduler
* refactor: use files to add prefix
* fix: always use $tw.sjcl
* refactor: move sjcl to lib/sjcl
* fix: require sjcl in lib/
* refactor: move sjcl.js back into /boot
* Introduced preliminary idea for infinite recurse exception
* Better handling of infinite recursion
But it could be better still...
* the TransclusionError is a proper error
Moved the magic number to be on the error's class. Not sure if that's
a great idea.
* Fixed minor minor issue that came up in conflict
The minor fix to the jasmine regexp that escaped a '+' somehow
broke some random test.
* Initial Commit
* Fix plugin library URL
* Need to set plugin library location for prerelease
* Styling tweaks
* Docs
* Add tests that the core plugins all have a valid stability field
* Update chinese language files
* Add chinese translations for the new `<$testcase>` widget
* Update chinese language files
* Add chinese translations for the new <$testcase> widget
* Initial Commit
* Add note to preview build
* Fix whitespace and indenting
Thanks @pmario
* Fix crash with unset $tiddler attribute on <$data> widget
Thanks @CodaCodr
* Don't duplicate "description" field in test cases
* Use different background colours for nested testcase widgets
* Extend the testcase widget to run tests
* Add testcases to control panel
* Add a view template body template to render testcase tiddlers
* Test edition should display testcases
* Whitespace fixes
* Make testcase tiddler tempalte link to itself
* Styling tweaks
* Docs improvements
* Styling tweaks
* Run the new tw5.com testcases in the test edition
* Update data widget to display its content in JSON
* Add testcase convenience procedure
* Clearer testcases for data widget, and docs tweaks
* Don't expect our intentionally failing test to pass
* Extend testcase default template so that the display format can be chosen
It is selected by setting the variable "displayFormat"
* DataWidget docs typo
* Fix data widget not refreshing
* Links in testcase output switch to the tab containing that tiddler
Thanks to @btheado for the suggestion
* Docs update for 648855e8a5
* Wording tweak
* Add support for narrative tiddlers in test cases
* Documentation improvements
* Cleanup comments
* Remove obsolete code comments
* Simplify template
* Docs update
* Rename $:/core/ui/testcases/DefaultTemplate/SourceTabs from $:/core/ui/testcases/DefaultTemplate/Source
* Use the view template body for failing tests
* Don't reference the geospatial plugin
* "Test case" should be two words
* Fix handling of currentTiddler variable
Fixes problem reported by @btheado in https://github.com/Jermolene/TiddlyWiki5/pull/7817#issuecomment-2103704468
* Prepare for merging
* fix parsing error with spaces before reEndString, update docs to clarify block mode inside block quotes.
* additional advanced example
* oops, convert spaces back to tabs.
* reset indentation
* final tabs
* missed some
* wikitext classes are appended to other leading wikitext, no need to skip whitespace here.
* Make month and weekday names lowercase
* Replace AM and PM with Polish words
* Adhere to recommendations wrt short weekday names
https://sjp.pwn.pl/poradnia/haslo/dni-tygodnia-i-inne-roznosci;1788.html
* Fix a typo
* Inflect month names
I assume they're always used as part of the full date,
and in this case months are always inflected in Polish.
* Use roman numerals in place of short month names
I could not find any actual use of short month names in Polish.
The only mentions are from people trying to translate English
conventions into Polish - typically in software.
In https://sjp.pwn.pl/poradnia/haslo/dni-tygodnia-i-inne-roznosci;1788.html
Mr. Bańko answered (translation mine):
Abbreviations of month names are less common, numbers are used instead.
Such abbreviations can be created [...]. However, one must take into account
that the reader will not understand them.
I decided to go with a convention that's in actual use, rather than to
force an English convention which is alien to non-software dev Poles.
APIs especially use 2XX response codes outside of 200, 201, 204 for responding to responses. Treat all "Successful" response codes (i.e. anything between 200-299) as successes, and pass the responseText.
We create a system bag to contain each plugin/theme/language. It seems wasteful because it results in lots of bags, but the semantics are exactly right and so it seems like the right approach
