On Mon, Sep 15, 2014 at 02:21:25PM +0100, Maxime Coste wrote:
> Hello,
>
> Here are a few thought on your design, based on my own experience with Kakoune.
Thanks for sharing them! Kakoune looks interesting. At some later point
I will take a closer look.
> On Sat, Sep 13, 2014 at 04:01:15PM +0200, Marc André Tanner wrote:
> > Text management using a piece table/chain
> > =========================================
> >
> > [...]
>
> While this looks like a nice data structure for editing arbitrary byte
> string, you can get much better actual performances if you decide you write
> a text/code editor.
I'm not sure whether this is actually the case. That is part of the reason
why I wrote it in the first place, to see how it behaves in practice. I'm not
aware of any other console style, open source editors for *nix systems
using a similar data structure (the closest I came was AbiWord).
I find the piece chain rather elegant. In particular the undo/redo
implementation and the fact that it naturally leads to a read only mmap(2)
based solution. That is the buffer management is taken care of by the operating
systems virtual memory subsystem.
> regular text is naturally line/column oriented, and storing it in the form of
> a dynamic array of lines (with lines being simple strings) works very well and
> gives excellent performance once you use (line, column) pairs to reference it.
I agree that this works fine for source code and other small files. However
I'm optimistic that the piece chain will work satisfactory too. Besides there
already exist plenty of editors based on dynamic arrays. I really saw no point
in creating another one (besides the fun, learning experience etc.).
> In practice your user think about text in this line column fashion, which
> implies that your text editing will stay mostly line column centric, so
> things ends up much simpler when the editing backend itself is matching that.
As I said I'm not totally convinced this is actually the case. Especially if
you have to deal with characters which occupy multiple columns etc. Having
a byte based addressing seems to work ok so far. For example I like the fact
that you can write your movements as functions which take the current file
position as argument and return the new one. All completely independent from
the display state.
> That said, this is limited to actual text, arbitrary byte sequences do not
> map well to this, in which case your piece table seems nice.
I agree. But for now I still think the piece table also works fine for text
files.
> > Screen Drawing
> > ==============
> >
> > [...]
> >
> > Window-Management
> > -----------------
> >
> > In principle it would be nice to follow a similar client/server approach
> > as sam/samterm i.e. having the main editor as a server and each window
> > as a separate client process with communication over a unix domain socket.
> >
> > [...]
>
> The client server thing can stay quite simple if you avoid any synchronisation.
> in Kakoune once the connection is done, the client sends keystrokes,
> and the server sends display commands. Once you have your poll event loop
> (which you will endup having if you want to handle anything asynchrounously)
> this integrate very easily.
Yes it doesn't have to be rocket since, but at this stage other things
seem more important. It also depends on what kind of assumpion you make.
For example once you properly want to handle partial read/writes, things
just became rather more complicated.
> > Editor Frontends
> > ================
> >
> > vis a vim like frontend
> > -----------------------
> >
> > [...]
> >
>
> So it seems you are basically targetting very close to vi interface, I am
> always a little sad to see new editors doing that. vi and vim have tons of
> good ideas in them, but the editing model has a lot of room for improvement
> to get a more consistent and regular interface.
This is true to some degree. The problem is that most people are already
familiar with vi(m) (myself included). Therefore the hope is that by sticking
to the vim conventions more contributors will be attracted. As for my personal
needs they are almost covered by the currently implemented functionality.
It would be interesting to know which parts of the editing model you consider
particularly problematic.
> Kakoune is one direction, integrating multi-selection and focusing on
> interactive edition, which gave very good results in term of keystrokes count
> (it beats vim on several vimgolf challenges).
I agree Kakoune seems interesting, I will have to read more about it.
> I expect there are lots of
> alternatives directions to improve the vi-like user interface, and trying
> to improve the implementation without trying to improve the design itself
> seems like a waste.
For me these two things are largely unrelated. A solid foundation should
make it easy to experiment with new editing paradigms. I certainly encourage
people to try different things.
> Anyway, best of luck on your project, writing a code editor is a very
> rewarding experience.
Thanks! Again, I agree.
Cheers,
Marc
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Received on Mon Sep 15 2014 - 21:03:59 CEST