On Windows for example the behavior of this function typically diverges
from the usual behavior on Unix. Instead of checking that the inserted
string starts with `'\n'` (untrue for for CRLF line endings) we need to
check that the first grapheme cluster in the string is a line ending.
(All line endings are single grapheme clusters.)
This matches the behavior described by the EditorConfig spec for its
`insert_final_newline` option:
> Editors must not insert newlines in empty files when saving those
> files, even if `insert_final_newline = true`.
Co-authored-by: Axlefublr <101342105+Axlefublr@users.noreply.github.com>
These match the equivalent options in VSCode. `trim_trailing_whitespace`
is also the name used by EditorConfig.
* `trim-final-newlines` trims any extra line endings after the final one
* `trim-trailing-whitespace` trims any trailing whitespace (but not
empty lines)
#12177 changed `insert_newline`'s behavior to trim any trailing
whitespace on a line which came before a cursor. `insert_newline` would
previously never delete text. Even the whitespace stripping behavior in
#4854 worked by inserting text - a line ending at the beginning of the
line. `global_offs`, a variable that tracks the number of characters
inserted between iterations over the existing selection ranges, was not
updated to also account for text deleted by the trimming behavior,
causing cursors to be offset by the amount of trailing space deleted
and causing panics in some cases.
To fix this we need to subtract the number of trimmed whitespace
characters from `global_offs`. `global_offs` must become an `isize`
(was a `usize`) because it may become negative in cases where a lot of
trailing whitespace is trimmed. Integration tests have been added for
each of these cases.
Fixes#12461Fixes#12495Fixes#12539
* don't use backup files with hardlinks
* check if the inodes remain the same in the test
* move funcs to faccess and use AsRawHandle
* use a copy as a backup for hardlinks
* delete backup after copy
Prior to this change, every integration test which wanted its line
endings to be handled transparently across platforms, i.e. test with
the same input that has its platform's line feed characters, converting
the line endings was up to each individual test by calling the
`platform_line` helper function. This significantly increases the amount
of boilerplate one has to copy between all the tests.
However, there are some test cases that need to exert strict control
over the exact input text without being manipulated behind the scenes by
the test framework.
So, with this change, the line feed conversions are factored into
the `TestCase` struct. By default, line endings of the input text
are converted to the platform's native line feed ending, but one can
explicitly specify in their test case when the input text should be left
alone and tested as is.
* Replace FileType::Suffix with FileType::Glob
Suffix is rather limited and cannot be used to match files which have
semantic meaning based on location + file type (for example, Github
Action workflow files). This patch adds support for a Glob FileType to
replace Suffix, which encompasses the existing behavior & adds
additional file matching functionality.
Globs are standard Unix-style path globs, which are matched against the
absolute path of the file. If the configured glob for a language is a
relative glob (that is, it isn't an absolute path or already starts with
a glob pattern), a glob pattern will be prepended to allow matching
relative paths from any directory.
The order of file type matching is also updated to first match on globs
and then on extension. This is necessary as most cases where
glob-matching is useful will have already been matched by an extension
if glob matching is done last.
* Convert file-types suffixes to globs
* Use globs for filename matching
Trying to match the file-type raw strings against both filename and
extension leads to files with the same name as the extension having the
incorrect syntax.
* Match dockerfiles with suffixes
It's common practice to add a suffix to dockerfiles based on their
context, e.g. `Dockerfile.dev`, `Dockerfile.prod`, etc.
* Make env filetype matching more generic
Match on `.env` or any `.env.*` files.
* Update docs
* Use GlobSet to match all file type globs at once
* Update todo.txt glob patterns
* Consolidate language Configuration and Loader creation
This is a refactor that improves the error handling for creating
the `helix_core::syntax::Loader` from the default and user language
configuration.
* Fix integration tests
* Add additional starlark file-type glob
---------
Co-authored-by: Michael Davis <mcarsondavis@gmail.com>
helix-stdx is meant to carry extensions to the stdlib or low-level
dependencies that are useful in all other crates. This commit starts
with all of the path functions from helix-core and the CWD tracking that
lived in helix-loader.
The CWD tracking in helix-loader was previously unable to call the
canonicalization functions in helix-core. Switching to our custom
canonicalization code should make no noticeable difference though
since `std::env::current_dir` returns a canonicalized path with
symlinks resolved (at least on unix).
Tatesa Uradnik
Ryan Mehri
CalebLarsen
Michael Davis
Nikita Revenco
TornaxO7
Skyler Hawthorne
Kirawi
Krishan
Pascal Kuthe
Galen Abell
Em Zhan
Alexis-Lapierre
jazzfool