I went to add in `zprofile` to the bash language config to get syntax
highlighting for it. After adding it in, Zed was still not highlighting
the file. I checked and saw that we are using `Path::extension()` in
`language_for_file()`, which [returns `None` when a file's name begins
with a
`.`](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.extension),
such as in the case of `.zprofile`. This PR adds a custom method, with
some tests, that just tries to grab the last component in the file name
if `Path::extension` returns `None`. Not sure if `ext` is the best name,
but I can't use `extension`.
Maybe this method should be called `extension_or_hidden_file_name()`?
Release Notes:
- Fixed a bug where language detection would fail for files starting
with `.` in their names.
- Added syntax highlighting for `.zprofile` files
When editing rust code, the project diagnostics view sometimes fails to
update, so that you have to close the view and re-open it to see the
correct state.
This PR fixes one possible cause of that problem. There was an async
step in between *receiving* diagnostics from the language server and
updating the diagnostics, due to an async call to
`LspAdapter::process_diagnostics`. This could cause the following
sequence of events to happen:
1. Rust-analyzer sends us new diagnostics for a file `a.rs`
2. We call `process_diagnostics` with those diagnostics
3. Rust-analyzer sends us a `WorkDoneProgress` message, indicating that
the "flycheck" (aka `cargo check`) process has completed
4. We update the project diagnostics view due to this message.
5. The `process_diagnostics` call for `a.rs` completes
6. 💥 We have the new diagnostics for `a.rs`, but do not update the
project diagnostics view again.
This PR fixes this bug by simply making `process_diagnostics`
synchronous. There is no I/O or expensive computation happening in that
method. If we need to make it asynchronous in the future, we need to
introduce a queue that ensures that `publishDiagnostics` and
`workDoneProgress` messages are processed serially.
Release Notes:
- Fixed a bug where the project diagnostics view would sometimes fail to
update properly when using Rust-analyzer.
Instead of returning a usize for the window id, I'm instead returning a
`WindowHandle<V: View>` where `V` is the type of the window's root view.
@as-cii helped me with a cool technique using generic associated types
where methods on `WindowHandle` can return either T or Option<T>
depending on the `BorrowWindowContext::Result` associated type.
Some example usage...
```rs
let window = cx.add_window(|cx| MyView::new(cx));
let my_view = window.root(cx); // If cx is TestAppContext, returns MyView. Otherwise returns Option<MyView>, because the window could be closed.
```
This isn't insanely beneficial on its own, but I think it will help
clean up our testing story. I'm planning on making `window` more useful
in tests for laying out elements, etc.
- [x] Rework tests that call `add_window` 😅 to expect only a window in
return.
- [x] Get tests passing
- [x] 🚬 test
This adds rudimentary language support for the Nix expression language,
through tree-sitter-nix.
I spent a little bit of time trying to add support for one of the Nix
language servers too, but wasn't able to get any of them running
reliably without crashing, and so I've opted to stick to just the
tree-sitter grammar for now.
View handles are window specific but this global will be doing things
in all windows, that would cause a panic when it attempted to update
a status bar mode indicator in a background window
Co-Authored-By: Mikayla Maki <mikayla@zed.dev>
One of the problems we had is that the status_bar shows a gap between
items, and we want to not add an additional gap for an invisible status
indicator.
