com.raelity.jvi
Class Normal

java.lang.Object
  com.raelity.jvi.Normal

public class Normal
extends Object

Contains the main routine for processing characters in command mode. Communicates closely with the code in ops.c to handle the operators.

This class started with VIM's normal.c. The idea is to work this into something that can be used in a JEditorPane framework to implement vi. So things that are handled by swing text are taken out. Here is a partial list of changes.

• Visual mode has been commented out for now.

nv_*(): functions called to handle Normal and Visual mode commands.
n_*(): functions called to handle Normal mode commands.
v_*(): functions called to handle Visual mode commands.

Constructor Summary

Normal()

Method Summary

static void	displaySelectState(String s)
static void	normal_cmd(char c, boolean toplevel) normal Parse and execute a command in Normal mode.
static void	processInputChar(char c, boolean toplevel) Vi comands can have up to three chunks: buffer-operator-motion.
static void	resetCommand()
static void	v_updateVisualState(ViTextView tv)

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

Normal

public Normal()

Method Detail

processInputChar

public static void processInputChar(char c,
                                    boolean toplevel)

Vi comands can have up to three chunks: buffer-operator-motion.
For example: "a3y4<CR>

• has buffer: "a
• and operator: 3y
• and motion: 4<CR>

The original vim invokes normal 3 times, one for each chunk. The caller had no knowledge of how many chunks there were in a single command, it just called normal in a loop. normal kept control, calling safe_getc as needed, and returned as each chunk was completed. Accumulated information was saved in OPARG. normal detected when a complete command was ready and then executed it, often times in do_pending_op. CMDARG has per chunk information, and OPARG is cleared after each command.

To fit in the swing environment, we want to be able to parse one character at a time in the event thread. This means we have to return after each character. So we must maintain a bunch of "where am i" state information between each character. This is messy, but not too bad. (Only breiefly considered having a separate thread.)

Operator and motion are very similar, they have or sometimes more than one char.

resetCommand

public static void resetCommand()

normal_cmd

public static void normal_cmd(char c,
                              boolean toplevel)

normal Parse and execute a command in Normal mode. This is basically a big switch with the cases arranged in rough categories in the following order:

1. Macros (q, @)
2. Screen positioning commands (^U, ^D, ^F, ^B, ^E, ^Y, z)
3. Control commands (:, , ^L, ^G, ^^, ZZ, *, ^], ^T)
4. Cursor motions (G, H, M, L, l, K_RIGHT, , h, K_LEFT, ^H, k, K_UP, ^P, +, CR, LF, j, K_DOWN, ^N, _, |, B, b, W, w, E, e, $, ^, 0)
5. Searches (?, /, n, N, T, t, F, f, ,, ;, ], [, %, (, ), {, })
6. Edits (., u, K_UNDO, ^R, U, r, J, p, P, ^A, ^S)
7. Inserts (A, a, I, i, o, O, R)
8. Operators (~, d, c, y, >, <, !, =)
9. Abbreviations (x, X, D, C, s, S, Y, &)
10. Marks (m, ', `, ^O, ^I)
11. Register name setting ('"')
12. Visual (v, V, ^V)
13. Suspend (^Z)
14. Window commands (^W)
15. extended commands (starting with 'g')
16. mouse click
17. scrollbar movement
18. The end (ESC)

displaySelectState

public static void displaySelectState(String s)

v_updateVisualState

public static void v_updateVisualState(ViTextView tv)