4 ms·

> there's no real need to make your implementation more complicated than a single array Yeah, good luck enabling line numbers in such an editor. In Emacs, whi

by bryal 7y ago

> there's no real need to make your implementation more complicated than a single array Yeah, good luck enabling line numbers in such an editor. In Emacs, which uses a gap-buffer for storing text, line numbers have had notoriously slow. It's gotten a bit better lately, but suffice to say, a naïve flat array / gap-buffer approach is not good enough for some relatively common scenarios even on modern hardware.

nine_k 7y ago
But line numbers are trivial to update when a gap buffer needs a move. A list of strings is more elegant, of course, where only the line being edited becomes a gap buffer. It taxes the allocator a bit more, though, which might be a concern on computers of the time when Emacs was born.
BurningFrog 7y ago
That's a problem to deal with when/if you need to add line numbers. Not a minute before that!
- CuriouslyC 7y ago
  While that is true to an extent, I've made a lot of money cleaning up after people that didn't architect and design their code to cleanly grow into a fairly obvious potential use case, requiring major rewrites. It isn't a premature optimization to avoid walling yourself into a corner..
  - BurningFrog 7y ago
    This is a complex and nuanced topic. I agree strongly with designing your code so it's easily changeable into whatever new features are needed. This is much easier said than done, and I don't know if anyone has written well about the tricks of that trade. But anyway, if you have that kind of code, swapping out whatever you need to make line numbers happen is no more work later than sooner. Code bases with features implemented that are never used, but you still have to keep working through all changes, because someone imagines it will be a real requirement someday, are what my nightmares are made of.
    - jstimpfle 7y ago
      It's all about the interfaces. More performant solutions require (in general) more complex interfaces. If your application has grown as long as it could with the simple implementation, and now it is all too slow, chances are there's a lot of code depending on the interface. If your interface (and the implementation) is too simplistic, then all of that code will need rearchitecting, too.
jstimpfle 7y ago
I don't think there should be a problem with line numbers. I would make two helper arrays containing the indices of the new-line characters, corresponding to the two gap buffer text arrays (new-line positions are sorted ascending for the first array, descending for the second array). Speaking as someone who's gone all the way from implementing a Red-black tree to making a rope data structure using the RB tree, to making a text editor that can edit almost arbitrarily large text files (dozens of gigabytes) without user-perceivable latency ;-)
userbinator 7y ago
I suspect that slowness is due to something else; remember that computers these days can execute a few billion instructions per second. I've written code to do word wrapping, and it was surprising how fast it was. Line numbers are similarly complex.
- srtjstjsj 7y ago
  We expect modern computers to do something more than just run a full-screen text editor.

by bryal 7y ago

nine_k 7y ago

But line numbers are trivial to update when a gap buffer needs a move. A list of strings is more elegant, of course, where only the line being edited becomes a gap buffer. It taxes the allocator a bit more, though, which might be a concern on computers of the time when Emacs was born.

BurningFrog 7y ago

That's a problem to deal with when/if you need to add line numbers. Not a minute before that!

CuriouslyC 7y ago
While that is true to an extent, I've made a lot of money cleaning up after people that didn't architect and design their code to cleanly grow into a fairly obvious potential use case, requiring major rewrites. It isn't a premature optimization to avoid walling yourself into a corner..
- BurningFrog 7y ago
  This is a complex and nuanced topic. I agree strongly with designing your code so it's easily changeable into whatever new features are needed. This is much easier said than done, and I don't know if anyone has written well about the tricks of that trade. But anyway, if you have that kind of code, swapping out whatever you need to make line numbers happen is no more work later than sooner. Code bases with features implemented that are never used, but you still have to keep working through all changes, because someone imagines it will be a real requirement someday, are what my nightmares are made of.
  - jstimpfle 7y ago
    It's all about the interfaces. More performant solutions require (in general) more complex interfaces. If your application has grown as long as it could with the simple implementation, and now it is all too slow, chances are there's a lot of code depending on the interface. If your interface (and the implementation) is too simplistic, then all of that code will need rearchitecting, too.

jstimpfle 7y ago

I don't think there should be a problem with line numbers. I would make two helper arrays containing the indices of the new-line characters, corresponding to the two gap buffer text arrays (new-line positions are sorted ascending for the first array, descending for the second array). Speaking as someone who's gone all the way from implementing a Red-black tree to making a rope data structure using the RB tree, to making a text editor that can edit almost arbitrarily large text files (dozens of gigabytes) without user-perceivable latency ;-)

userbinator 7y ago

I suspect that slowness is due to something else; remember that computers these days can execute a few billion instructions per second. I've written code to do word wrapping, and it was surprising how fast it was. Line numbers are similarly complex.

srtjstjsj 7y ago
We expect modern computers to do something more than just run a full-screen text editor.