test_EditorCellBidi.cpp File Reference

What the caret, click-to-position and arrow keys do inside bidirectional text. More...

#include <wx/wx.h>
#include <wx/bitmap.h>
#include <wx/dcmemory.h>
#include <vector>
#include "Bidi.h"
#include "CellPointers.h"
#include "Configuration.h"
#include "cells/EditorCell.h"
#include "cells/GroupCell.h"
#include <catch2/catch.hpp>

Include dependency graph for test_EditorCellBidi.cpp:

Data Structures
class	TestApp

Functions
	SCENARIO ("The caret follows the text it is placed in")
	SCENARIO ("The arrow keys move the caret the way it is drawn")
	SCENARIO ("A selection covers the characters it selects")
	SCENARIO ("The caret is placed correctly on a mixed-direction line")
	SCENARIO ("A click resolves to the position whose caret it lands on")
	SCENARIO ("The arrow keys move the caret the way it is drawn on a mixed-direction line")
	wxDECLARE_APP (TestApp)
int	main (int argc, char **argv)

Detailed Description

What the caret, click-to-position and arrow keys do inside bidirectional text.

EditorCell maps a caret position (an index into the content) to a point by measuring how wide the text before it is - PositionToPoint(). That is only correct while the text is drawn in the same order it is stored. In a right-to-left script it is not: the first character of a Hebrew word is drawn at its right end, so a caret one character in belongs near the right of the word and not, as the measurement says, one character's width from its left. SelectPointText() (turning a click into a position) and HandleSpecialKey()'s arrow-key handling face the same problem from the other direction.

These scenarios measure the mapping rather than assume it, for a left-to-right string as the control, a right-to-left one, and a line mixing the two.

Windowless: a real GroupCell/EditorCell against a memory-DC Configuration, in the manner of test_EditorCellWrapping. The display comes from the run_headless wrapper ctest starts this through, so there is no Xvfb wrangling here.