Git `nu-complete` defs where outdated, using a removed function
`nu-complete git switachable branches`, now using `nu-complete git
switch`
Already tested (except for tags)
Forgot to bump the Nupm version, but then again everyone else did as
well ;-)
Updated it to 0.3.0 (skipped 0.2.0) since it looks like there have been
two commands that have been either added or drastically changed since
0.1.0.
Minor fix on `str dedent` - I erroneously used the regex multi-line flag
`(?m)` in several patterns where it shouldn't have been. For the most
part, this was harmless, but it did surface an error when I was working
on updating the themes.
Fixed these and added two new tests that would have caught the issue.
Changes:
* Custom Nushell `color_config`'s (non-Lemnos) are moved to the
`./src/custom-nu-themes` directory and used to generate the main theme
files when doing a `./make.nu`
* `make.nu` and other scripts (e.g. preview) have been moved to the
`src` directory
* A separate `README` for the `src` scripts
* Main theme `README` updated for clarity
* Reordered the theme template, so all themes were regenerated. I'd like
to stop doing this ;-)
@amtoine Thanks for your suggestions on the `README`. I've pretty
extensively changed the flow, so please re-review and let me know how it
looks. Also note that I haven't personally tested with Nupm, so please
especially review this section. Thanks!
@fdncred CC
Still planning on working on the preview scripts next. They'll need only
slight changes to run (probably a path change), but they can be
simplified a bit now, I hope. At the same time, I'll complicate them in
other ways ;-).
Note that there is a bug in both `nushell-dark` and `nushell-light` that
prevented the terminal colors from being updated regardless. You can see
that in the existing screenshots, where both those themes simply re-use
the previous theme (alphabetically's) background. I haven't fixed this
yet.
* Primary change: Simplifies theme usage by adding an `export-env` to
each theme so that `$env.config.color_config` is automatically set when
importing the module.
Rather than the old:
```nu
use nu-themes/nushell-dark.nu
$env.config.color_config = (nushell-dark)
```
It's now a single-step:
```nu
use nu-themes/nushell-dark.nu
```
* Updates `make.nu` to create the theme files (uses the previously added
`str dedent` for clean output).
* A couple (literally, 2) of the remote themes did not have all
necessary colors and failed. Updated `make.nu` to continue on error, but
report the failures.
* Updated `README.md`
Finally got around to polishing up and contributing the concept from
[Nushell #11477](https://github.com/nushell/nushell/issues/11477).
This is based on a (very slightly) modified version of the [Swift
approach](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/stringsandcharacters/#Multiline-String-Literals)
suggested by @jameschensmith:
<img
src="https://docs.swift.org/swift-book/images/org.swift.tspl/multilineStringWhitespace~dark@2x.png"
width="480" />
```nu
> use std-rfc str
> let s = "
Totally unindented
Indented by two spaces
Indented by four spaces
Intended by two spaces
Unindented
"
> $s | str dedent
Totally unindented
Indented by two spaces
Indented by four spaces
Intended by two spaces
Unindented
```
Specifically:
* Requires a multi-line string where the first and last lines are blank
(empty or contains only whitespace)
* Will error if the first and/or last line are not blank
* The amount of indentation to remove is based solely on the *number of
spaces* on the final line of the string
* Tabs are not considered for indentation calculations
* The first and last line of the original string are not returned as
part of the dedented string. Those lines are for "control"/formatting
purposes only.
* If you want the string to end in a linebreak, simply add an extra
blank line before the last "control" line (as in the example above).
* Unlike the Swift format, whitespace is allowed on the first line of
the string. It may not be visible to the user in their IDE, and there's
just no reason to create an error in this case since the line is
intended to be stripped anyway.
* *Only* indentation whitespace is removed. Any other whitespace is left
untouched, including that on otherwise empty lines.
A good (I hope) set of examples for these rules can be found in the test
cases.
Added `git restore` to git completions, as I was missing tab completion
for that.
I've begun to use Nushell regularly, so I hope this addition will be
useful to others as it is to me.
Feedback is appreciated if there's any conventions I've missed, or
options that need better wording.
I am sorry. I assumed that an SSH host in the config file must contain a
hostname, but this assumption is not true.
If a user reads an SSH host that doesn't contain a hostname, it will
fail to parse.
This is a benchmark that I created while testing IR. It's meant to
basically do only very simple operations but be running 100% Nushell
code most of the time, without any heavy lifting being done by commands,
and without any closure calls or anything like that. It seemed useful to
keep around so I'm adding it to `nu_scripts`.
> 💡 **Note**
>
> greatly inspired by _Direnv_
this new "_nuenv_" hook will `source` any `.env.nu` file found in the
current directory as part of a hook.
in order to be a bit more safe, i've added `nuenv allow` and `nuenv
disallow` that will keep track of which "env" files are allowed to be
sourced, i.e. if a file is not allowed, then you'll have to run `nuenv
allow` first.
## example usage
```nushell
use nu-hooks/nuenv/hook.nu [ "nuenv allow", "nuenv disallow" ]
$env.config.hooks.env_change.PWD = (use nu-hooks/nuenv/hook.nu; hook setup)
```
i wanted to share some of my hooks, as i don't see equivalent things in
the `nu-hooks` package 😌
## new hooks
- `toolkit.nu`: creates a hook that will activate any `toolkit.nu`
- `startup-times.nu`: creates a hook that will log the startup times in
a log file
## review
i think the easiest is to read the docstring and arguments of the two
`setup` commands i've added in the two modules defined above 😉
cc @fdncred, i might have missed the latest and hotest features of the
"startup times" hook, please tell me if something should be added
😇
Changing "export def" to "export extern" to not shadow the original
command as it would disallow anything not defined in the re-definition
There seem to be similar cases in completions for (naive search with "rg
'export def'")
- mask
- winget (exports some defs and some externs. So i dont know if those
defs are actually additional functionality)
- pnpm (only exports some 'nu-complete' defs)
- pass (only exports some 'nu-complete' defs)
I don't feel comfortable changing those as i am not familiar with them.
Having the the main branch listed in the checkout command:
```nushell
git -C $repo checkout -b $branch nushell/main
```
Made my git to track against the main branch, causing it to push to main
instead of a branch. Removing the branch fixed the problem:
```nushell
git -C $repo checkout -b $branch
```
This PR adds `jc` wrapper, so that `jc` output is automatically parsed
into a nushell data structure and you don't have to use `| from json`
filter to parse it.
References: https://kellyjonbrazil.github.io/jc/#jc
This PR makes the location of vswhere more programmatic by looking where
it's supposed to be located on the file system instead of relying on it
being in your path.
I changed `export-env {}` at the beginning to a custom command to avoid
having `export-env` run when loading the module
because:
1. I couldn't use `nu_msvs activate` because it depends on env vars
being set that were hidden with `nu_msvs deactivate`
2. It seems that `export-env` executed at `use`, leaves `$env.FILE_PWD`
available in the environment which I think may be
a bug. So, putting it in a custom command avoids that.
This updates the nu_msvs module. There were several things that I didn't
think looked proper for Windows so I changed them an hopefully made this
module a tiny bit better.
[`kw`](https://github.com/kworkflow/kworkflow) is a tool used by kernel
developers to help with the workflow
---------
Co-authored-by: Lais_Nuto_Rossman <laisnuto@gmail.com>
- removed usage of a new external command `math significant-digits`
- rounded precision to 4th digit including (max relative error of 0.05%)
- in `--pretty` I replaced abs `stddev` with relative `coefficient of
variation` (CV)
@amtoine, would you please take a look into my new variant once again?
Maybe this time it will be good enough?
<img width="804" alt="image"
src="https://github.com/nushell/nu_scripts/assets/4896754/49e62609-4301-4d5c-b1f5-d2c3355cb33e">
1. fix: update `(sys).host` to `sys host` to work for 0.94.x
2. fix: handle incorrect behaviors when re-importing nu_conda or nu_msvs
3. doc: update minimum requirements of nushell in README.md
Rustup help page changed, so the commands that were based on the old
layout to get the completions were broken
Improved some completions to include a description like "default" or
"installed"
Also added completions for `rustup help`
Reverts nushell/nu_scripts#868
I found that this works, if you source these files like
```
use aliases/git/git-aliases.nu *
use custom-completions/git/git-completions.nu *
```
but if you source them like this, it doesn't work.
```
use custom-completions/git/git-completions.nu *
use aliases/git/git-aliases.nu *
```
This changed recently somewhere in nushell.
@amtoine gave me valuable feedback about the [PR of `std bench`
improvement](https://github.com/nushell/nu_scripts/pull/859) CANDIDATE
into `stdlib-candidates`.
I understood and respected his reasoning about his position. Yet, I
still believe that users of `std bench` will benefit from my proposal.
I incorporated some of @amtoine advice in this PR.
I removed the `bench --units` option as I now believe it is better to
encourage users to use core functionality for formatting duration (which
I had not thought of initially) and to avoid multiplying `--options`.
```
bench -n 10 {sleep 0.1sec} | format duration ms mean min max stddev
# or
bench -n 10 {sleep 0.1sec} | format duration ms ...($in | columns)
```
Also, I removed the option of `--sign-digits` and just hard-coded the
precision of conversion to the fourth significant digit (which will give
a maximum relative error of 0.05%, which I still think is unnecessarily
precise).
To explain my motivation, I added some context from our previous
conversation:
>> Maybe you would agree with me that this representation is very wordy
and unnecessary, even for a professional?
>> `1sec 333ms 333µs 333ns`
> maybe, but then i would argue the issue comes from the formatting
nushell does on durations, not from std bench, it's just that Nushell
will show every part of the duration 😕
And I add here that if Nushell adds the setting for resetting
insignificant digits from displaying, those conversions could be removed
for the better. Yet, we don't have such a setting yet, but we already
use bench and use it quite often. So, I propose this usability
improvement.
In my defense, I would add that the existing `--pretty` option will only
benefit from the proposed changes (while it can't benefit from `| format
duration ms`).
```diff
> bench {sleep (10sec / 3)} --rounds 2 --pretty
- 3sec 335ms 974µs 264ns +/- 1ms 108µs 748ns
+ 3sec 335ms +/- 1ms 108µs
```
Finally, I kept the `--list-timings` option because I strongly believe
that users much more often will not need expanded 50 lines of timing
results on their screen (which they can get rid of by adding `| reject
time` in the second execution of the `bench` command - but I would like
to avoid this second execution).
I won't be hurt if my proposed changes aren't accepted and applied to
mainstream. Yet, I feel like my initial PR is still valuable and will
benefit from my current PR's additions.
In the last `pr` there was an error, that I just discovered and fixed.
Also I added test for this case in future, and some test for negative
numbers
```
0 | signfificant digits 2
33 │
34 │ let insignif_position = $n - 1 - ($num | math abs | math log 10 | math floor)
· ──┬─ ────┬───
· │ ╰── 'math log' undefined for values outside the open interval (0, Inf).
· ╰── value originates from here
35 │
╰────
```
I'm sorry for hassle here 😞
TL;DR: The "simple" example from
https://www.gnu.org/software/make/manual/html_node/Simple-Makefile.html
is currently not compatible with the custom completion script found in
`custom-completions/make/make-completions.nu`. This PR tries to fix
that.
As I was working on `nur` (https://github.com/ddanier/nur) and the
`nurify` script to convert to `nur` from different task runners
(https://github.com/ddanier/nur/blob/main/scripts/nurify.nu) I wanted to
create a good way to convert from using `make`. So I thought the `make`
completion would for sure implement a good way to get a list of all
possible `make` targets. Hence I started looking at
`custom-completions/make/make-completions.nu`.
Then I searched for a good documentation for how `Makefile`s work, as
the last time I was using this myself is about 5 to 10 years ago. If you
for example look at the documentation on gnu.org you may find examples
of `Makefile`s not working with the current autocompletion. See
https://www.gnu.org/software/make/manual/html_node/Simple-Makefile.html
for example, the "simple" example they provide.
The reason for this not working is that the targets use some whitespace
after the target name. This is somehow allowed and thus valid. See
https://www.gnu.org/software/make/manual/html_node/Rule-Introduction.html
for a quick overview about how the `Makefile`s syntax works. I quickly
checked this to ensure `make` actually parses this correctly, it really
does.
This means that the current `make` completion does miss support for the
"simple" example provided my `make` itself. So I went on to fix this.
My suggested solution is:
* Filter all lines by regex `'^[\w\.-]+\s*:'` to ensure possible targets
- start with some word (also allowing `.` and `-`)
- may have some whitespaces after the word
- has ":" after this
* Split by the ":"
* Use first column
* Trim the remaining target name to remove those nasty whitespaces
* Use result for completion
For me this did fix the issue with the "simple" `Makefile`, allowing me
to put this into my `nurify` script.
Would be nice to get this "backported" to nu scripts as well. Might help
others 😉
- Removes the note about installing the dataframes feature.
- Moves the command changes section to the top level, renames some sub
sections, and adds some more sub sections.
- Moves and simplifies the hall of fame.
Adds completions for when using a `./gradlew` script in Gradle projects
The script provides completions both for the script flags and for the
available tasks in the current project
This PR is part of porting all old scripts #221 and includes the
`virtual_environments` module
## 5 files changed
- `conda.nu`: removed, already in
`modules/virtual_enviromnents/conda/nu_conda.nu`
- `conda_deactivate.nu`: also removed, has already been merged with
`nu_conda.nu`
- `README.nu`: removed, similar info in
`modules/virtual_enviromnents/README.md`
- `venv.nu`: ported to `modules/virtual_enviromnents/venv/venv.nu`
- `venv_deactivate.nu`: ported to
`modules/virtual_enviromnents/venv/venv_deactivate.nu`
This PR is part of porting all old scripts #221 and includes a set of
modules:
- `data_extraction`
- `examples`
- `duplicates`
## 7 changed files:
### `data_extraction`
- `data_extraction/ultimate_extractor.nu`: removed. Has already been
ported to `modules/data_extraction/ultimate_extractor.nu`
### `duplicates`
- `duplicates/duplicates.nu` -> `modules/duplicates/duplicates.nu`
- `duplicates/example.nu` -> `modules/duplicates/example.nu`
- `duplicates/README.md` -> `modules/duplicates/README.md`: unchanged
### `examples`
- `examples/netstat.nu` -> `modules/examples/netstat.nu`
- `examples/date_in_local_timezones.nu` ->
`modules/examples/date_in_local_timezones.nu`
- `befove_v0.60/assets/core_team.nu`: removed. This table has been
embedded into `date_in_local_timezones.nu`
This PR is part of porting all old scripts #221 and includes a set of
modules:
- `config_management`
- `language`
- `tests`
- `prompt`
## 12 files changed
### `config_management`
This module was removed, because it was related to the old `config.toml`
format
1. `README.md`: removed
2. `config.toml`: removed
3. `startup.nu`: removed
### `language`
4. `playground.nu` : unchanged because this is just `source ...`
5. `std.nu` : unchanged because this is just `source ...`
6. `playground/lib.nu` -> `playground/mod.nu` and all commands have been
exported
7. `std/date.nu` + `export` keyword
### `tests`
This module contained only the usage of `language` module, so I merged
it with `language`
8. `tests/language/std/date.nu` -> `modules/language/tests/date.nu`
9. `main.nu`: removed because it was just `source date.nu`
### `prompt`
10. `git_status_prompt.nu` -> `modules/git_status_prompt.nu` + `export`
keyword
11. `left_and_right_prompt.nu` -> `modules/left_and_right_prompt.nu` +
`export` keyword
12. `README.md` : has been removed as a duplicate of
`modules/prompt/README.md`
This PR is part of porting all old scripts #221 and includes a set of
modules:
- fuzzy -> `modules/fuzzy/fuzzy_command_search.nu`
- ls-mods -> `modules/ls-mods`: `ls-less.nu`, `ls-wide.nu` and
`ls-wide-with-color.nu`
- nu_101 -> `modules/nu_101`: `nothing.nu` and `inner_outer_loop.nu`
Edit: `fuzzy` and `nu_101` have been moved to `sourced`
