From brad.beveridge at gmail.com Wed Oct 25 16:39:43 2006 From: brad.beveridge at gmail.com (Brad Beveridge) Date: Wed, 25 Oct 2006 09:39:43 -0700 Subject: [climacs-devel] "Vial" mode for Climacs? Message-ID: Hi all, I'm the author of Vial (http://common-lisp.net/project/vial/), a Vi like editor for CL. I've recently gone public, which prompted Troels to hit me with a cluebat :) He asked "Why didn't you use Flexichain?", which is a reasonable question. I answered "Well the project was originally just for fun and to learn CL, but now its got some life it makes sense to reuse FC" Reuse is a slippery, slippery slope, and for me the bottom of that slope is implementing a "Viper" mode for Climacs. But, if I do it I want to call in "Vial" - I like the name, and it needs to be not "Viper". 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 am a total Climacs and McClim newbie, and really pretty new to vanilla CL, so please forgive any particularly dense questions I have. I've skimmed the Climacs code and read about Clim command tables, I think that I have a basic understanding. I'll ramble for a bit below about what I think I know, I'd love it if somebody could correct my misconceptions :) A command table essentially maps one or more keystrokes (including modified keys) into a function call. Defining commands involves a somewhat fancy Clim macro that does most of the work for you. Command tables setup a paradigm of a one to one map: keystrokes map to a single function call. I'm not sure how repeats work, but I assume C-u or M-[0-9] prime some sort of repeat accumulator. 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. Insert mode is trivial. EX mode is probably almost trivial because it is just a minibuffer. Normal mode is a bit harder, I think, and doesn't fit well. Some Vi commands are just single or double keystrokes, eg j k l h - move the cursor dd - delete line The rest involve a two part command, it starts with an op and then has a motion. d{motion} - delete from cursor to the end of motion As far as I can tell, commands fall into either operations, or operation-motion. In my editor I currently solve this with pattern matching. A key is pressed and a regular expression runs, if a match is found in either the OP or MOTION expressions, then the function is just called. So pressing "dd" or "j" is an immediate match and a line is deleted or the cursor moved down a line, respectively. The next table to search is the OP-MOTION expression table, if a match is found then two things happen 1) A region is defined by taking the current point, then executing the specific MOTION. 2) The OP function is called with the created region. Also, everything can be prefixed with a number, hence 2dd, delete 2 lines. d2j, delete from point till two lines down. 2d2q, delete from point till two lines down, then do it again - 4 lines deleted (the "d" op works on whole lines). My code for defining patterns is quite simple: (define-pattern 'motion "j" #'move-forward-line) (define-pattern 'op "dd" #'delete-line) (define-pattern 'op-motion "d" #delete-region) If you've managed to read this far - thanks!! 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. So I think I have two options: 1) Define a command table that replaces 'BASE, and basically does self-insert to redirect all keystrokes to a matching function that I define. Possibly the most straight forward. 2) Define a new McClim command table instance that has the semantics I would like. I have no idea how to do this though :) 3) Do what Viper appears to do: map keys where the make sense, and redirect everything else to a huge switch statement function. I guess this is really equivalent to #1, but uglier :) Thanks, Brad From athas at sigkill.dk Wed Oct 25 22:21:35 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 26 Oct 2006 00:21:35 +0200 Subject: [climacs-devel] "Vial" mode for Climacs? In-Reply-To: (Brad Beveridge's message of "Wed, 25 Oct 2006 09:39:43 -0700") References: Message-ID: <87d58gnij4.fsf@sigkill.dk> "Brad Beveridge" 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 From brad.beveridge at gmail.com Thu Oct 26 05:46:24 2006 From: brad.beveridge at gmail.com (Brad Beveridge) Date: Wed, 25 Oct 2006 22:46:24 -0700 Subject: [climacs-devel] "Vial" mode for Climacs? In-Reply-To: References: <87d58gnij4.fsf@sigkill.dk> Message-ID: > > 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 like the sound of this idea. Is this experimental command processor > in ESA cvs right now? Also, when you say "fed gestures" I assume you > mean that the command processor is getting input from McClim? I should have also asked to please have the experimental code if it isn't in CVS (I can't see it there) Cheers Brad From brad.beveridge at gmail.com Thu Oct 26 05:46:54 2006 From: brad.beveridge at gmail.com (Brad Beveridge) Date: Wed, 25 Oct 2006 22:46:54 -0700 Subject: Fwd: [climacs-devel] "Vial" mode for Climacs? In-Reply-To: References: <87d58gnij4.fsf@sigkill.dk> Message-ID: I mistakenly posted to Troels only. ---------- Forwarded message ---------- From: Brad Beveridge Date: 25-Oct-2006 16:25 Subject: Re: [climacs-devel] "Vial" mode for Climacs? To: Troels Henriksen On 25/10/06, Troels Henriksen wrote: > "Brad Beveridge" writes: > > > 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. I don't use Viper for precisely the reason that it feels half-baked. Vial doesn't need to implement all Vim's features, but must have proper Vi finger feel - otherwise it is not a solution in my mind. > > 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 the problem here is that I want to rebind keys at a very general level, but sub-modes of Climacs will go and blow away my bindings when the more specific mode becomes active? At the same time I want to keep the same modes of Climacs, because modes effect things like syntax as well as key bindings. I would like to prevent sub-modes from breaking the Vial bindings, but keep the other mode features. I also want to provide my own sub-mode maps that _will_ effect the Vial commands. This sounds like something of a thorny problem. Any pointers on where to look in Climacs so that I may begin to understand what work is required here? > > 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 like the sound of this idea. Is this experimental command processor in ESA cvs right now? Also, when you say "fed gestures" I assume you mean that the command processor is getting input from McClim? > 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 I think there is a gap in my understanding here. I don't see how command tables would fit in with a Vi-style command processor module in ESA. > 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. For operations that are line centric, I think it is fair to move the point and create a region that consists of whole lines only. That way Vial mode and Emacs mode should be able to share pretty much all the same editing primitives. > 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. I don't mind a lot of work in the long run, but I'm the type of person who likes/needs gratification early, so I hope that getting something half baked working will be pretty fast :) Cheers Brad From athas at sigkill.dk Thu Oct 26 08:35:44 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 26 Oct 2006 10:35:44 +0200 Subject: Fwd: [climacs-devel] "Vial" mode for Climacs? In-Reply-To: (Brad Beveridge's message of "Wed, 25 Oct 2006 22:46:54 -0700") References: <87d58gnij4.fsf@sigkill.dk> Message-ID: <87hcxr1nkv.fsf@sigkill.dk> "Brad Beveridge" writes: > So the problem here is that I want to rebind keys at a very general > level, but sub-modes of Climacs will go and blow away my bindings when > the more specific mode becomes active? At the same time I want to > keep the same modes of Climacs, because modes effect things like > syntax as well as key bindings. I would like to prevent sub-modes > from breaking the Vial bindings, but keep the other mode features. I > also want to provide my own sub-mode maps that _will_ effect the Vial > commands. This sounds like something of a thorny problem. Indeed, very thorny. The best approach, I think, would be to consider Climacs a set of libraries, instead of trying to actually make it mutable into a Vi-like editor. This would also fit nicely into my overall diabolical plot, which is basically to make Climacs be just a "thin" wrapper over a set of powerful, general and reusable libraries. > Any pointers on where to look in Climacs so that I may begin to > understand what work is required here? Look at the generic function `find-applicable-command-table' in ESA. Methods defined on that function are responsible for the syntax-specific command tables in Climacs. > I like the sound of this idea. Is this experimental command processor > in ESA cvs right now? Also, when you say "fed gestures" I assume you > mean that the command processor is getting input from McClim? Yes, McCLIM ultimately handles the low-level gesture reading, but at some point, the gesture will go through a `process-gesture' generic function for the command processor. The motivation for this was to use the same code for command-loop-based and event-based command processing, but it could be used to implement completely non-CLIM-like command semantics as well, I guess. The experimental ESA is not in CVS, because it breaks Climacs and is used for some otherwise pretty intrusive McCLIM word I'm doing. If you just want to take a look at it, see mcclim-drei/ESA/esa.lisp from http://sigkill.dk/code/mcclim-drei.tar.gz > I think there is a gap in my understanding here. I don't see how > command tables would fit in with a Vi-style command processor module > in ESA. You'd need command-tables to organise commands and have syntax-specific commands under all circumstances. > I don't mind a lot of work in the long run, but I'm the type of person > who likes/needs gratification early, so I hope that getting something > half baked working will be pretty fast :) In that case, I'd recommend that you start out by using Climacs as a library (switch to the Climacs buffer protocol, perhaps the syntaxes, etc) in an independent application, and wait a while before attempting to implement Vial in Climacs. -- \ Troels "Athas" /\ Henriksen From splittist at yahoo.com Thu Oct 26 09:21:03 2006 From: splittist at yahoo.com (John Q Splittist) Date: Thu, 26 Oct 2006 09:21:03 +0000 (UTC) Subject: [climacs-devel] Re: Fwd: "Vial" mode for Climacs? References: <87d58gnij4.fsf@sigkill.dk> <87hcxr1nkv.fsf@sigkill.dk> Message-ID: Troels Henriksen sigkill.dk> writes: > "Brad Beveridge" gmail.com> writes: > > I don't mind a lot of work in the long run, but I'm the type of person > > who likes/needs gratification early, so I hope that getting something > > half baked working will be pretty fast :) > > In that case, I'd recommend that you start out by using Climacs as a > library (switch to the Climacs buffer protocol, perhaps the syntaxes, > etc) in an independent application, and wait a while before attempting > to implement Vial in Climacs. I agree with this. My suggestion would be: * Use the buffer protocol. * Use the parts of the syntaxes that parse and display the buffer. * Make your own application frame, with your own command parser (but look at what ESA gives you for gesture-handling, too), but have panes and buffers inherit from the Climacs ones. * Reuse as much of the functionality underlying the Climacs commands as you can (movement, file handling etc.). If stuff needs to be moved out of a command definition into a supporting function, that is probably a good thing. * Extend the Swine functionality to talk to a remote lisp (: Cheers, JQS From brad.beveridge at gmail.com Thu Oct 26 14:40:51 2006 From: brad.beveridge at gmail.com (Brad Beveridge) Date: Thu, 26 Oct 2006 07:40:51 -0700 Subject: [climacs-devel] Re: Fwd: "Vial" mode for Climacs? In-Reply-To: References: <87d58gnij4.fsf@sigkill.dk> <87hcxr1nkv.fsf@sigkill.dk> Message-ID: On 26/10/06, John Q Splittist wrote: > Troels Henriksen sigkill.dk> writes: > > "Brad Beveridge" gmail.com> writes: > > > I don't mind a lot of work in the long run, but I'm the type of person > > > who likes/needs gratification early, so I hope that getting something > > > half baked working will be pretty fast :) > > > > In that case, I'd recommend that you start out by using Climacs as a > > library (switch to the Climacs buffer protocol, perhaps the syntaxes, > > etc) in an independent application, and wait a while before attempting > > to implement Vial in Climacs. > > I agree with this. > > My suggestion would be: > > * Use the buffer protocol. > > * Use the parts of the syntaxes that parse and display the buffer. > > * Make your own application frame, with your own command parser (but look at > what ESA gives you for gesture-handling, too), but have panes and buffers > inherit from the Climacs ones. > > * Reuse as much of the functionality underlying the Climacs commands as you > can (movement, file handling etc.). If stuff needs to be moved out of a > command definition into a supporting function, that is probably a good thing. > > * Extend the Swine functionality to talk to a remote lisp (: That is certainly the plan. I've already done at least some work with Slime in another partial project I started, Slim-Vim. I'm not having a great time getting a working Vim-like editor with Slime support yet am I? From brad.beveridge at gmail.com Thu Oct 26 15:15:07 2006 From: brad.beveridge at gmail.com (Brad Beveridge) Date: Thu, 26 Oct 2006 08:15:07 -0700 Subject: [climacs-devel] Re: Fwd: "Vial" mode for Climacs? In-Reply-To: References: <87d58gnij4.fsf@sigkill.dk> <87hcxr1nkv.fsf@sigkill.dk> Message-ID: On 26/10/06, Brad Beveridge wrote: > On 26/10/06, John Q Splittist wrote: > > Troels Henriksen sigkill.dk> writes: > > > "Brad Beveridge" gmail.com> writes: > > > > I don't mind a lot of work in the long run, but I'm the type of person > > > > who likes/needs gratification early, so I hope that getting something > > > > half baked working will be pretty fast :) > > > > > > In that case, I'd recommend that you start out by using Climacs as a > > > library (switch to the Climacs buffer protocol, perhaps the syntaxes, > > > etc) in an independent application, and wait a while before attempting > > > to implement Vial in Climacs. > > > > I agree with this. > > > > My suggestion would be: > > > > * Use the buffer protocol. > > > > * Use the parts of the syntaxes that parse and display the buffer. > > > > * Make your own application frame, with your own command parser (but look at > > what ESA gives you for gesture-handling, too), but have panes and buffers > > inherit from the Climacs ones. > > > > * Reuse as much of the functionality underlying the Climacs commands as you > > can (movement, file handling etc.). If stuff needs to be moved out of a > > command definition into a supporting function, that is probably a good thing. > > > > * Extend the Swine functionality to talk to a remote lisp (: > That is certainly the plan. I've already done at least some work with > Slime in another partial project I started, Slim-Vim. I'm not having > a great time getting a working Vim-like editor with Slime support yet > am I? Sorry, I sent that prematurely - fat fingers. From chatting to Troels and some others this morning on #lisp, it appears that the fastest path is to take what I like from Climacs, and do the rest myself. So my current thinking is to distill out the parts of Climacs that fit (I'm hoping to grab: buffer, undo, syntax and editing features). That line of thinking is probably where my future questions will be directed. Cheers Brad