search

cessen / ropey

A utf8 text rope for manipulating and editing large texts.
MIT License
1.04k stars 46 forks source link

Add ability to insert rope slices #4

Closed cessen closed 5 years ago

cessen commented 6 years ago

Right now you can only insert &str slices into ropes. However, in an editor it may be useful to insert text from other ropes (e.g. for copy-pasting a large amount of text). Adding the ability to insert rope slices would allow for this.

hcpl commented 6 years ago

The best way to do this is to unify API around an ImmutableText trait, common for &str and RopeSlice. Sadly, I couldn't find such a trait in the wild, so we might need to create a text-traits crate along with resolving this issue. In turn, that crate can also provide forward-compatibility to deal with other text data structures as well.

cessen commented 6 years ago

Having something like an ImmutableText trait would be great, but is somewhat orthogonal to my intent behind this feature. I didn't explain in the issue text thoroughly, but part of the reason for having a separate method that knows that it's dealing with rope slices is that it can deal with them as rope slices and get additional efficiencies out of it. For example, sharing the nodes from the rope slice in a similar fashion as when cloning.

But I agree that having a more generic interface to inserting text would be great. And once specialization hits stable, then it could even just be a single method, with specializations for &str and RopeSlice to make it more efficient.

hcpl commented 6 years ago

For example, sharing the nodes from the rope slice in a similar fashion as when cloning.

Yeah, I also had this in mind when commenting before -- I just forgot that specialization is nightly for now, which makes my proposal a bit less useful :).

Regarding a generic text interface: I think that if Rope/RopeSlice acquires most of the methods from String/str, API bloat will happen if it is decided to have 2 versions (one for String/str and one for Rope/RopeSlice) of each method for efficiency without requiring nightly. So I thought this is the right moment to propose such an idea to prevent a potential ecosystem split in the future.

Though of course, you are the owner of this crate, so whatever decision to choose is up to you.

cessen commented 6 years ago

I'm not too worried about ecosystem split (unless I'm misunderstanding the thrust of what you're getting at). If I make e.g. an insert_rope_slice method now, it can be deprecated later when specialization becomes stable. And insert can switch from taking a &str to taking a generic type with trait ImmutableText or whatnot, without impacting backwards compatibility.

cessen commented 5 years ago

On further thought, and after more experience with Ropey, I now believe that this wouldn't be especially useful. I'm not against adding it, but would like to wait for a real use-case/feature-request to manifest rather than trying to predict how it might theoretically be useful.

So I'm closing this for now. But anyone coming across this: feel free to either re-open or create a new issue if you have a concrete use-case for this.