[climacs-devel] "Vial" mode for Climacs?

[Troels Henriksen]

"Brad Beveridge" <brad.beveridge at gmail.com> writes:

> Reuse is a slippery, slippery slope, and for me the bottom of that
> slope is implementing a "Viper" mode for Climacs.

That could be interesting - and it would require some
flexibility-enhancing improvements to Climacs, which really can't be
bad.

> So my thinking is that if I want to really be sensible (damn logic!),
> I at least need to figure out how hard it would be to make a Vial mode
> for Climacs. 

I could say that it would be easy, and assume that you want something
half-baked. If you want something really good, something that will not
leave people thinking that Vial is merely a really weird set of
keybindings for Climacs, but actually a Vi-like editor, it's going to
require a lot of code. That code might be fairly simple, though, but I
kind of doubt it.

> A command table essentially maps one or more keystrokes (including
> modified keys) into a function call.

Strictly, a command table can only map a single "gesture" to
"something". Binding multiple keystrokes to a command is implemented
using a rather ingenious technique implemented by Robert Strandh that
uses nested command tables. But this is all properly abstracted away
in a CLIM library called ESA, so you don't really need to care that
much about it.

> I'm not sure how repeats work, but I assume C-u or M-[0-9] prime
> some sort of repeat accumulator.

Yes, you can place "placeholder arguments" in your gesture-binding
definitions that will be replaced by, for instance, the numeric
argument. Also, there is a global accumulator IIRC.

> Vi style editors have at least 3 modes, normal/command, insert, and EX
> mode.  I suspect that each mode will need its own command table,
> probably replacing the 'BASE table in Climacs.

That's not likely to work well - the BASE table really is the base,
and doesn't do much in itself. The higher-level command tables,
including the syntax-specific ones, would override your Vim-like
behavior. You really need a self-contained command table tree I think
(which is the reason for my comment about probably needing a lot of
not-very-complicated code).

> So my basic problem is trying to shoehorn this kind of key matching
> into a table structure that I don't think is a good fit - though it
> could be done by permuting the op-motions I guess.  If I am missing
> something obvious, I'd love to hear about a better way to do the
> op-motion style handling.

I don't think you are missing anything, command tables are not really
suitable for this. In fact, I do not think Vi-like command processing
can be implemented using standard CLIM command processing semantics.

> So I think I have two options:

I have a novel ideal, that relies on some functionality available in
an experimental version of ESA (the library responsible for Climacs
command processing, among other things) I'm working on. Basically, I
define the concept of a "command processor" that is fed gestures and
uses these gestures to look up commands in command tables - really,
what CLIM does by default. However, you can create a new command
processor (all it needs to do is to obey the command processor
protocol) that implements more Vi-like behavior. As it can do
gesture-processing however it likes, it can implement Vi-style
pairings of editing and movement commands. I still recommend using
command tables for lookup, if for nothing else, then because Climacs
and ESA already has some semantics for syntax-specific command
tables. You'd probably also need to wrap many commands, as they
generally expect to be used with the Emacs concept of the region,
instead of with Vi-style movement commands. A simple implementation
might be to temporarily move point and mark to the edges of the region
traversed by the provided movement command.

No matter what, this will require a lot of code and reworking of some
Climacs internals - the current code is not engineered for the
flexibility needed by a proper implementation of a Vi-like editor.

-- 
\  Troels "Athas"
/\ Henriksen