| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
| |
Co-authored-by: krfl <kr.fl@outlook.com>
|
| |
|
| |
Co-authored-by: krfl <kr.fl@outlook.com>
|
| |
|
|
|
|
|
| |
When looking up the runtime/ directory relative to the executable path,
canonicalize the path first in case the executable is a symbolic link.
Fixes #3768
|
| |
|
|
| |
LLDB is marked broken on all arches except for x86_64-linux. With this
change, I can use `nix develop` on aarch64-darwin.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bumps [url](https://github.com/servo/rust-url) from 2.2.2 to 2.3.1.
- [Release notes](https://github.com/servo/rust-url/releases)
- [Commits](https://github.com/servo/rust-url/compare/v2.2.2...v2.3.1)
---
updated-dependencies:
- dependency-name: url
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
|
| |
|
|
|
| |
- Add markup styles
- Replace custom colors with Nord colors
- Clean up code spacing
|
| | |
|
| |
|
|
|
| |
the white space confusion with hyphen
Co-authored-by: Fanda Vacek <fvacek@elektroline.cz>
|
| | |
|
| |
|
|
|
|
|
| |
(#3780)
* chore(ci): remove the strip step from the release CI workflow
* chore(ci): set `profile.release.strip = true` in the release CI workflow
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The tutor file is loaded as .txt which can potentially spawn a
language server. Then the path is unset, but the LS remains active.
This can cause panics since updates are now submitted for a doc
with no path.
As a quick workaround we remove the extension which should avoid
detection.
Fixes #3730
|
| | |
|
| |
|
| |
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
|
| | |
|
| |
|
|
| |
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expands the trigger sources of the release CI workflow (`release.yml`),
allowing the developers to test changes to `.github/workflows/release.yml`
easily. The new trigger sources start the workflow in a "preview" mode, in
which it publishes build outputs as a CI artifact instead of creating a new
release so that they can be manually inspected.
The following events trigger the preview mode:
- Pushing to any branch matching the glob pattern `patch/ci-release-*`.
- Opening a pull request that modifies `.github/workflows/release.yml`.
- Pushing versioning tags to a forked repository.
|
| | |
|
| |
|
|
|
|
|
| |
* Don't change config to default when refreshing invalid config
* Propely handle theme errors with config-reload
* Extract refresh theme into seperate function
|
| | |
|
| |
|
|
|
| |
If you type a nonexistant language an appropriate message will show,
and the language won't be changed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Enable lint option to highlight unused vars, etc.
and take full advantage of the running language server.
|
| |
|
|
|
| |
Add jsonnet-language-server for jsonnet language.
See: https://github.com/grafana/jsonnet-language-server
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Helix is first and foremost a modal editor. Willingness to support non-modal
editing is there, but it is not one that should be encouraged with the default
settings. There are an increasing number of users who are stumbling because
they are trying to use Helix as a non-modal editor, so this is an effort to
encourage new users to stop and take notice that Helix has a different paradigm
than VSCode, Sublime, etc. Users can still add these bindings back to their own
configs if they wish.
|
| |
|
| |
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Around 50 columns for the summary is good because it is often used as
heading or as subject in emails. 72 columns for the body is generally
good because some tools do not wrap long lines (`git log` with pager
`less` is a good example). Helix's `:reflow` command is really good to
help with the second point.
Linux kernel documentation says:
> For these reasons, the ``summary`` must be no more than 70-75
> characters, and it must describe both what the patch changes, as well
> as why the patch might be necessary. It is challenging to be both
> succinct and descriptive, but that is what a well-written summary
> should do.
Source:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n627
tpope:
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Commit message style guide for Git:
https://commit.style/
|
| |
|
| |
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
|
| | |
|
| | |
|
| |
|
| |
If formatting fails, report error to log and save without formatting.
|
| | |
|
| |
|
|
|
|
|
|
| |
* avoid coloring `identifier`s globally
* fix function application when not part of `select_expression`
* add `has_attribute_expression` highlighting
* fix precendence for interpolation, which should be after select
* highlight `@` as delimiter
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
By simply placing a comment with the name of the desired language just
before a multi-line string, that language will be injected.
Also, common functions and attributes which are expected to be shell
code are automatically injected.
|
