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
Received on Sat Sep 13 2014 - 19:38:21 CEST