Re: [dev] [RFC] Design of a vim like text editor

From: Marc André Tanner <>
Date: Sat, 13 Sep 2014 19:38:21 +0200

On Sat, Sep 13, 2014 at 11:06:33AM -0400, Andrew Hills wrote:
> Hi Marc,
> Thank you for the thorough and illustrated RFC. If you have not already
> done so, I suggest you keep this text around with the project.

Good idea, I've added it as README for now.

> > Notice that the common case of appending text to a given piece is fast
> > since, the new data is simply appended to the buffer and the piece length
> > is increased accordingly. In order to keep the number of pieces down,
> > the least recently edited piece is cached and changes to it are done
> > in place (this is the only time buffers are modified in a non-append
> > only way). As a consequence they can not be undone.
> This seems like behavior that will surprise me, and possibly even
> others. (Possibly using it will demonstrate otherwise.) Is there any
> convenient workaround?

This is just an implementation detail. In practice you will always
be able to get back to the state you had either:

 - at the time after your last operator command

 - at an idle period of 3 seconds in either insert or replace mode

As I already mentioned, it would also be possible to add a heuristic
based on the distance between consecutive editing operations. In terms
of API whenever you call text_snapshot(...) you will be able to return
to this state.

> > The history is currently linear, no undo / history tree is implemented.
> Are orphaned pieces (on dead branches) eliminated?

When you undo a few changes and then start adding new ones, the previously
undone pieces are thrown away. That is no branch and hence no tree is

> Is there any useful
> interface for navigating a history tree that would make the feature
> worth having?

vim supports the :earlier, :later commands among other things (see also
:help undo-redo). I believe there is also a plugin to display the history
as some form of a graph/tree. I personally have no use for this stuff.

> > The editor takes a similar regex-based approach to syntax highlighting
> > than sandy and reuses its syntax definitions but always applies them to
> > a "screen full" of text thus enabling multiline coloring.
> How does this work when important parts of the syntax are off of the screen?

At the moment not at all. But you can start reading and coloring a portion
of the text before what actually is displayed in the window. However this
is not currently done.

At some point I will need to take another look at the whole syntax stuff,
it could probably be made a bit more efficient. For example the rules for
multiline comments should be the first to test such that all others are
skipped once a comment is found.

> > The repeat command '.' currently only works for operators. This for
> > example means that inserting text can not be repeated (i.e. inserted
> > again). The same restriction also applies to commands which are not
> > implemented in terms of operators, such as 'o', 'O', 'J' etc.
> Is this intended, or is the vim-like behavior planned?

It is just a result of the current implementation. It would be possible to
promote these commands to self contained operators which would make them
repeatable. I don't know yet what the best way is.

> > + code completion: this should be done as an external process. I will
> > have to take a look at the tools from the llvm / clang project. Maybe
> > dvtm's terminal emulation support could be reused to display an
> > slmenu inside the editor at the cursor position?
> This feature seems unnecessary; do others use this? The last time I had
> code completion was in Eclipse, when I was younger and more foolish, and
> I don't miss it at all.
> > - macro recording
> Macros are one of my most-used Vim features; they are very useful for
> repetitive editing of complex files where regular expressions are more
> of a pain. Even if you have no desire for them, would you accept patches
> to add the feature, or should this list be considered a blacklist?

Yes I will certainly evaluate patches which add other kind of functionality.
It is more a list of stuff which I personally don't (currently?) use/need
and therefore have no particular interest in.

On a technical level for this to work, you would also have to repeat
past commands but to be honest I don't even know what is possible with
 Marc André Tanner >< >< GPG key: CF7D56C0
Received on Sat Sep 13 2014 - 19:38:21 CEST

This archive was generated by hypermail 2.3.0 : Sat Sep 13 2014 - 19:48:07 CEST