Commit graph

6 commits

Author SHA1 Message Date
Daniel Eklöf
251545203b
search: reset match state when selection is cancelled
While we’re in scrollback search mode, the selection may be
cancelled (for example, if the application is scrolling out the
selected text). Trying to e.g. extend the search selection after this
has happened triggered a crash.

This fixes it by simply resetting the search match state when the
selection is cancelled.

Closes #644
2021-07-22 17:57:43 +02:00
Daniel Eklöf
5e64e06a55
input: rewrite of how we match foot’s own key bindings
Bindings are matched in one out of three ways:

* By translated (by XKB) symbols
* By untranslated symbols
* By raw key codes

A translated symbol is affected by pressed modifiers, some of which
can be “consumed”. Consumed modifiers to not partake in the comparison
with the binding’s modifiers. In this mode, ctrl+shift+2 maps to
ctrl+@ on a US layout.

Untranslated symbols, or un-shifted symbols refer to the “base” symbol
of the pressed key, i.e. it’s unaffected by modifiers. In this mode,
consumed modifiers *do* partake in the comparison with the binding’s
modifiers, and ctrl+shift+2 maps to ctrl+shift+2 on a US layout.

More examples: ctrl+shift+u maps to ctrl+U in the translated lookup,
while ctrl+shift+u maps to ctrl+shift+u in the untranslated lookup.

Finally, we also match raw key codes. This allows our bindings to work
using the same physical keys when the user switches between latin and
non-latin layouts.

This means key bindings in foot.ini *must* not include both +shift+
and a *shifted* key. I.e. ctrl+shift+U is not a valid combo as it
cannot be triggered. Unfortunately, this was how you were supposed to
write bindings up until now... so, we try to detect such bindings, log
a deprecation warning and then “fix” the binding for the user.

When specifying bindings in foot.ini, both ctrl+U and ctrl+shift+u are
valid, and will work. The latter is preferred though, since we cannot
detect the raw key code for the former variant. Personally, I also
prefer the latter one because it is more explicit; it’s more obvious
which keys are involved.

However, in some cases it makes more sense to use the other
variant. Typically for non-letter combos.
2021-03-04 09:43:43 +01:00
Daniel Eklöf
f51ce34753
search: new function: search_add_chars()
This function inserts a string into the search buffer, at the current
insertion point (i.e. where the cursor is).
2020-12-07 20:44:12 +01:00
Daniel Eklöf
04e566492c
multi-seat: re-enable scrollback search support 2020-07-08 18:20:34 +02:00
Daniel Eklöf
0d188895c3
search: add support for user configurable key bindings
No default bindings defined yet, though.
2020-03-08 15:28:47 +01:00
Daniel Eklöf
61cabdac13
search: wip: re-direct input while searching, and build a search buffer
This adds a new state, 'is_searching'. While active, input is
re-directed, and stored in a search buffer. In the future, we'll use
this buffer and search for its content in the scrollback buffer, and
move the view and create a selection on matches.

When rendering in 'is_searching', everything is dimmed. In the future,
we'll render the current search buffer on-top of the dimmed "regular"
terminal output.
2019-08-27 17:23:28 +02:00