- Revise the introduction section.
- Link to the notes on commands taking value inputs from all such commands.
- Revise the doc on the "all" command.
- Revise references to the builtin module from the language reference.
* docs(effective-elvish): follow same style as other docs
e.g., https://elv.sh/ref/language.html
* docs(builtin): ref from take to drop
* docs(language): remove mention of :up and :down ns
* docs(fundamentals): update to new lambda format
* docs(tour): update to new lambda syntax
* docs(builtin): update to new lambda syntax
* docs(language): update to new lambda syntax
* docs(unique-semantics): update to new lambda syntax
* docs(tour): fix typo
* Revert "docs(effective-elvish): follow same style as other docs"
This reverts commit db4306a400c61f5f7b6acec7a1e1f39feb9b1ba0.
https://github.com/elves/elvish/pull/1457#discussion_r775102178
The existing `edit:add-var` documentation incorrectly implies the `$init`
value is optional. It also doesn't include any examples that are useful
in practice. This addresses both shortcomings.
* Remove a superfluous line break in the equivalent Elvish code.
* Keep code in transcripts on the same line to be correctly highlited.
* Add another example using digit-only argument names.
The `AnyError` placeholder error can cause tests to succeed for errors
other than what was expected. That is, the use of `AnyError` can mask
bugs in a unit test. So replace it with the specific error, or error type,
the test expects to be raised.
This does not remove the anyError structure because it is used in
the TestCase.DoesNotCompile() method. To keep the size of this change
as small as possible I want to defer updating that use to a separate
change. However, remove the public AnyError var so future test writers
don't attempt to use it.
Now that v0.17-release has been branched, the HEAD build will show deprecations
intended for 0.17.0, and be considered a pre-release version of 0.18.0.
When the destination to scan into is an interface, its zero value is simply a
nil interface, losing the information of the original type and resulting in
error messages like "need nil, got $actual-type".
ScanToGo now handles this case specifically, and uses the string representation
of the interface type in the error message.
Before:
~> ns []
Exception: wrong type of argument 0: wrong type: need nil, got list
~> var x~ = x
Exception: wrong type: need nil, got string
After:
~> ns []
Exception: wrong type of argument 0: wrong type: need !!hashmap.Map, got list
~> var x~ = x
Exception: wrong type: need !!eval.Callable, got string
This is still not ideal, since the "need" type is not given as an Elvish "kind",
but it's much less confusing than than old "need nil" messages.
This fixes#715.
* Fix the case when start is near the overflow point and add regression tests.
* Rewrite the implementation in a less abstract way.
* Rewrite the elvdoc.
This simple optimization improves the performance of pipelines containing only
one form drastically. Pipelines containing more than one form also execute a
little bit faster.
A subset of the benchmark results, on MacBook Air M1 2020:
| Benchmark | Before | After | Speedup |
| --------- | ----------- | ----------- | ------- |
| nop | 3398 ns/op | 934.1 ns/op | 3.6x |
| nop-nop | 13596 ns/op | 11423 ns/op | 1.2x |
| put-x | 4163 ns/op | 1611 ns/op | 2.6x |
I was surprised to see so many legacy lambda syntax examples in the
documentation. This replaces all of them with the new syntax -- excluding
the handful of cases meant to explicitly verify the legacy form is still
valid. This also adds a link to the issue in the release notes which
documents the change in syntax.
Related #664
This change is due to a recent IM discussion wherein someone had
difficulty finding the `path:is-regular` command. It attempts to make
such discovery easier.
Expose the default comparison function used by the `builtin:order`
command as a command in its own right. This command is useful when
writing, in Elvish, something like `builtin:order`. Such as a semantic
version comparison command.
Resolves#1347
A recent IM question, and subsequent discussion, resulted in @hhanche
commenting that if you need to explicitly move the output of `printf`
from the byte to the value stream you should use `slurp` rather than
`put` or `from-lines`. Include that insight in the `printf`
documentation.
