On Fri, Nov 8, 2013 at 3:14 PM, Edward K. Ream <[email protected]> wrote:
When a regex matches, its components will be parsed, and the components
> sent to the vim-like command given by the corresponding setting.
>
Prototyping vim without changing Leo in any way has been a spectacular
success.
As a result, the regular expression scheme is no more, like
minibuffer abbreviations before the
m :-)
Indeed, after doing the regex prototype I saw that the helper code that
created regexes could more easily (and clearly!) create tables for a simple
state machine. The tables themselves are much simpler, clearer and faster
than using regexes!
These tables will be organized as a dictionary: keys are the first
characters of commands (not including repeat counts and other preliminary
keys); values are lists of tuples representing the next command characters,
if any. For single-character command like '^' the list would be something
like.
('^',((None,vim_caret))),
None indicates that ^ is to executed as soon as it is seen. The name
vim_caret is just for prototyping (or maybe it will be an alias to a more
descriptive name).
This is a fast, flexible scheme. Here is a more complex example,
('z',(
# z- or zb redraw, current line at bottom of window
# z. or zz redraw, current line at center of window
# z<CR> or zt redraw, current line at top of window
# N zh scroll screen N characters to the right
# N zl scroll screen N characters to the left
('\\n',vim_zt),
('.',vim_zz),
('-',vim_zb),
('b',vim_zb),
('h',vim_zh),
('l',vim_zl),
('t',vim_zt),
('z',vim_zz),
))
Some flag or convention will be used for commands like t <char>, where
<char> can be any printable character. It's feasible to make an entry in
the table for every element of char; the convention might be just for the
@data node so the poor user doesn't have to make dozens of sub-entries.
For the prototype, it's trivial to generate sub-entries in a for loop.
So now the plan is:
1. Create tables "by hand" (using prototype scripts) for all of vim's
commands. This will solidify my grasp of the state machine implicitly used
to parse vim commands. I'll look at the vim code for clarification of
subtle issues.
2. Create code that simulates the dispatch of the tables, based on lists of
simulated input that covers all the expected input. I'll edit within vim
itself to clarify subtle issues.
Points 1 and 2 can be done in an @test node. This might happen today.
3. Create a script that will turn text representation of the tables (in an
@data node) into the actual tables.
There will be dozens of entries in the @data node. Presumably, most users
will leave this node largely unchanged.
And then of course, there is the task of writing dozens of vim-oriented
commands.
Edward
P.S. Leo's vim mode promises to be more flexible than vim itself. Python's
ability to change code at execution time virtually guarantees this. There
is no need for a separate build pass! Yes, vim does some hacks for
on-the-fly changes, but Leo's vim-mode-related @data nodes will be more
simpler and more flexible.
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
