Yeah, I don't even know what is causing that
*16 leaf nodes
well it was slow until i redid it :P
PR maybe?
yeah i'll send one
using a single String as a buffer and avoiding creating lots of intermediate
Vecs made it faster
thanks!
*I'll
I think the modal editing thing is something that could be implemented as a plugin, and doesn't necessarily need to be built-in
And a good key binding/resolver system would help, so plugins can hook into that
I've been using Atom a lot recently, and I really like how they've approached it
How's your rope stuff going?
:(
I need to spend some time tidying things up and adding some real docs
As far as functionality, I need to consider mutability (is it desirable at all, if so, what does it look like), API ergonomics, different types of iterators (grapheme clusters, chars, maybe u8s, starting from different places in the rope), and maybe investigate what it would take to have mmap backed leaf nodes
This might be a dumb question, but what's the point of
Mark? It looks like it's just supposed to represent a byte index into a buffer, and is only used to keep track of the top-left character position and the cursor position. If that's true, what is the usize for and why is it always 0? I'm confused in part because the mark hashmap is a property of a buffer, rather than a view.
Marks are used for storing references to places in the buffer. Things like cursor position. Also used for marking the first line the editor should draw to the screen. This is 0 when the first line of the. Buffer is the first line the editor should draw. Say you scroll down a large file though, that number will increase to be the index of the start of the line at the top of the view. Does that make sense?
I think the idea is to also use them for text selection and things too...
Saying that though, not sure why it would be 0 for cursor position? Is that the case when you scroll around too?
And I think my original reasoning for having them on the buffer was that when you switch buffers, you could restore cursor position and stuff to what it was before you switched.
Open to suggestions on all this BTW!
Thanks for the explanation :)
The reason I said that "the usize is always 0" is that Mark is defined like enum Mark { Cursor(usize), DisplayMark(usize) }, and I looked through the code, and found several places where Marks are constructed, and they are all instantiated with a value of zero. I just don't understand what that number is supposed to mean.
What's the advantage of a Mark over a usize that represents a byte index into the buffer?
Also, was iota designed to be able to have multiple views into the same buffer? It seems like it was because of the Arc<Mutex<Buffer>>
Yeah, you can have multiple views for a buffer
At least, that's the plan!
What does
dw do at the moment? I think the text object system was meant to be pretty open ended, so you could basically jump to any point in the document, from any other arbitrary point. Like "the second line down from the cursor" or "the fifth character from the start of the fifth line above the cursor". That sort of thing. The cursor is just one of the positions that can be used as the starting point for a movement. Does that answer your question?
dw deletes from the cursor to the start of the next word. I was just thinking out loud. A text object at the moment represents a mapping from a buffer to a particular character, and I've been playing around with changing it so that it represents a mapping from a buffer to a range of characters like in vim.
The advantage is that mio is already pretty quick and that there are some async libraries built ontop of it, which would make the async calls a bit simpler to use