This removes the selection_mark_word() and selection_mark_row()
functions. To start a word/row-based selection, use selection_start()
with SELECTION_SEMANTIC_{WORD,ROW}
When calculating the offset into the search string, from where to
start rendering, take into account that the cursor position is
in *characters*, and the glyph-offset is in *cells*.
These bindings copy from the clipboard or primary selection into the
search buffer.
Default bindings:
* clipboard-paste: ctrl+v, ctrl+y
* primary-paste: shift+insert
This option lets the user configure which characters act as word
delimiters when selecting text.
This affects both “double clicking”, and ‘ctrl-w’ in scrollback search
mode.
Closes#156
If the match was somewhere near the scrollback beginning, and if the
entire scrollback hadn't yet been filled, we ended up trying to move
the viewport past the beginning of the scrollback, which we then
adjusted in the wrong direction, causing the viewport to not move at
all.
Besides being a bad user experience, since the new match wasn't
visible, foot would also crash if you manually scrolled up to the
match.
search_update_selection() was changed in 1.4.x to *first* update the
selection, *then* move the viewport.
This leads to a crash if the new match (selection) is outside the
current viewport; the selection code assumes the updated selection
endpoint is in the visible viewport.
Changing back to *first* move the viewport, *then* update the
selection solves this.
* Don't move the viewport if the new match is already fully visible
* When we do have to move the viewport, position it such that the new
match ends up roughly in the middle.
They aren't really user configurable. At least not yet.
However, with this, we now handle raw key codes just like the normal
key bindings. Meaning, e.g. ctrl+g, ctrl+a, ctrl+e etc now works while
searching with e.g. a russian layout.
Before, when looking for a matching user key binding, we only
matched *symbols*.
This means that the physical keys that generate a specific key binding
is layout dependent. What's worse, it may not even be possible to
generate the key binding at all.
Russian is one such layout, where all the "normal" (us) symbols are
replaced.
By using raw key codes, we can get around this - the key code has a
direct mapping to the physical key.
However, matching raw key codes **only** doesn't always make sense
either. For now, match **both** symbols _and_ key codes. Symbols take
precedence.
TODO: we might have to make this configurable _per binding_.
Note: 'search' mode still uses mostly hardcoded shortcuts that still
have this problem (i.e. ctrl+g doesn't work with a russian layout).
Handle the CSDs and the search box the same way we handle the main
grid; when we need to redraw them, call
render_refresh_{csd,search}(). This sets a flag that is checked after
each FDM iteration. All actual rendering is done here.
This also ties the commits of the Wayland sub-surfaces to the commit
of the main surface.
While most compositors handle instantiated but not-yet-mapped
sub-surfaces correctly, e.g. kwin does not.
For example, it will incorrectly offset the main surface both
horizontally and vertically with a couple of pixels, leaving two
transparent areas at the top and left, between the SSDs and the main
surface.
Note that a workaround is to position the sub-surfaces inside the main
surface while they're unmapped. However, since the surfaces may be
larger than the main surface (the CSDs, for examples, always are),
this doesn't quite work since kwin, at least, resizes the window to
include the sub-surfaces, even when unmapped.
So, instead we instantiate all sub-surfaces on demand, when we know
where to position them, and when they should be mapped.
Maintain a view 'offset' (which glyph from the search string to start
rendering at).
This defines the start of the viewable area. The end is the offset +
the search box size (which is limited to the window size).
Adjust this offset whenever the cursor moves outside the viewable
area. For now, this is always done in the same way: set the offset to
the cursor position.
This means that when we're entering text at the end of the search
criteria (i.e. the normal case; we're simply typing), and the search
box reaches the window size, the cursor will jump to the start of the
search box, which will be empty. This could be confusing, but let's go
with for now.
When we calculate the end coords, we must reset end-col when we reach
the end of the line and bump the end-row.
This fixes an issue where bumping the row once lead to the end row
being bumped for *each* remaining match character.
When we've already found a partial match (but *not* a complete match),
and that match spanned multiple lines, then when we continued with the
next start-column we re-used a know-wrong row pointer.
* search_find_next() searches the scrollback, continuing from the last
match. The assumption is that the search buffer has changed.
* search_update_selection() updates the selection and moves the view
to ensure the selection is visible. Note that it doesn't verify the
selection actually matches the search buffer.
If the user has started a scrollback search and have some matching
text, he can now press ctrl+w to extend that selection (and thus the
search criteria too) to the end of the current word, or to the end of
the next word if currently at a word separating character.
When matching characters, we moved on to next row directly after
matching the last character in a row.
This was wrong since if that last character was the last matching
character, we tried to create a selection that was on the wrong row.
