Vitaly Shukela
Vitaly Shukela
> no escape sequences are recognized But indentation works the same was as in usual multiline string or is also disabled (all bytes just copied literally)?
> if nothing is specified, it's a file, and we use the extension to deduce the format > if an environment variable store a number that we want to interpret...
> But field paths are a bit more involved - you can have escaping, so stuff like foo."bar.baz".balrg, the code was already existing the grammar as Nickel needs to parse...
Do I correctly assume that current way of specifying fields on CLI is not stable, so we break backwards compatibility and e.g. require some additional prefix to specify a nontrivial...
> So all an evil file or Nickel snippet could do is...to produce a value It can include arbitrary file from a filesystem, which may be unsandboxed. That value may...
> `foo."bar=baz?".value=true` How important are those field names containing `=`? Maybe it can be worth to just limit CLI to simpler, reasonable field names and require a workaround (e.g. a...
> Thinking about this again, in fact we could find the right = by leveraging the lexer. I also though about it. > the whole thing Can lalrpop parse prefix...
> impose that the user write either file or env Shall there be also "@literal:" to embed arbitrary uninterpreted string? Is the list of those prefixes expected to grow in...
> A dialog already exists for that. Is not yet in the latest Github release version? I don't see such dialog when I long-tap the playback speed button. Or are...
Thanks for the release.