> The editor uses interactive structural regular expressions, somewhat > like sam, only with more visual support. Say you run the command > `x/re/'; a special `match' buffer will open containing the matching > lines and line numbers (and in the case of X & Y, their file names > too), allowing you to jump to those locations. You can then edit and > run commands on these matches (including filtering) and the buffer(s) > will be updated accordingly.
x doesn't necessarily match lines; it chunks the file arbitrarily. The chunks could potentially be huge. Also, another buffer seems unwieldy. Still, perhaps a non-contiguous highlighted "dot" of sorts would be possible, as the only context in which that would occur currently is in the middle of an incomplete x/X/y/Y command. I like the idea of a Sam in which the viewing window responds more quickly to changes in the command window, such that it's practical to navigate and edit entirely from the command window if one so chooses, while still having the viewing window as the focus for one's eyes. This would mean e.g. the dot "chasing" incomplete address regexps (with a partial undo if the command remains incomplete); "a", "i", and "c" causing the viewing window to dynamically update, etc. The main difficulty would be maintaining the conceptual purity of Sam while trying to reduce inefficient keypresses -- the vi-style "f" solution (for example) seems pretty ugly. I'm only an absolute beginner with C, but might try implementing some of these things over the uni break. Leon
