Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
crespyl
@crespyl
Also, is it just me, or does the bench_delete benchmark take an inordinately long amount of time to complete? The measured times seem reasonable, but the test seems to take on the order of minutes for me.
Adrian
@orangea
here is the result of my benchmark: https://gist.github.com/orangea/1e146b3a679496f3e4eb
oh wow it auto-embedded
crespyl
@crespyl
Yup, stuff like that is why I like Gitter!
I wonder if there's something I can do to minimize that margin of error on the fixup tests
Adrian
@orangea
so the _1000 benchmarks are using a rope that is 1000 chars long and has .fixup_lengths(50, 100) called on it, which means there are 16 nodes total
Yeah, I don't even know what is causing that
*16 leaf nodes
crespyl
@crespyl
Out of curiosity, is your bench_to_string using a rope that is several layers deep, or just one leaf?
Adrian
@orangea
several layers deep
crespyl
@crespyl
Oh cool, I forgot to add a benchmark for that operation, and was afraid it might be slow
Adrian
@orangea
i just tried with a depth=20 rope and there still isn't much of a difference, so i guess i was wrong about it
well it was slow until i redid it :P
crespyl
@crespyl
Hah!
PR maybe?
yeah i'll send one
using a single String as a buffer and avoiding creating lots of intermediate Vecs made it faster
crespyl
@crespyl
Herp derp. That makes sense.
thanks!
crespyl
@crespyl
Weird, it takes my machine ~10 minutes to run the benchmarks when I include bench_delete
Adrian
@orangea
that is very strange O.o
crespyl
@crespyl
I'm running it on a debian VPS atm, but everything else behaves normally. I've have to see if it's any different locally when I get a chance.
*I'll
Greg Chapple
@gchp
considering removing the whole "mode" thing from Iota...
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
crespyl
@crespyl
That would be interesting. Do you still envision modal/vi-like interaction as the default behavior, just with a "user-space" implementation?
Greg Chapple
@gchp
Yeah, exactly!
How's your rope stuff going?
crespyl
@crespyl
I actually haven't done much with it lately
:(
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
Greg Chapple
@gchp
Cool!
Adrian
@orangea
Would it be a good idea to temporarily start using GapBuffer<char> or String instead of GapBuffer<u8> until crespyl's rope library (or anything) is ready so that unicode compatibility can start to be implemented? I think it would make things easier
Greg Chapple
@gchp
Yeah, that sounds like a good idea!
Adrian
@orangea
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.
Greg Chapple
@gchp
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!
Adrian
@orangea

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>>

Greg Chapple
@gchp
Hmm, to be honest, off the top of my head I can't remember what the advantage is :) I'll go back through the commit history and see if something sparks my memory!
Yeah, you can have multiple views for a buffer
At least, that's the plan!
Adrian
@orangea
Here's an idea that I want to put out there: when both an operation and a text object are given, is performing the operation from the cursor to that object ever really useful? For example, are there many instances in vi where one might want to use dw instead of daw or diw?
Greg Chapple
@gchp
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?