Re: [dev] Experimental editor

On 13 June 2011 03:25, Leon <leondistefano_AT_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
Received on Mon Jun 13 2011 - 06:12:06 CEST