forked from Mirrors/helix
Loading…
Reference in New Issue
There is no content yet.
Delete Branch 'Mirrors/helix:master'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Deleting a branch is permanent. It CANNOT be undone. Continue?
This is necessary for configurations like: [editor] gutters = ["diagnostics", "line-numbers"] after the toml 0.6.0 dependency update.The purpose of this change is to remove the mutable self borrow on `HighlightIterLayer::sort_key` so that we can sort layers with the correct ordering using the `Vec::sort` function family. `HighlightIterLayer::sort_key` needs `&mut self` since it calls `Peekable::peek` which needs `&mut self`. `Vec::sort` functions only give immutable borrows of the elements to ensure the correctness of the sort. We could instead approach this by creating an eager Peekable and using that instead of `std::iter::Peekable` to wrap `QueryCaptures`: ```rust struct EagerPeekable<I: Iterator> { iter: I, peeked: Option<I::Item>, } impl<I: Iterator> EagerPeekable<I> { fn new(mut iter: I) -> Self { let peeked = iter.next(); Self { iter, peeked } } fn peek(&self) -> Option<&I::Item> { self.peeked.as_ref() } } impl<I: Iterator> Iterator for EagerPeekable<I> { type Item = I::Item; fn next(&mut self) -> Option<Self::Item> { std::mem::replace(&mut self.peeked, self.iter.next()) } } ``` This would be a cleaner approach (notice how `EagerPeekable::peek` takes `&self` rather than `&mut self`), however this doesn't work in practice because the Items emitted by the `tree_sitter::QueryCaptures` Iterator must be consumed before the next Item is returned. `Iterator::next` on `tree_sitter::QueryCaptures` modifies the `QueryMatch` returned by the last call of `next`. This behavior is not currently reflected in the lifetimes/structure of `QueryCaptures`. This fixes an issue with layers being out of order when using combined injections since the old code only checked the first range in the layer. Layers being out of order could cause missing highlights for combined-injections content.* helix-term: send the STOP signal to all processes in the process group From kill(3p): If pid is 0, sig shall be sent to all processes (excluding an unspecified set of system processes) whose process group ID is equal to the process group ID of the sender, and for which the process has permission to send a signal. This fixes the issue of running `git commit`, attempting to suspend helix with ^Z, and then not regaining control over the terminal and having to press ^Z again. * helix-term: use libc directly to send STOP signal * helix-term: document safety of libc::kill * helix-term: properly handle libc::kill's failure I misread the manpage for POSIX `kill` -- it returns `-1` in the failure case, and sets `errno`, which is retrieved via `std::io::Error::last_os_error()`, has its string representation printed out, and then exits with the matching status code (or 1 if, for whatever reason, there is no matching status code). * helix-term: expand upon why we need to SIGSTOP the entire process group Also add a link back to one of the upstream issues.6ae0186ef1into master 2 years ago6ae0186ef1.Step 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Forgejo.