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
