As the triangles intro relies on the audio track's clock advancing, we can't use it just yet (CI server has no audio device). This is a temporary workaround for that shortcoming.
Due to floating-point rounding and representation errors, filters could
wrongly display results incongruous with the wedge display text (ie.
a beatmap with the BPM of 139.99999 would be displayed as having 140
BPM and also pass the bpm<140 filter).
Apply tolerance when parsing floating-point constraints. The tolerance
chosen is half of what the UI displays for the particular values (so
for example half of 0.1 for AR/DR/CS, 0.01 for stars, etc.)
Tests updated accordingly.
To match stable, add creator= and artist= filters to the beatmap
carousel on song select screen. Contrary to stable, this implementation
supports phrase queries with spaces within using double quotes.
The quote handling is not entirely correct (can't nest), but quotes
should rarely happen within names, and it is an edge case of an edge
case - leaving best-effort as is. Test coverage also included.
Introduce unit tests covering parsing for the originally introduced
filtering features. The introduced improvements (lower and upper
interval and decimal point support) also tested.
After the preparatory introduction of LineBufferedReader, it is now
possible to introduce registration of fallback decoders that won't drop
input supplied in the first line of the file.
A fallback decoder is used when the magic in the first line of the file
does not match any of the other known decoders. In such a case,
the fallback decoder is constructed and provided a LineBufferedReader
instance. The process of matching magic only peeks the first non-empty
line, so it is available for re-reading in Decode() using ReadLine().
There can be only one fallback decoder per type; a second attempt of
registering a fallback will result in an exception to avoid bugs.
To address the issue of parsing failing on badly or non-headered files,
set the legacy decoders for Beatmaps and Storyboards as the fallbacks.
Due to non-trivial logic, several new, passing unit tests with possible
edge cases also included.
Add a line-buffered reader decorator operating on StreamReader
instances. The decorator has two main operations - PeekLine(), which
allows to see the next line in the stream without consuming it,
ReadLine(), which consumes and returns the next line in the stream, and
ReadToEnd() which reads all the remaining text in the stream (including
the unconsumed peeked line). Peeking line-per-line uses an internal
queue of lines that have been read ahead from the underlying stream.
The addition of the line-buffered reader is a workaround solution to
a problem with decoding. At current selecting a decoder works by
irreversibly reading the first line from the stream and looking for
a magic string that indicates the type of decoder to use.
It might however be possible for a file to be valid in format, just
missing a header. In such a case a lack of a line-buffered reader makes
it impossible to reparse the content of that first line. Introducing it
will however allow to peek the first line for magic first.
- If magic is found in the first line, GetDecoder() will peek it and
use it to return the correct Decoder instance. Note that in the case
of JsonBeatmapDecoder the magic is the opening JSON object brace,
and therefore must not be consumed.
- If magic is not found, the fallback decoder will be able to consume
it using ReadLine() in Decode().
This commit additionally contains basic unit tests for the reader.
Suggested-by: Aergwyn <aergwyn@t-online.de>
Allow users to put both balanced round parentheses, as well as
unbalanced escaped ones, in old style link text. The implementation
is the same as for Markdown and new style links, except for swapping
all instances of
\[\]
to
\(\)
for obvious reasons (different type of parenthesis requiring escaping).
Tests also included.
Allow users to put both balanced brackets, as well as unbalanced
escaped ones, in Markdown link text. The implementation is the exact
same as in the case of new format links.
For completion's sake, tests also included.
For users to be able to add square brackets inside of links using
the new format, the regular expression used for parsing those links
contained a balancing group, which can be used for matching pairs
of tokens (in this case, opening and closing brackets, in that order).
However, this means that users could not post links with unmatched
brackets inside of them (ie. ones that contain single brackets, or
a closing bracket and then an opening one). Allow for escaping opening
and closing brackets using the backslash character.
The change substitutes this old fragment of the regex in the display
text group:
[^\[\]]* // any character other than closing/opening bracket
for this one:
(((?<=\\)[\[\]])|[^\[\]])*
The second pattern in the alternative remains the same; the first one
performs the escaping, as follows:
(
(?<=\\) // positive lookbehind expression:
// this match will succeed, if the next expression
// is preceded by a single backslash
[\[\]] // either an opening or closing brace
)
Since the entire display group is matched, unfortunately the lookbehind
expression does not actually strip the backslashes, so they are
manually stripped in handleMatches.
As demonstrated in the unit tests attached, this also allows balanced
brackets to be mixed with escaped ones.
