Re: [dev] Experimental editor

On 17 June 2011 15:24, Martin Kühl <martin.kuehl_AT_gmail.com> wrote:
> If "ex mode" were just a command buffer, you could
> use every piece of functionality your editor provided, maybe even open
> another command buffer operating on the current one.

I'd not even considered this possibility, but you're right, it would
work as a direct result of the command buffer abstraction. You could
even open a dozen windows, SSH into different machines, and
interactively run the same commands on each of them (I think there's a
program which does this), without my having even considered it. All
you need is `X a'.

On 17 June 2011 15:29, Nick <suckless-dev_AT_njw.me.uk> wrote:
> tying things to X is a nasty thing to do. I haven't used it,
> so don't know it's level of suckiness, but might cairo work?

I don't believe Cairo abstracts anything other than drawing (i.e.
keyboard and mouse), so it would have to be Cairo + something.

> But if we're thinking about
> breaking from the terminal, how would remote editing work?

A minimalist remote editing protocol is a todo. It'll basically be
like the sam host, except all editing actually happens locally, only
modifications to the buffer are transmitted, so you don't have any
visible lag besides the initial read. It'll also be simpler, and the
editor won't be dependent on it; so think closer to 9P (only with
efficient in-file insert and so on). That's once we've got the basics
down, though.

On 17 June 2011 17:54, Michael Farnbach <noble.oblige_AT_gmail.com> wrote:
> I don't know that X or tmux have anything more than mark and copy to
> clipboard. The rest is handled by the program in them.

This is true.

> Also the modeless second window isn't a bad idea, but I wonder if it is
> modeless or not.

The modality of windows is debatable. But since we have X I don't
consider it our problem, so long as we don't *add* to the problem.

Thanks,
cls
Received on Fri Jun 17 2011 - 19:10:38 CEST