---
name: Pull Request
about: Propose a change to TiddlyWiki 5
title: ""
labels: ''
assignees: ''

---
<!-- HOW TO USE: Under each "#### Heading" below, enter information relevant to your pull request.
Leave the headings unless they don't apply to your PR.

Please read carefully and don't delete the comments delimited by "< !--" and "-- >"
Once a pull request is submitted, automatic stylistic and consistency checks will be performed on the PR's changes.
The results of these can be either seen under the "Files changed" section of a PR or in the check's details.

NOTE: Please grant permission for repository maintainers to edit your PR.  It is common for PRs to be held up due to trivial changes being requested and the author being unavailable to make them. -->

## Summary

Category type "Brief description"

<!-- This section should consist of exactly one line, edit the one above.

1. Replace the word "Category" with one of these words: Usability, Widget, Filter, Hackability, Document, Plugin, Server, Performance, Infrastructure, Translation, Accessibility, Theme.
2. Replace the word "type" with one of these words: added, modified, fixed, extended, updated, improved, renamed, removed, hide.
3. Replace the text inside the quotes with a brief description of your changes.
Or if you don't want a changelog entry, replace the whole line with just the word "None" (with no quotes).

This is checked by .github/workflows/pr-validator.yml automatically
For more on the meaning of each category, see:
https://tiddlywiki.com/dev/#Pull%20request%20for%20TiddlyWiki
If approved and merged, your summary will be added to the project release notes:
https://tiddlywiki.com/#Releases

An example:

## Summary

Widget fixed "incorrect behaviour of default values with lookup Operator"

example end.

-->

## Is your PR related to a problem? Please describe

<!-- With a few sentences, describe your reasons for making this change. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...].
If it relates to an existing issue, you can link it with a # followed by the GitHub issue number, like #1234.  If your pull request *fully* resolves an issue, include the word "Fix" or "Fixes" before the issue number, like: Fixes #xxxx
If there is no related issue, explain here what issue, feature, or other concern you are addressing.  If this is a bugfix, include steps to reproduce the original bug, so your fix can be verified. -->

## Describe the solution

<!-- A clear and concise description of the changes you are proposing. Include images to show visual changes. How does the feature work, or how does this fix a bug?  The easier you make your solution to understand, the faster it can get merged.  -->

## Describe alternatives you've considered

<!-- A clear and concise description of any alternative solutions or features you've considered. -->

## Testing

<!-- Describe what steps you took to test that this PR resolved the bug or added the feature, and what tests you performed to make sure it didn't cause any regressions.  Also include testing suggestions for reviewers and maintainers. -->

## Additional context

<!-- Add any other context (such as mock-ups, proof of concepts or screenshots) about the feature or bugfix here.
If you link to discussions elsewhere then please copy and paste the important text, and don't expect readers to scan the entire discussion to find the relevant part.-->

## Checklist before requesting a review

- [ ] Illustrate any visual changes (however minor) with before/after screenshots
- [ ] Self-review of code
- [ ] Documentation updates (for user-visible changes)
- [ ] Tests (for core code changes)
- [ ] Complies with coding style guidelines (for JavaScript code)