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

From: Andrew Hills <ahills_AT_ednos.net>
Date: Sat, 13 Sep 2014 11:06:33 -0400

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.

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

> The history is currently linear, no undo / history tree is implemented.

Are orphaned pieces (on dead branches) eliminated? Is there any useful
interface for navigating a history tree that would make the feature
worth having?

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

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

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

Thanks for your work thus far,
Andrew
Received on Sat Sep 13 2014 - 17:06:33 CEST