| Age | Commit message (Collapse) | Author |
|---|
|
In 13e90c090923a209e5e26fb3e609d5d12f737f53 I decided to make `Map` a
type alias to a tuple containing the key-value pair used by
`MapCollection`.
Here I've decided that I prefer the type as it was before. Sure, it was
more of an intermediary type, but it did have a name that was used
consistently. We do have to leave in our custom `HashMap` building, so
perhaps this isn't the ideal solution, but I'm going with it, at least
for now.
|
|
An input with all mixed whitespace and comments should behave the same
as empty input.
|
|
Since the most recent `many1` change
(09c0a432fb339a2218096bb9a4398fb86301488f), the parser fails on
end-of-input, or an empty string.
In that case, it should instead return the default `MapGroup`. Add a
special case for this.
|
|
Thanks to Arnavion on Mozilla#rust for clueing me into this:
> The documentation starts with "A parser in this library can be
> described as a function which takes some input and if it is
> successful, returns a value together with the remaining input."
> Key phrase being "with the remaining input"
> So I assume it just matches as best as it can (which is nothing, in
> your case)
> Maybe you want to use some one-or-more combinator rather than many
> which is a zero-or-more combinator
> Then add your own check that "the remaining input" is empty
Replacing my `many()` parsers with `many1()` correctly propagates errors
up from sub-parers. Nice!
This will fail when we try to parse an empty string, but we can just add
a special case for that to parse successfully.
|
|
Investigating why I'm not getting error messages in my parsed result.
The layer where I stop getting them is when parsing to a
`MapCollection`.
Split the list of `map()` parser out from `map_collection()` to get more
information. Turns out that the new `maps()` parser is now where parse
errors get discarded.
In an attempt to get the errors to appear, I tried to replicate the
structure of Combine's INI example parser:
https://github.com/Marwes/combine/blob/921202a018000041c9d3e8b12b7c1a53d0252f67/examples/ini.rs
That program makes a `property()` parser which outputs a 2-tuple of
`(String, String)`, and a `properties()` parser which outputs a
`HashMap<String, String>`, using the values in the tuple to construct
the HashMap.
Unfortunately, this change didn't solve the problem of the non-bubbling
error messages. Unsure about whether or not to keep this change.
|
|
This was here for reference. No longer needed.
|
|
This means that if any of `<Up>`, `<Play>`, or `<Down>` are undefined in
the mappings file definition, they will be set to their default action
values (as set in `MapGroup::default()`).
To get rid of the default, map the button trigger to `<Nop>`.
Update a test that didn't map `<Up>` to give it the default mapping.
|
|
If a mappings file is found but is empty, no mappings will be set. Hmm,
that sounds wrong. We still want to keep the defaults even if only some
button triggers are mapped. Making buttons do nothing is what `<Nop>` is
for, not this behaviour. Darn.
|
|
This idea is replaced by code from 'autopilot', which lives in the
`autopilot_internal` module.
|
|
Seemed to make more sense as it will be printed to the daemon's stderr
log when reloading mappings.
|
|
Don't panic on error. Instead display the error to the user.
|
|
Looking at the function, it makes more sense to put it inside
a `MapAction` impl since it operates on a `MapAction`.
|
|
I had written that TODO when I thought we were going to be parsing
`Action::Command`s. I ended up completely getting rid of
`Action::Command`, and putting commands in `Action::String`s instead.
|
|
|
|
Get rid of these warnings:
warning: private type `parser::Character` in public interface (error E0446)
--> src/parser.rs:72:15
|
72 | Character(Character),
| ^^^^^^^^^
|
= note: #[warn(private_in_public)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #34537 <https://github.com/rust-lang/rust/issues/34537>
warning: private type `parser::KeyCode` in public interface (error E0446)
--> src/parser.rs:73:13
|
73 | KeyCode(KeyCode),
| ^^^^^^^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #34537 <https://github.com/rust-lang/rust/issues/34537>
|
|
I wasn't using it. At first I added it because it made sense, but
ultimately I ended up using `Action::String` for commands instead
because that was easier.
|
|
This function isn't used
|
|
|
|
This "key" creates an empty action that doesn't do anything. Allows
users to clear the default behaviour of a headphone button.
|
|
|
|
Add a new parser for `NXKey`s. I originally thought I was going to add
this to the `key_code()` parser, but that one parses to `KeyCode`s.
Seemed like it would be easier to make a brand new parser to handle the
different type.
Need to add tests for this.
|
|
Add this new key type to the enum and enable it to be `tap()`ped like
the others.
Made `NXKey` a type alias instead of a struct to allow us to refer to
any of the NX key constants using the `NXKey` type. This also meant
moving those NX constants outside of the `NXKey` impl and into the top
level. May end up wrapping them back up in some kind of namespace later.
Adjusted the public-ness of some functions to support this change.
|
|
Commands now stay `Action::String`s without getting re-parsed to
`Action::Command`s (as per 79dfb6c8cd536e9448f05421d5018785a8b590ce).
This test is therefore unnecessary.
|
|
Previously I had only implemented it for top-level maps. Get it working
for in-mode maps too. Move the parsing code to a function so it can be
re-used in both places.
|
|
Non-working attempts.
|
|
Use `autopilot::key::tap()` to simulate each key and modifier in an
action.
Originally tried to do this using a method that takes a closure to
access the `KeyCodeConvertible` types inside `KeyboardKey`. Ended up
with a much cleaner API solution that only requires a single method
call.
|
|
I originally wrapped the contained `Vec` in an `Option` to that we
wouldn't have to initialise whole new empty `Vec` for every key in an
`Action` list.
However, this made less sense once I wrote the parser and ended up with
an empty `Vec` by default that I then had to convert into an `Option`.
Now I've started the code to type keys including modifiers, and the
`Option` no longer makes any sense at all. In order to type keys
(including modifiers), I'll be using Autopilot's `tap()` function:
pub fn tap<T: KeyCodeConvertible + Copy>(key: T, flags: &[Flag], delay_ms: u64) {
This function requires a slice, so I ended up getting a `Vec` from my
parser, converting it to an Option to satisfy my original interface, and
now would have to convert it back into a `Vec` or slice in order to be
able to pass it into `tap()`. Talk about unnecessary.
Get rid of the `Option` because it's more work for absolutely no reason.
|
|
Get rid of old commented code now that we have a working version.
|
|
First, `MapGroup::parse` parses actions to `Action::String`s. We then
run a second pass on the parsed actions to parse them into
`Action::Map`s.
A few failed attempts but finally got it working. Tried a few ways of
doing it and kept running into various borrowing problems. Glad it's
working now.
|
|
This reverts commit 5ef2443642a2d8b223afdf169200a725d2809b76. See that
commit for details.
|
|
Trying to add new escape special keys for '\' and '<' but having a bit
of trouble.
Looks like I'm not using `and` `satisfy` correctly, as I'm getting this
error:
error[E0271]: type mismatch resolving `<(impl combine::Parser, combine::combinator::Satisfy<_, [closure@src/parser.rs:263:56: 263:68]>) as combine::Parser>::Output == char`
--> src/parser.rs:260:18
|
260 | (choice!(
| __________________^
261 | | try(string_case_insensitive("Bslash")).map(|_| '\\'),
262 | | try(string_case_insensitive("lt")).map(|_| '<'),
263 | | try(action_character().and(satisfy(|c| c != '>')))
264 | | ).map(|c|
| |_________________^ expected tuple, found char
|
= note: expected type `(char, _)`
found type `char`
= note: required because of the requirements on the impl of `combine::Parser` for `combine::combinator::Try<(impl combine::Parser, combine::combinator::Satisfy<_, [closure@src/parser.rs:263:56: 263:68]>)>`
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
I had added the `satisfy` not '>' after getting this test failure
without it:
---- parser::tests::action_parses_map_with_bslash_and_lt_special_keys stdout ----
thread 'parser::tests::action_parses_map_with_bslash_and_lt_special_keys' panicked at 'assertion failed: `(left == right)`
left: `Err(Errors { position: PointerOffset(4332007031), errors: [Unexpected(Token('l')), Expected(Token('>'))] })`,
right: `Ok(Map([KeyboardKeyWithModifiers { key: Character(Character(Character('a'))), flags: None }, KeyboardKeyWithModifiers { key: Character(Character(Character('\\'))), flags: None }, KeyboardKeyWithModifiers { key: Character(Character(Character('A'))), flags: None }, KeyboardKeyWithModifiers { key: Character(Character(Character('N'))), flags: None }, KeyboardKeyWithModifiers { key: Character(Character(Character('D'))), flags: None }, KeyboardKeyWithModifiers { key: Character(Character(Character('<'))), flags: None }, KeyboardKeyWithModifiers { key: Character(Character(Character('>'))), flags: None }, KeyboardKeyWithModifiers { key: Character(Character(Character('\\'))), flags: Some([Control]) }, KeyboardKeyWithModifiers { key: Character(Character(Character('<'))), flags: Some([Meta, Shift]) }]))`', src/parser.rs:928:9
as I suspected this was a problem with `<lt>`. But now that I think
about it, it could just as easily have been a problem with `<Bslash>`.
Not sure.
Anyway, I'm thinking of dropping these escapes because they're redundant
(we already have '\' escaping) and because I'm tired of these errors.
|
|
A simple test to check parsing of a simple string without any special
keys or modifiers.
|
|
Make this test do something, validating that it parses multiple modifier
prefixes in a special key.
|
|
Add a '>' closing bracket to the end of the test string to make sure
that the '<' gets escaped even with a '>' following it.
|
|
Previously we were able to parse modifier + KeyCode (`<C-Enter>`) special
keys and plain KeyCode ones (`<Esc>`).
This change adds parsing support for the final type of special key,
modifier + character (e.g. `<C-l>`).
action_character():
Move the `map` outside of this function and into `action_map()` to allow
us to reuse the parsed `char` in `special_key()`.
key_modifier():
* Move the `many()` parser and `Option` handling outside of this
function and into `special_key()`. Doing so enables us to say:
<C-l> // Character special keys _require_ a modifier (thus
// `many1`)
<[C-]Left> // KeyCode special keys may or may not have a modifier
// (thus `many`)
* Rename from `key_modifiers()` to singular now that it only parses a
single modifier.
special_key():
Parse both character and KeyCode special keys with modifiers.
action_parses_map_with_modifier():
Change input string to include a KeyCode-style special key with a
modifier since we didn't have one previously. This ensures we test both
kinds of special keys.
|
|
Add some parsing code for modifier keys inside special keys (`<`-
`>`-wrapped keys).
Currently only works for special keys defined in `special_key()`. Needs
to be extended to work for modified character keys (e.g. <C-l>), thus
the test in this commit doesn't pass.
|
|
Escape '<' and '\' by prepending a backslash. Since special characters
are enclosed in '<' '>' brackets, in order to type a literal '<', we
need a way to escape it. Use backslash, like in Vim.
|
|
Splits up the `action_map()` function and gives the parser a name.
|
|
Additionally, fix a problem in `key_code()` when using special key names
that start with the same character (like any of the F keys, or Enter and
Esc). The parser would discard the first character, like in the
`definitions()` parser. Use the same solution here, by wrapping the
parser choices in `try()`s.
Add `Esc` to the test to confirm that it fails not just for the F keys
but for all key names that start similarly.
|
|
Still need to test them though. They'll be used in conjunction with
another new parser, `action_map`, which will parser map-type action
strings.
`key_code` parses `autopilot::key::KeyCode`s, basically all special keys
and modifiers. `special_key` parses key codes inside `<` `>` braces.
Change the test to use `easy_parse` to give a clear error message.
Add `recursion_limit` to the crate on the advice of the compiler in
order for the `choice!` macro in `key_code()` to work properly.
Otherwise it spits out a giant error message complaining about
`rustc --explain E0277`. If I remove a handful of elements from the
`choice!`, it compiles, so it seems there's an upper bound restricted by
the recursion limit.
Modifier keys are included in a commented section as these are part of
the 'autopilot' `KeyCode` enum, but they'll be handled in a separate
parser.
|
|
* Some stub ideas for test text
* Fill in the test for special keys
* Add some convenience methods to more easily create the expected test
result objects
|
|
Ideas for some things we should be testing.
|
|
Fix these tests that were based on the `String` version of `Action`,
before b02e7366c3c4b9edb5afa0d012952fad369b66a9.
|
|
It will now be a different type of `Vec` depending on whether it
represents a string map or a command. We'll have new parsers to parse
the action definition in a more fine-grained way.
The `String` variant is just there for temporary backward compatibility
while I figure out parsing for the other two.
Still need to update the tests for this change.
|
|
This reverts commit 16cd3895f7b111544927d71904aab912d9abbf59. See that
commit message for details.
|
|
Such a pain. As soon as I clear one set of compilation errors, another
set crops up. The last one was like the following:
error[E0277]: the trait bound `K: std::default::Default` is not satisfied
--> src/cocoa_bridge.rs:117:1
|
117 | / pub extern "C" fn state_new<K>() -> *mut State<K>
118 | | where K: KeyCodeConvertible {
119 | | Box::into_raw(Box::new(State::default()))
120 | | }
| |_^ the trait `std::default::Default` is not implemented for `K`
|
= help: consider adding a `where K: std::default::Default` bound
note: required by `cocoa_bridge::State`
--> src/cocoa_bridge.rs:100:1
|
100 | / pub struct State<K: KeyCodeConvertible>
101 | | where K: Default {
102 | | in_mode: Option<Vec<HeadphoneButton>>,
103 | | map_group: Option<MapGroup<K>>,
104 | | }
| |_^
error[E0277]: the trait bound `K: std::default::Default` is not satisfied
I'm done with this. Just going to make a darn enum of 'autopilot's
`Character` and `KeyCode` structs so I don't have to deal with this
mess.
|
|
This reverts commit 76ab45d4a5890c4c348b33c32775e45a7c320c58. See that
commit for details.
|
|
Some non-working code where I was trying to get an `Action2` to parse
correctly, with a dependency on the result of the `map_kind()` parser.
Couldn't figure out how to get this to work though, as I couldn't escape
errors like this one:
error[E0271]: type mismatch resolving `<[closure@src/parser.rs:157:36: 186:6] as std::ops::FnOnce<(_,)>>::Output == std::result::Result<parser::Map, <I as combine::StreamOnce>::Error>`
--> src/parser.rs:137:16
|
137 | fn map<I>() -> impl Parser<Input = I, Output = Map>
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `std::result::Result`, found struct `parser::Map`
|
= note: expected type `std::result::Result<std::result::Result<(parser::Map, _), _>, _>`
found type `std::result::Result<parser::Map, _>`
= note: required because of the requirements on the impl of `combine::Parser` for `combine::combinator::FlatMap<combine::combinator::TakeUntil<_, combine::char::Newline<I>>, [closure@src/parser.rs:157:36: 186:6]>`
= note: the return type of a function must have a statically known size
error: aborting due to previous error
For more information about this error, try `rustc --explain E0271`.
Feeling like I've spent way too long stuck on this, so I'm just going to
parse actions into new action type (`Action2` for now) by doing a second
parsing pass. It's not going to be as performant, but at least I'm
confident that will work. We can always come back to this later. I'll be
reverting this commit.
|
|
With this new type, I'm trying to set up a way to parse actions more
precisely, to allow us to get special keys and modifier-flagged keys.
Still trying to work out how this is going to work at the parser level
though, since the action parser is going to need to depend on the map
kind parser.
|
|
Instead of letting the Objective-C code keep track of `in_mode` by
passing it around in `CKeyActionResult`, keep track of it in a `State`
struct.
Derive `Clone` on `HeadphoneButton` to resolve this error:
error[E0277]: the trait bound `parser::HeadphoneButton: std::clone::Clone` is not satisfied
--> src/cocoa_bridge.rs:273:38
|
273 | state.in_mode = Some(trigger.to_vec());
| ^^^^^^ the trait `std::clone::Clone` is not implemented for `parser::HeadphoneButton`
|
