Re: [Cgdb-devel] CGDB GPL version.

[Gilboa D. <gi...@gm...>]

On Sun, 2007-08-26 at 14:20 -0400, Bob Rossi wrote:
> On Sun, Aug 26, 2007 at 08:12:49PM +0300, Gilboa Davara wrote:
> > On Sun, 2007-08-26 at 11:55 -0400, Bob Rossi wrote:
> > > On Sun, Aug 26, 2007 at 05:34:57PM +0300, Gilboa Davara wrote:
> > > > Short question: What the is the GPL version under which cgdb is
> > > > released?
> > > > (GPLv2 or above, GPLv2, etc?)
> > > 
> > > Hi,
> > > 
> > > I don't think we ever really put any thought into it. You can assume
> > > it's licensed under either of those terms as far as I'm concerned.
> > > 
> > > Bob Rossi
> > 
> > OK. I'll put it up as GPLv2 or above.
> > 
> > P.S. Did you have any chance to take a log at the mock code I sent
> > yesterday?
> > (I'm doing a mock code just to approve the general concept)
> 
> Hi Gilboa,
> 
> I did, i'm thinking about if that approach is worth while for cgdb at
> the moment. I've done more thinking about the roadmap for CGDB since we
> talked last.
> 
> cgdb is getting closer to the .7.0, which will signify that the
> map/macro support is ready for prime time use. This represents the
> design, implementation and use of libkui.
> 
> All of the .7 release will be focused on getting the next higher level
> of key binding into cgdb. Originally this was called libcex, to
> represent 'lib cgdb ex'. However, I'm thinking that name is going to
> change as I'm not sure it is appropriate anymore. I'm not exactly sure
> what I'm going to make this API accomplish. I have 2 choices,
> 
>   - Allow cgdb to capture multiple keys and bind them to a single 
>     piece of hard coded functionality in cgdb. Think of how you move 
>     windows in vim. <Ctrl-w>j is multiple keys, but translates to a 
>     single command. This approach has the disadvantage that the user
>     can't tell cgdb what keys map to what commands. It has the 
>     advantage that while the user is typing a command, cgdb can pick
>     up on the state of the command, and do specific things. Think
>     about 'd/foo<Enter>' in vim. The d says 'delete the following text'.
>   - Allow the user to fully specify what key or set of keys translates
>     into what cgdb command. This would be a key/value pair in a piece
>     of configuration. This is how mutt handles this. The advantage to
>     this is that the user can specify any set of keys to make cgdb do
>     what they want. Potentially down the road someone could make an
>     emacs binding mode. The downside is, it would be more difficult 
>     than a key/value pair implementation in order to provide context
>     support for commands like 'd/foo<Enter>'. Although it is possible.
> 
> So, with that said, the next series of releases will basically undo the
> work that you are doing here. Maybe you should just send in a patch that
> adds supports for the new keys you want in the existing infrastructure.
> Please feel free to persuade me otherwise.

.... It sounds reasonable not do a mini-revolution in the key-mapping
code seconds before you are about to do a full revolution in the same
code.

Either way, I'll send out a series of TGDB_XXX and front-end enhancement
patches that will add a couple of additional commands to the :cgdb
interface.

> 
> One other thought, how does your implementation allow multiple keys to
> bind to the same command?

Most likely hard coded. (Using the existing hard-coded values)
Creating a fully dynamic, multiple-key-supporting system (ALA emacs)
should require a lot of work... and I wonder if it is even required -
read: cgdb users are most likely (IMHO, at least) vim users that want a
vim-like interface for their favorite (?) debugger and in turn, will
most likely use the :cgdb (:vim like) interface.
Never the less, my test group is composed by my team-mates (who love
cgdb ;)) and myself... so... well, did I say IMHO?

- Gilboa