nomad / crop Goto Github PK

For use-cases like logos::Source, efficient access to raw bytes can be important. Would you be OK with adding a method like ropey::RopeSlice::chunk_at_byte? Not a feature request, just want to know your stance on expanding API in this direction.

Thanks for your work!

I like crop's API and consider using crop in a LSP server, however in LSP offsets can be UTF-8, UTF-16 or UTF-32, and LSP servers must support UTF-16 offsets.

According to crop's README:

crop doesn't currently implement those APIs but adding them would be extremely easy. If you need those features in your application please open an issue describing your use case.

So I open this issue. Hoping you could add UTF-16 and UTF-32 offsets support.

I'm making a text editor, and noticed 'r's are removed from the end of lines when iterating over them with the Lines iterator. I had a look in the crop codebase and found this suspicious looking line:

Take this test as example:

#[test]
fn rope_slice_infinite_loop_line_slice_function() {
    use std::panic::catch_unwind;

    use crate::Rope;

    let r = Rope::from("foo\nbar\r\nbaz\nfoobar\n");
    let s = r.byte_slice(2..17);

    assert_eq!(s.line_slice(..1), "o\n");
    assert_eq!(s.line_slice(1..3), "bar\r\nbaz\n");
    assert_eq!(s.line_slice(3..), "foob");
    // assert_eq!(s.line_slice(4..), "");
    catch_unwind(|| s.line_slice(5..)).unwrap_err();
}

The uncommented line runs indefinitely.
I expected an empty RopeSlice (or a panic).

Hi! This crate is amazing, thank you for your work on it.

I'm curious what the motivation is for having the empty line after a trailing newline not be counted as a line? For context, I'm creating a language server, and when I open an empty document and start writing, the first incremental update I get is roughly "insert X text on line 0". But rope.line(0) on an empty rope just panics, when I would expect it to return an empty RopeSlice.

Is this an outcome of the implementation? Or was Rope created with a specific use case in mind that wanted this behavior?

I've been beavering away learning rust by working on omnikron13/braid, another generic rope implementation.

I'm wondering what benchmarks you might have that would be worth stealing? I already lifted more or less any of the ones from cessen/ropey that I was able to apply to my codebase. =P

Although useful, they don't seem to blend in much unicode, and they're definitely pretty artificial, being composed of Lorem Ipsum text (v.s. for example source code, presumably a primary target for a rope implementation). I'd be very interested, and much appreciative, for extra and perhaps more 'realistic' benchmarks you might be able to propose?

On an only partially related note... Do you think it would be worth attempting to abstract out any 'interface' traits related to accessing these string+ data types? I've been thinking of maybe trying some other 'text editor buffer' type string implementations too at some point, and looking at the few ropes that exist already and such, I wonder if trying to standardise something for plug-n-play use, and benchmarking efforts, might work? Idk, just an idea, lemme know your thoughts.

Hello sir,

Good job on crop!

I was considering using it in my toy editor, however I found out looking around in the API that some things I like in ropey are missing here:

• Rope::is_instance
• Rope::from_reader and Rope::write_to
• RopeSlice::as_str and From<RopeSlice> for Cow<str>
• design.md

Things not in ropey I'd love to use:

• Iterators (esp. Chunks) with offsets (see this)
• byte <-> (line, col) (see this)

What are your thoughts about those API additions? Would you be open to PRs?

Thanks

Is there way to insert bytes by line and column?