| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* fix: version of Cargo feature resolver.
This commit solve the ambiguity to determin the version of resolver.
To get more detail, see the following two documents:
- https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions
- https://doc.rust-lang.org/edition-guide/rust-2021/default-cargo-resolver.html
* unified: Rust edition in all workspaces.
Now, the Rust 2021 is available in all workspaces.
* fined up: Cargo.toml by using workspace inheritance.
To get more detail of the `workspace.package` table, see a following document:
- https://doc.rust-lang.org/cargo/reference/workspaces.html#the-package-table
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Snippet text elements can contain escape sequences
that must be treated properly. Furthermore snippets
must always escape certain characters (like `}`
or `\`). The function has been updated to account
for that. `text` is now also included with
`anything` to match the grammar and can also
match empty text. To avoid infinite loops the
`non-empty` combinator has been added which is
automatically used in the `one_or_more` and
`zero_or more` combinator where the problemn would
occur.
|
| | |
|
| | |
|
|
|
Parser-combinators are one of the simpler tools for building ad-hoc
parsers. They're a good fit because they are...
* Small: each parser / parser-combinator is around 10 LOC.
* Functional: helix_core strives to be a functional set of utilities
usable throughout the rest of the editor.
* Flexible: use them to build any sort of ad-hoc parser. In the child
commit, we'll parse LSP Snippet syntax using these new parser
combinators.
Why not use an existing parser-combinator crate? Existing popular
parser-combinator crates have histories of making breaking changes
(for example nom and combine).
> Implementation note: I tried to not introduce a new trait since the
> types can be expressed in terms of `impl Fn`s. The trait is necessary
> to build `seq` implementations without a proc macro though, and also
> allows us to use `&'static str`s very conveniently: see the trait
> implementation for `&'static str`.
|
