Panic Error in Python with Pyright/Pylsp & Ruff

[thebraingen]

Summary

Had the same error happen using Pylsp. Here is my languages.toml for python:

# PYTHON
[[language]]
name = "python"
language-servers = [ "ruff-lsp", "pyright" ]
auto-format = true

[language-server.pyright.config.python.analysis]
typeCheckingMode = "basic"

[language-server.ruff-lsp]
command = "ruff-lsp"

[language-server.ruff-lsp.config.settings]
args = ["--ignore", "E501"]

[language.formatter]
command = "ruff"
args = ["format", "-"]

https://github.com/helix-editor/helix/assets/12926678/8c43ec30-cbb9-440c-bc03-05278d74351b

Reproduction Steps

I tried this: 1. `hx main.py` 2. Use any function 3. Try to read the documentation inline (without using `-K`), coming back & forth ~3 times I expected this to happen: - Be able to continue/read without a crash Instead, this happened: - Crashes (does not happen if I am using Rust, only has happened to me with Python) ### Helix log

RUST_BACKTRACE=1

``` hx . thread 'main' panicked at 'Attempt to slice past end of RopeSlice: slice end 202, RopeSlice length 201', /Users/brain/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ropey-1.6.1/src/slice.rs:656:9 stack backtrace: 0: _rust_begin_unwind 1: core::panicking::panic_fmt 2: ropey::slice::RopeSlice::slice 3: helix_lsp::util::generate_transaction_from_completion_edit 4: helix_term::ui::completion::Completion::new::{{closure}}::item_to_transaction 5: helix_term::ui::completion::Completion::new::{{closure}} 6: as helix_term::compositor::Component>::handle_event 7: as helix_term::compositor::Component>::handle_event 8: ::handle_event 9: helix_term::compositor::Compositor::handle_event 10: helix_term::application::Application::run::{{closure}} 11: tokio::runtime::park::CachedParkThread::block_on 12: tokio::runtime::context::runtime::enter_runtime 13: tokio::runtime::runtime::Runtime::block_on 14: hx::main note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.```

~/.cache/helix/helix.log

``` 2024-05-05T15:12:06.671 helix_lsp::transport [ERROR] ruff-lsp err <- "Ignoring notification for unknown method \"workspace/didChangeConfiguration\"\n" 2024-05-05T15:12:12.560 helix_lsp::transport [ERROR] ruff-lsp err <- "Ignoring notification for unknown method \"workspace/didChangeConfiguration\"\n" 2024-05-05T15:12:47.351 helix_lsp::transport [ERROR] ruff-lsp err <- "Ignoring notification for unknown method \"workspace/didChangeConfiguration\"\n" 2024-05-05T15:13:17.618 helix_lsp::transport [ERROR] Tried sending response into a closed channel (id=Num(14)), original request likely timed out 2024-05-05T15:13:46.147 helix_lsp::transport [ERROR] ruff-lsp err: <- StreamClosed 2024-05-05T15:13:46.147 helix_lsp [ERROR] client was already removed 2024-05-05T15:13:46.149 helix_lsp::transport [ERROR] pyright err: <- StreamClosed 2024-05-05T15:13:46.149 helix_lsp [ERROR] client was already removed 2024-05-05T15:13:46.364 helix_lsp::transport [ERROR] ruff-lsp err <- "Ignoring notification for unknown method \"workspace/didChangeConfiguration\"\n" 2024-05-05T15:14:59.807 helix_lsp::transport [ERROR] ruff-lsp err <- "Ignoring notification for unknown method \"workspace/didChangeConfiguration\"\n" 2024-05-05T15:15:08.013 helix_lsp::util [WARN] LSP position Position { line: 13, character: 0 } out of range assuming EOF ```

### Platform macOS ### Terminal Emulator Warp ### Installation Method source ### Helix Version helix 24.3 (cfca3088)

[the-mikedavis]

Looking at the backtrace I believe one of the language servers is sending us a range for the completion item that is beyond the end of the document and we need to handle that case when turning completion items into transactions.

[thebraingen]

Looking at the backtrace I believe one of the language servers is sending us a range for the completion item that is beyond the end of the document and we need to handle that case when turning completion items into transactions.

Yes. Python is relatively unusable with helix using the main branch. Can't use any language server without it being unstable. Had to go back to 2cadec0b

[thebraingen]

For some reason, it is fixed and working as-expected if instead of doing :

 fn find_completion_range(text: RopeSlice, replace_mode: bool, cursor: usize) -> (usize, usize) {
        let start = cursor
            - text
                .chars_at(cursor)
                .reversed()
                .take_while(|ch| chars::char_is_word(*ch))
                .count();
        let mut end = cursor;
        if replace_mode {
            end += text
                .chars_at(cursor)
                .skip(1)
                .take_while(|ch| chars::char_is_word(*ch))
                .count()
                + 1;
        }
        (start, end)
    }

as was changed in #10279 We take out the + 1 and leave it as-is.

 fn find_completion_range(text: RopeSlice, replace_mode: bool, cursor: usize) -> (usize, usize) {
        let start = cursor
            - text
                .chars_at(cursor)
                .reversed()
                .take_while(|ch| chars::char_is_word(*ch))
                .count();
        let mut end = cursor;
        if replace_mode {
            end += text
                .chars_at(cursor)
                .skip(1)
                .take_while(|ch| chars::char_is_word(*ch))
                .count();
        }
        (start, end)
    }

I have tested extensively using JS/TS, Rust & Python. This fixes the main issue that was happening before. Note, however, that I previously had only experienced the crashes using Python.

---

There still is an ongoing issue where in Python the next-line gets concatenated to the current line and the next-line's first element (-1) gets replaced if doing an autocomplete, only when using Python. See video:

https://github.com/helix-editor/helix/assets/12926678/861c0ab9-0142-47e9-b7b6-a94f1d6b87f8

• as you can see it doesn't replace a but it does replace print excluding the t

---

Might be worth investigating. I'm playing around with the codebase but I have just now started to get a little bit more familiar with it. @the-mikedavis

[kirawi]

There still is an ongoing issue where in Python the next-line gets concatenated to the current line and the next-line's first element (-1) gets replaced if doing an autocomplete, only when using Python.

Was this when you ran master?

[thebraingen]

There still is an ongoing issue where in Python the next-line gets concatenated to the current line and the next-line's first element (-1) gets replaced if doing an autocomplete, only when using Python.

Was this when you ran master?

Yes, on master.