On 13 June 2011 03:25, Leon <leondistef...@gmail.com> wrote: > x doesn't necessarily match lines; it chunks the file arbitrarily. The > chunks could potentially be huge.
Of course; I just meant the matches and their addresses. > 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. It's possible, though there seems something very powerful about having all the matches in one view, perhaps folded to a few lines if they are too big, etc -- especially if the matches span multiple files. Certainly, if you select some text and run `x' on it it ought to dot matches within that, not spawn a whole new view. I suppose the match view should only appear if, say, you are operating on multiple files. > 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 could be useful, though I suspect a mixture of the two would be the most efficient. I will probably spend most of my time interacting with the view, switching over to the command pane for structural regular expressions. > 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. This sort of thing is secondary to the editor proper, but I would like this to be possible. I'm also keen to make substitutions similarly interactive: as you type the match component it highlights matches, with (pastel-)coloured submatches, and when you type the replacement it could demonstrate the changes, or so. As I say, these are closer to finishing touches, and we've barely got anything yet. ;) Still, it's useful to establish our direction now. > 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. Yeah, this is why I've been hoping to stay modeless, and why I've opted for archy's `leaping'. Unfortunately, power and purity seem mutually exclusive in some cases, in which case it's a difficult decision. For example, the command composition quasimode I'm unsure about: it would be powerful, but also very `vi' (and quite unlike the sam command language, to which ours will be similar). > I'm only an absolute beginner with C, but might try implementing some > of these things over the uni break. You'd be welcome to help out with this, though these are very early days. Thanks, cls
