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 created. > 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 macros. -- Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0