c8e6857aff
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`.
37 lines
669 B
TOML
37 lines
669 B
TOML
[workspace]
|
|
members = [
|
|
"helix-core",
|
|
"helix-view",
|
|
"helix-term",
|
|
"helix-tui",
|
|
"helix-lsp",
|
|
"helix-dap",
|
|
"helix-loader",
|
|
"helix-vcs",
|
|
"helix-parsec",
|
|
"xtask",
|
|
]
|
|
|
|
default-members = [
|
|
"helix-term"
|
|
]
|
|
|
|
[profile.release]
|
|
lto = "thin"
|
|
# debug = true
|
|
|
|
[profile.opt]
|
|
inherits = "release"
|
|
lto = "fat"
|
|
codegen-units = 1
|
|
# strip = "debuginfo" # TODO: or strip = true
|
|
opt-level = 3
|
|
|
|
[profile.integration]
|
|
inherits = "test"
|
|
package.helix-core.opt-level = 2
|
|
package.helix-tui.opt-level = 2
|
|
package.helix-term.opt-level = 2
|
|
|
|
[patch.crates-io]
|
|
tree-sitter = { git = "https://github.com/tree-sitter/tree-sitter", rev = "c51896d32dcc11a38e41f36e3deb1a6a9c4f4b14" }
|