This fixes a problem introduced in
c7b31b0242.
The changes by @tobibeer inadvertently made the regular expression
evaluation significantly more expensive because of lookahead. The is
less elegant but reverts the performance problem.
* return all wikiparserrules w/o operand
* simpler layout & code / updated instruction details
Also wanted to link each rule to the official docs using a dictionary at
`$:/language/Docs/ParserRules/`. However, without #2194 this is not
doable.
This commit permits language plugins to carry the field
“text-direction” with the value “rtl” to trigger right-to-left layout
of the entire page. We also adjust the sidebar layout to work in RTL
mode.
There are still a number of problems to be addressed:
* Brackets and other punctuation incorrectly placed within en-GB UI text
* System tiddler titles are rendered semi-back-to-front (eg
`languages/ca-ES/:$`)
Starting to address #1845 and the discussion in #2523.
We were using `String.prototype.replace()` without addressing the
wrinkle that dollar signs in the replacement string have special
handling. This caused problems in situations where the replacement
string is derived from user input and contains dollar signs.
Fixes#2517
* Save binary tiddlers with meta file
The filesystemadaptor plugin was a little simplistic in its
understanding of a binary file. It was using the typeInfo dictionary to
choose what tiddler types were binary (and hence needed a meta file when
saving).
I looked as if it was trying to be smart by looking for the hasMetaFile
*OR* had the encoding of base64. Unfortunately the typeInfo only defined
image/jpeg and so any other base64 encoded tiddler was assumed to be of
type text/vnd.tiddlywiki.
The net effect was only JPG images got a meta file and everything else
were saved as .tid files with base64 encoding. It all still worked but
made working with binary data in a Git repo a bit daunting.
There is enough information in the $tw.config.contentTypeInfo to
determine if a tiddler type is encoded with base64 or not. A better list
is available from boot/boot.js who registers all the types thorough the
registerFileType and marks then with base64 were appropriate.
This commit uses the typeInfo dictionary first for any filesystem
specific overrides, then the contentTypeInfo, and finally defaults to
the typeInfo["text/vnd.tiddlywiki"]. It also eliminates the now
unnecessary override for image/jpeg.
I think this might have been the original intent from commit 10b192e7.
From my limited testing all files described in boot/boot.js (lines
1832-1856) with an encoding of base64 now save as the original binary
and a meta file. Meaning that when you start the node server and then
drag-n-drop a binary file (i.e. image/png) it will PUT to the server
and then save it on the filesystem as-is allowing the file to be managed
as a binary file and not a text file. (Binary diffs are better and
GitHub supports them as well).
* Prevent duplicate file extensions
A side effects of using the $tw.config.contentFileInfo in the previous
commit is that it will always append a file extension to the tiddler
title when saving. In most cases this is the correct course of action.
However, sometimes that title is already a proper filename with an
extension (for example importing 'foobar.png' would save a file named
'foobar.png.png') which seemed silly.
This commit simply checks to make sure the title does not already end
with the file extension before appending it to the filename. A little
convenience really.
Since IE apparently doesn't have the String endsWith method I took the
liberty to add a helper method to $tw.utils trying to follow the other
polyfill patterns. I figured this was more generic and readable then
attempting to use a one-off solution inline. I got the polyfill code
from MDN.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/endsWith#Polyfill
Is strEndsWith the best method name?
It turns out that IE11 has a horrible bug whereby setting the
placeholder attribute before setting the text will trigger an input
event:
https://social.msdn.microsoft.com/Forums/ie/en-US/ae4832b0-8eee-4729-b93
3-a9977ea1b583/internet-explorer-input-event-get-fired-when-settingunset
ting-the-placeholder?forum=iewebdevelopment
There have been long standing problems with the buttons not working in
Firefox, and now a [further
problem](https://groups.google.com/d/msg/tiddlywiki/GlsruQyPOag/BAhnI2mt
BgAJ) has come to light, and been similarly hard to resolve.
On balance, I’ve decided to remove the undo/redo buttons from the
toolbar (the ctrl/cmd-Z shortcut is still operational), thus avoiding
the problems, and saving some space in the core.
This is quite a big change: a new way to invoke action widgets.
The advantage is that it solves #2217 and #1564, a long running problem
that prevented us from adding action widgets to widgets that modify the
store.
This commit adds the new technique for the button and keyboard widgets,
but also extends the select widget to trigger action widgets for the
first time
* Change the negation logic to address an edge case
Make it possible to get an interval ending with yesterday or starting with tomorrow.
* "days" filter: adjust documentation
When saving new tiddlers on node.js, allow the user to override the path of the
generated .tid file. This is done by creating a tiddler
$:/config/FileSystemPaths which contains one or more filter expressions, one
per line. These filters are applied in turn to the tiddler to be saved, and
the first output produced is taken as a logical path relative to the wiki's
tiddlers directory. Any occurences of "/" in the logical path are replaced with
the platform's path separator, the extension ".tid" is appended, illegal
characters are replaced by "_" and the path is disambiguated (if necessary) in
order to arrive at the final tiddler file path. If none of the filters matches,
or the configuration tiddler does not exist, fall back to the previous file
naming scheme (i.e. replacing "/" by "_").
This implies we will now, for tiddlers matching the user-specified filters,
create directory trees below the tiddlers directory. In order to avoid
cluttering it with empty directory trees when renaming or removing tiddlers, any
directories that become empty by deleting a tiddler file are removed
(recursively).
Benefits of this configuration option include the ability to organize git
repositories of TiddlyWikis running on node.js, ability to replace characters
that cause trouble with particular operating systems or workflows (e.g. '$' on
unix) and the ability to replicate tiddler "paths" in the filesystem (by
including a filter like "[!has[draft.of]]") without forcing such a (potentially
problematic) change on all users.
Entities such as `👷` were broken because
`String.fromCharCode()` is not fully Unicode aware. The fix is to use
`String.fromCodePoint()` where available.
Noted by @ericshulman
List fields (such as tags) when evaluated to produce tiddlers result in empty arrays. Using the exact not equals, an empty array is not the same as an empty string. By using equivelent not equals, we state that the field is either != "" or anything that can be coerced to "". Which, based on https://dorey.github.io/JavaScript-Equality-Table/ is `false` `0` `[]` or `[[]]`` neither `false` nor `0` can be set as a tiddler field as both will end up being quoted (`"false"`, `"0"`) so this should work.
When using the widget with only short form SetText attributes (field="value) -- the default field (text) of the default tiddler is set to the default value ("") -- thus clearing the text field of the current tiddler. I have inserted a conditional to test for the presence of the `field` attribute.
Whilst I was about this, I have inserted code to enable the setting of any number of TextReferences -- this fixes the issue of only being able to set one index per widget and also allows different tiddlers to be targeted by the same widget.
