* Fix encodebase64 and decodebase64 filters
The documentation for encodebase64 says that the input is treated as
binary data, but in fact the input is being treated as text data, with
an extra UTF-8 encoding step being performed first.
Likewise, the decodebase64 documentation says that it outputs binary
data, but in fact it will do a UTF-8 decoding step before producing
output, which will in fact garble binary data.
This commit changes the behavior of encodebase64 and decodebase64 to
match what the documentation says they do. It also adds an optional
`text` suffix to both filters to keep the current behavior.
Finally, an optional `urlsafe` suffix is added to both filters to allow
them to use the "URL-safe" variant of base64 (using `-` instead of `+`
and `_` instead of `/`).
* Try to fix failing test
Turns out a little more than this is going to be needed.
* Fix binary base64 encoding, including unit tests
* Update base64 filter documentation
* Can't use replaceAll, too new
Have to use String.replace with a global regex instead
* Replace uses of window.btoa() in rest of code
Since window.btoa() is not available under Node.js, we'll replace all
uses of it with the $tw.utils.base64encode() function that now works
correctly for binary data.
* Add link to UTF-8 glossary definition at MDN
* make toolbar, editor and preview display: grid
* correct display of bitmap editor
* grid-area: toolbar not only when preview is shown
* use dedicated classes and tc-grid and no brittle CSS selectors
* no need for width: 100%
* cleanup style definitions
* use semantic classnames
* Passing test
* Failing test
* Fix test
It still fails, but now fails correctly
* Fix refreshing transcluded functions (#7755)
We store the previous result of the filter function and recalculate it
when the transclude widget needs to be refreshed, refreshing the widget
if the result is different.
---------
Co-authored-by: Jeremy Ruston <174761+Jermolene@users.noreply.github.com>
Co-authored-by: Robin Munn <rmunn@pobox.com>
* Initial Commit
* Update docs
* Add support for elseif blocks
* Another test
* WIP
* Change from `{%if%}` to `<%if%>`
See discussion here - https://talk.tiddlywiki.org/t/proposed-if-widget/7882/64
* Don't use the widget body as the template if a list-empty widget is present
See discussion here - https://github.com/Jermolene/TiddlyWiki5/pull/7710#issuecomment-1717193296
* List widget should search recursively for list-template and list-empty
* Allow block mode content within an if/then/else clause
* Update docs
* Add from-version tag to docs
Both flexbox and grid layouts need the container div to be the direct
parent of the children it lays out. To enable that, we need a class that
can select the direct parent of the list widget in PageTemplate.tid so
that that class can have `display: flex` or `display: grid` applied to
it. The `tc-page-container` div is not suitable, because it contains
a `<$dropzone>` inside it, and the dropzone widget creates a div so
tc-page-container is no longer the direct parent of the list. Instead,
a tc-page-container-inner class is added to the dropzone widget in
addition to its existing tc-dropzone class, so that grid or flexbox
layouts can target tc-page-container-inner for setting the appropriate
CSS `display` property.
* Add failing test for list widget with counter-last
The failing test appends a value to a list without changing the rest of
the list, and the counter-last value doesn't get updated correctly when
that happens. Also added another test, which passes, testing removing
the last item of the list, just in case of a regression.
* Improve unit tests for counter-last list widget bug
The unit tests were looking very similar to each other, so I factored
out the common code and made them into simple data-driven tests.
* Fix bug where counter-last fails in list widget
The only scenario that was failing was when counter-last was used, but
the list was strictly appended to with no other changes made. The one
unit test that was failing now passes with this fix.
* Improve bugfix to list widget counter-last
Now we only refresh the last item if it was truly necessary.
The `all` filter operator has shortcuts to optimise common patterns like
`[all[shadows+tiddlers]]` or `[all[tiddlers]]`. In those cases, the
filter operator function returns early and never uses the `result`
linked list that was created, so it's immediately garbage-collected.
Let's delay creating it until we know it's actually going to be used.
If we don't delete the typeInputTiddler with the click on the "delete" button then the dropdown stays filtered - but the text input seems to be empty. This PR corrects this behavior
* Refactor parse mode out of getTransclusionTarget
* Refactor missing transclusion target
* Add a test to avoid regressions on the handling of macros vs procedures
* Refactor condition logic
* Preparing to split getTransclusionTarget into two separate functions
* Split getTransclusionTarget into getTransclusionTargetIncludingParseTreeNodes
* Resolve another inefficiency
The transclusion target was sometimes being parsed twice when transcluding as text/plain
Associated test results are also made more consistent
* Simplify method naming
* Neatening up
* fix drag and drop from chrome-like browsers to FireFox
* test feature matchMedia function
* implement new borwser sniffing functions as utilities
* use $tw.browser structure for isMobileChrome detection
With a demo courtesy of https://random.dog/
@rmunn you recently worked on the base64 utilities. I tried to use $tw.utils.base64Encode instead of window.btoa, but found that it didn't work. It's concerning because we expose that utility method as a filter operation, and it would be frustrating if we were not base64encoding things properly.
1. Update comments
2. Refactor use of parseTreeNodes so that they are not referenced unnecessarily
3. getTransclusionTarget doesn't need to return the parser object
* Added failing test for #7604
* Fix attribute substitution regexp
Use the same regexp in wiki.getSubstitutedText as is used in
Widget.prototype.substituteVariableReferences. Fixes#7604.
* Added a test for a variable name containing spaces
Previously, the implicit sort ordering of modules ensured that the "plugins" startup module ran before the "startup" startup module. That no longer holds when experimenting with alternate stores that might use a subtly different collation order (eg $:/core/modules/startup.js vs. $:/core/modules/startup/commands.js), so it's more robust to explicitly specify the dependency
