Thread: [Cgdb-devel] Patch: Additional vim-prompt commands/short-cuts.
Brought to you by:
bobbybrasko,
crouchingturbo
Menu
▾
▴
cgdb-devel
|
From: Gilboa D. <gi...@gm...> - 2008-05-07 08:13:53
Attachments:
a2-tgdb-switch-command.patch
additional-commands.patch
|
Hello all, I'm trying to add some missing functionality (as in, required by my team-mates) to cgdb's vim-prompt. Patch 1: Replace the a2-tgdb enum_cmd->gdb_cmd conversion with easier to hack switch/case. Patch 2: Additional vim-prompt commands and shortcuts. - Gilboa |
|
From: Gilboa D. <gi...@gm...> - 2008-05-07 08:35:08
Attachments:
a2-tgdb-switch-command.patch
|
On Wed, 2008-05-07 at 11:13 +0300, Gilboa Davara wrote: > Hello all, > > I'm trying to add some missing functionality (as in, required by my > team-mates) to cgdb's vim-prompt. > > Patch 1: Replace the a2-tgdb enum_cmd->gdb_cmd conversion with easier to > hack switch/case. > > Patch 2: Additional vim-prompt commands and shortcuts. > > - Gilboa Patch0: Fixed wording. (Bad-piglish-day) P.S. I remember sending such a patch in the past; though I don't remember what happened to it. - Gilboa |
|
From: Bob R. <bob...@co...> - 2008-05-08 00:31:45
|
On Wed, May 07, 2008 at 11:13:41AM +0300, Gilboa Davara wrote:
> Hello all,
Hi Gilboa!
> I'm trying to add some missing functionality (as in, required by my
> team-mates) to cgdb's vim-prompt.
>
> Patch 1: Replace the a2-tgdb enum_cmd->gdb_cmd conversion with easier to
> hack switch/case.
Looks good, thanks.
> Patch 2: Additional vim-prompt commands and shortcuts.
> diff -X patch/diff.exclude -ur cgdb/cgdb/src/cgdbrc.c cgdb-new/cgdb/src/cgdbrc.c
> --- cgdb/cgdb/src/cgdbrc.c 2008-05-07 09:12:25.000000000 +0300
> +++ cgdb-new/cgdb/src/cgdbrc.c 2008-05-07 10:11:40.000000000 +0300
> @@ -175,7 +175,7 @@
> /* edit */ { "e", command_source_reload, 0 },
> /* focus */ { "focus", command_do_focus, 0 },
> /* help */ { "help", command_do_help, 0 },
> - /* highlight */ { "highlight", command_parse_highlight,0 },
> + /* highlight */ { "highlight", command_parse_highlight,0 },
> /* highlight */ { "hi", command_parse_highlight,0 },
> /* imap */ { "imap", command_parse_map, 0 },
> /* imap */ { "im", command_parse_map, 0 },
> @@ -191,10 +191,18 @@
> /* unmap */ { "unmap", command_parse_unmap, 0 },
> /* unmap */ { "unm", command_parse_unmap, 0 },
> /* continue */ { "continue", command_do_tgdbcommand, TGDB_CONTINUE },
> + /* continue */ { "c", command_do_tgdbcommand, TGDB_CONTINUE },
> /* finish */ { "finish", command_do_tgdbcommand, TGDB_FINISH },
> + /* finish */ { "f", command_do_tgdbcommand, TGDB_FINISH },
> /* next */ { "next", command_do_tgdbcommand, TGDB_NEXT },
> + /* next */ { "n", command_do_tgdbcommand, TGDB_NEXT },
> /* run */ { "run", command_do_tgdbcommand, TGDB_RUN },
> - /* step */ { "step", command_do_tgdbcommand, TGDB_STEP }
> + /* run */ { "r", command_do_tgdbcommand, TGDB_RUN },
> + /* kill */ { "kill", command_do_tgdbcommand, TGDB_KILL },
> + /* kill */ { "k", command_do_tgdbcommand, TGDB_KILL },
> + /* step */ { "step", command_do_tgdbcommand, TGDB_STEP },
> + /* step */ { "s", command_do_tgdbcommand, TGDB_STEP },
> + /* start */ { "start", command_do_tgdbcommand, TGDB_START }
What do we all think about this? There is a problem where :f and :n
actually mean something in vim. So, if we use them for cgdb,
we can never implement the underlying vim commands. Does anyone care?
> diff -X patch/diff.exclude -ur cgdb/tgdb/annotate-two/src/a2-tgdb.c cgdb-new/tgdb/annotate-two/src/a2-tgdb.c
> --- cgdb/tgdb/annotate-two/src/a2-tgdb.c 2008-05-07 09:57:20.000000000 +0300
> +++ cgdb-new/tgdb/annotate-two/src/a2-tgdb.c 2008-05-07 09:59:01.000000000 +0300
> @@ -384,9 +384,16 @@
> case TGDB_NEXT:
> return "next";
>
> + case TGDB_START:
> + return "start";
> +
> case TGDB_RUN:
> return "run";
>
> + case TGDB_KILL:
> + /* Awful hack around send limitation. Should work never the less :) */
> + return "set confirm no\n kill\n set confirm yes";
Sorry Gilboa, I can't accept this into cgdb. What problem where you
trying to work around?
Thanks,
Bob Rossi
|
|
From: Gilboa D. <gi...@gm...> - 2008-05-08 08:13:53
|
On Wed, 2008-05-07 at 20:31 -0400, Bob Rossi wrote:
> On Wed, May 07, 2008 at 11:13:41AM +0300, Gilboa Davara wrote:
> > Hello all,
>
> Hi Gilboa!
>
> > I'm trying to add some missing functionality (as in, required by my
> > team-mates) to cgdb's vim-prompt.
> >
> > Patch 1: Replace the a2-tgdb enum_cmd->gdb_cmd conversion with easier to
> > hack switch/case.
>
> Looks good, thanks.
>
> > Patch 2: Additional vim-prompt commands and shortcuts.
> > diff -X patch/diff.exclude -ur cgdb/cgdb/src/cgdbrc.c cgdb-new/cgdb/src/cgdbrc.c
> > --- cgdb/cgdb/src/cgdbrc.c 2008-05-07 09:12:25.000000000 +0300
> > +++ cgdb-new/cgdb/src/cgdbrc.c 2008-05-07 10:11:40.000000000 +0300
> > @@ -175,7 +175,7 @@
> > /* edit */ { "e", command_source_reload, 0 },
> > /* focus */ { "focus", command_do_focus, 0 },
> > /* help */ { "help", command_do_help, 0 },
> > - /* highlight */ { "highlight", command_parse_highlight,0 },
> > + /* highlight */ { "highlight", command_parse_highlight,0 },
> > /* highlight */ { "hi", command_parse_highlight,0 },
> > /* imap */ { "imap", command_parse_map, 0 },
> > /* imap */ { "im", command_parse_map, 0 },
> > @@ -191,10 +191,18 @@
> > /* unmap */ { "unmap", command_parse_unmap, 0 },
> > /* unmap */ { "unm", command_parse_unmap, 0 },
> > /* continue */ { "continue", command_do_tgdbcommand, TGDB_CONTINUE },
> > + /* continue */ { "c", command_do_tgdbcommand, TGDB_CONTINUE },
> > /* finish */ { "finish", command_do_tgdbcommand, TGDB_FINISH },
> > + /* finish */ { "f", command_do_tgdbcommand, TGDB_FINISH },
> > /* next */ { "next", command_do_tgdbcommand, TGDB_NEXT },
> > + /* next */ { "n", command_do_tgdbcommand, TGDB_NEXT },
> > /* run */ { "run", command_do_tgdbcommand, TGDB_RUN },
> > - /* step */ { "step", command_do_tgdbcommand, TGDB_STEP }
> > + /* run */ { "r", command_do_tgdbcommand, TGDB_RUN },
> > + /* kill */ { "kill", command_do_tgdbcommand, TGDB_KILL },
> > + /* kill */ { "k", command_do_tgdbcommand, TGDB_KILL },
> > + /* step */ { "step", command_do_tgdbcommand, TGDB_STEP },
> > + /* step */ { "s", command_do_tgdbcommand, TGDB_STEP },
> > + /* start */ { "start", command_do_tgdbcommand, TGDB_START }
>
>
> What do we all think about this? There is a problem where :f and :n
> actually mean something in vim. So, if we use them for cgdb,
> we can never implement the underlying vim commands. Does anyone care?
I wonder if this could be use toggle-able. (if any when cgdb gets buffer
and print support)
set purevimmode yes/no
>
> > diff -X patch/diff.exclude -ur cgdb/tgdb/annotate-two/src/a2-tgdb.c cgdb-new/tgdb/annotate-two/src/a2-tgdb.c
> > --- cgdb/tgdb/annotate-two/src/a2-tgdb.c 2008-05-07 09:57:20.000000000 +0300
> > +++ cgdb-new/tgdb/annotate-two/src/a2-tgdb.c 2008-05-07 09:59:01.000000000 +0300
> > @@ -384,9 +384,16 @@
> > case TGDB_NEXT:
> > return "next";
> >
> > + case TGDB_START:
> > + return "start";
> > +
> > case TGDB_RUN:
> > return "run";
> >
> > + case TGDB_KILL:
> > + /* Awful hack around send limitation. Should work never the less :) */
> > + return "set confirm no\n kill\n set confirm yes";
>
> Sorry Gilboa, I can't accept this into cgdb. What problem where you
> trying to work around?
>
If you issue a 'kill' command, you get a confirmation dialog that cannot
be disable (within gdb). The same is true for start and run.
In theory, I can issue the run/start/kill gdb command and then switch to
the gdb window for the user input.
However, this created what-looked-to-me-like a horrible layering
violation. (cgdb shouldn't be forced to understand the inner-workings of
the tgdb/gdb layer)
A better solution will be to create a tgdb->cgdb callback that's being
called by tgdb if the lower level requires input. While this, again,
does present a certain layering problem - it should be less intrusive.
> Thanks,
> Bob Rossi
- Gilboa
|
|
From: Bob R. <bob...@co...> - 2008-05-17 01:31:56
|
On Thu, May 08, 2008 at 11:13:44AM +0300, Gilboa Davara wrote:
>
> > > Patch 2: Additional vim-prompt commands and shortcuts.
> > > diff -X patch/diff.exclude -ur cgdb/cgdb/src/cgdbrc.c cgdb-new/cgdb/src/cgdbrc.c
> > > --- cgdb/cgdb/src/cgdbrc.c 2008-05-07 09:12:25.000000000 +0300
> > > +++ cgdb-new/cgdb/src/cgdbrc.c 2008-05-07 10:11:40.000000000 +0300
> > > @@ -175,7 +175,7 @@
> > > /* edit */ { "e", command_source_reload, 0 },
> > > /* focus */ { "focus", command_do_focus, 0 },
> > > /* help */ { "help", command_do_help, 0 },
> > > - /* highlight */ { "highlight", command_parse_highlight,0 },
> > > + /* highlight */ { "highlight", command_parse_highlight,0 },
> > > /* highlight */ { "hi", command_parse_highlight,0 },
> > > /* imap */ { "imap", command_parse_map, 0 },
> > > /* imap */ { "im", command_parse_map, 0 },
> > > @@ -191,10 +191,18 @@
> > > /* unmap */ { "unmap", command_parse_unmap, 0 },
> > > /* unmap */ { "unm", command_parse_unmap, 0 },
> > > /* continue */ { "continue", command_do_tgdbcommand, TGDB_CONTINUE },
> > > + /* continue */ { "c", command_do_tgdbcommand, TGDB_CONTINUE },
> > > /* finish */ { "finish", command_do_tgdbcommand, TGDB_FINISH },
> > > + /* finish */ { "f", command_do_tgdbcommand, TGDB_FINISH },
> > > /* next */ { "next", command_do_tgdbcommand, TGDB_NEXT },
> > > + /* next */ { "n", command_do_tgdbcommand, TGDB_NEXT },
> > > /* run */ { "run", command_do_tgdbcommand, TGDB_RUN },
> > > - /* step */ { "step", command_do_tgdbcommand, TGDB_STEP }
> > > + /* run */ { "r", command_do_tgdbcommand, TGDB_RUN },
> > > + /* kill */ { "kill", command_do_tgdbcommand, TGDB_KILL },
> > > + /* kill */ { "k", command_do_tgdbcommand, TGDB_KILL },
> > > + /* step */ { "step", command_do_tgdbcommand, TGDB_STEP },
> > > + /* step */ { "s", command_do_tgdbcommand, TGDB_STEP },
> > > + /* start */ { "start", command_do_tgdbcommand, TGDB_START }
> >
> >
> > What do we all think about this? There is a problem where :f and :n
> > actually mean something in vim. So, if we use them for cgdb,
> > we can never implement the underlying vim commands. Does anyone care?
>
> I wonder if this could be use toggle-able. (if any when cgdb gets buffer
> and print support)
> set purevimmode yes/no
I've been busy. I've decided just to accept all of these changes for
now. I'll deal with this issue at a later point.
> > > diff -X patch/diff.exclude -ur cgdb/tgdb/annotate-two/src/a2-tgdb.c cgdb-new/tgdb/annotate-two/src/a2-tgdb.c
> > > --- cgdb/tgdb/annotate-two/src/a2-tgdb.c 2008-05-07 09:57:20.000000000 +0300
> > > +++ cgdb-new/tgdb/annotate-two/src/a2-tgdb.c 2008-05-07 09:59:01.000000000 +0300
> > > @@ -384,9 +384,16 @@
> > > case TGDB_NEXT:
> > > return "next";
> > >
> > > + case TGDB_START:
> > > + return "start";
> > > +
> > > case TGDB_RUN:
> > > return "run";
> > >
> > > + case TGDB_KILL:
> > > + /* Awful hack around send limitation. Should work never the less :) */
> > > + return "set confirm no\n kill\n set confirm yes";
> >
> > Sorry Gilboa, I can't accept this into cgdb. What problem where you
> > trying to work around?
> >
>
> If you issue a 'kill' command, you get a confirmation dialog that cannot
> be disable (within gdb). The same is true for start and run.
> In theory, I can issue the run/start/kill gdb command and then switch to
> the gdb window for the user input.
> However, this created what-looked-to-me-like a horrible layering
> violation. (cgdb shouldn't be forced to understand the inner-workings of
> the tgdb/gdb layer)
>
> A better solution will be to create a tgdb->cgdb callback that's being
> called by tgdb if the lower level requires input. While this, again,
> does present a certain layering problem - it should be less intrusive.
This is the only part of the patch I can't accept. I can however,
provide you want a 'map' command that could perhaps accomplish the same
functionality. I'll try to commit this some time early next week. I've
been super busy. Let you know when it goes in.
Thanks,
Bob Rossi
|
|
From: Gilboa D. <gi...@gm...> - 2008-05-17 03:41:20
|
On Fri, 2008-05-16 at 21:31 -0400, Bob Rossi wrote:
> On Thu, May 08, 2008 at 11:13:44AM +0300, Gilboa Davara wrote:
> >
> > > > Patch 2: Additional vim-prompt commands and shortcuts.
> > > > diff -X patch/diff.exclude -ur cgdb/cgdb/src/cgdbrc.c cgdb-new/cgdb/src/cgdbrc.c
> > > > --- cgdb/cgdb/src/cgdbrc.c 2008-05-07 09:12:25.000000000 +0300
> > > > +++ cgdb-new/cgdb/src/cgdbrc.c 2008-05-07 10:11:40.000000000 +0300
> > > > @@ -175,7 +175,7 @@
> > > > /* edit */ { "e", command_source_reload, 0 },
> > > > /* focus */ { "focus", command_do_focus, 0 },
> > > > /* help */ { "help", command_do_help, 0 },
> > > > - /* highlight */ { "highlight", command_parse_highlight,0 },
> > > > + /* highlight */ { "highlight", command_parse_highlight,0 },
> > > > /* highlight */ { "hi", command_parse_highlight,0 },
> > > > /* imap */ { "imap", command_parse_map, 0 },
> > > > /* imap */ { "im", command_parse_map, 0 },
> > > > @@ -191,10 +191,18 @@
> > > > /* unmap */ { "unmap", command_parse_unmap, 0 },
> > > > /* unmap */ { "unm", command_parse_unmap, 0 },
> > > > /* continue */ { "continue", command_do_tgdbcommand, TGDB_CONTINUE },
> > > > + /* continue */ { "c", command_do_tgdbcommand, TGDB_CONTINUE },
> > > > /* finish */ { "finish", command_do_tgdbcommand, TGDB_FINISH },
> > > > + /* finish */ { "f", command_do_tgdbcommand, TGDB_FINISH },
> > > > /* next */ { "next", command_do_tgdbcommand, TGDB_NEXT },
> > > > + /* next */ { "n", command_do_tgdbcommand, TGDB_NEXT },
> > > > /* run */ { "run", command_do_tgdbcommand, TGDB_RUN },
> > > > - /* step */ { "step", command_do_tgdbcommand, TGDB_STEP }
> > > > + /* run */ { "r", command_do_tgdbcommand, TGDB_RUN },
> > > > + /* kill */ { "kill", command_do_tgdbcommand, TGDB_KILL },
> > > > + /* kill */ { "k", command_do_tgdbcommand, TGDB_KILL },
> > > > + /* step */ { "step", command_do_tgdbcommand, TGDB_STEP },
> > > > + /* step */ { "s", command_do_tgdbcommand, TGDB_STEP },
> > > > + /* start */ { "start", command_do_tgdbcommand, TGDB_START }
> > >
> > >
> > > What do we all think about this? There is a problem where :f and :n
> > > actually mean something in vim. So, if we use them for cgdb,
> > > we can never implement the underlying vim commands. Does anyone care?
> >
> > I wonder if this could be use toggle-able. (if any when cgdb gets buffer
> > and print support)
> > set purevimmode yes/no
>
> I've been busy. I've decided just to accept all of these changes for
> now. I'll deal with this issue at a later point.
> > > > diff -X patch/diff.exclude -ur cgdb/tgdb/annotate-two/src/a2-tgdb.c cgdb-new/tgdb/annotate-two/src/a2-tgdb.c
> > > > --- cgdb/tgdb/annotate-two/src/a2-tgdb.c 2008-05-07 09:57:20.000000000 +0300
> > > > +++ cgdb-new/tgdb/annotate-two/src/a2-tgdb.c 2008-05-07 09:59:01.000000000 +0300
> > > > @@ -384,9 +384,16 @@
> > > > case TGDB_NEXT:
> > > > return "next";
> > > >
> > > > + case TGDB_START:
> > > > + return "start";
> > > > +
> > > > case TGDB_RUN:
> > > > return "run";
> > > >
> > > > + case TGDB_KILL:
> > > > + /* Awful hack around send limitation. Should work never the less :) */
> > > > + return "set confirm no\n kill\n set confirm yes";
> > >
> > > Sorry Gilboa, I can't accept this into cgdb. What problem where you
> > > trying to work around?
> > >
> >
> > If you issue a 'kill' command, you get a confirmation dialog that cannot
> > be disable (within gdb). The same is true for start and run.
> > In theory, I can issue the run/start/kill gdb command and then switch to
> > the gdb window for the user input.
> > However, this created what-looked-to-me-like a horrible layering
> > violation. (cgdb shouldn't be forced to understand the inner-workings of
> > the tgdb/gdb layer)
> >
> > A better solution will be to create a tgdb->cgdb callback that's being
> > called by tgdb if the lower level requires input. While this, again,
> > does present a certain layering problem - it should be less intrusive.
>
> This is the only part of the patch I can't accept. I can however,
> provide you want a 'map' command that could perhaps accomplish the same
> functionality.
Far better :)
IMHO customized mapping always beats static ones hands down.
> I'll try to commit this some time early next week. I've
> been super busy. Let you know when it goes in.
OK, thanks.
I'll keep an eye open on cgdb-devel.
P.S. any idea when the next minor/major release is planned.
I rather not push an svn version as a Fedora/RHEL update.
- Gilboa
|
|
From: Bob R. <bob...@co...> - 2008-05-17 10:58:15
|
On Sat, May 17, 2008 at 06:41:12AM +0300, Gilboa Davara wrote: > P.S. any idea when the next minor/major release is planned. > I rather not push an svn version as a Fedora/RHEL update. I would like to do one very soon. There are a couple of bug fixes that should get released. Perhaps in early June. It'll just be a minor release however. Thanks, Bob Rossi |
|
From: Gilboa D. <gi...@gm...> - 2008-05-17 17:59:41
|
On Sat, 2008-05-17 at 06:57 -0400, Bob Rossi wrote: > On Sat, May 17, 2008 at 06:41:12AM +0300, Gilboa Davara wrote: > > P.S. any idea when the next minor/major release is planned. > > I rather not push an svn version as a Fedora/RHEL update. > > I would like to do one very soon. There are a couple of bug fixes that > should get released. Perhaps in early June. It'll just be a minor > release however. > > Thanks, > Bob Rossi OK. Thanks for the update. - Gilboa |
|
From: Bob R. <bob...@co...> - 2008-05-28 13:28:52
|
On Sat, May 17, 2008 at 08:59:30PM +0300, Gilboa Davara wrote: > > On Sat, 2008-05-17 at 06:57 -0400, Bob Rossi wrote: > > On Sat, May 17, 2008 at 06:41:12AM +0300, Gilboa Davara wrote: > > > P.S. any idea when the next minor/major release is planned. > > > I rather not push an svn version as a Fedora/RHEL update. > > > > I would like to do one very soon. There are a couple of bug fixes that > > should get released. Perhaps in early June. It'll just be a minor > > release however. > > > > Thanks, > > Bob Rossi > > OK. Thanks for the update. Hi Gilboa, Sorry for the delay, I committed your patch. Also, if you build from svn trunk, and use this command, :map :k<CR> <ESC>iset<space>confirm<space>no<CR>kill<CR>set<space>confirm<space>yes<CR><ESC> you should be able to get the kill functionality that you want. Please let me know if this works for you. Are there any other changes that you wanted to get in before the next release? Thanks, Bob Rossi |
|
From: Gilboa D. <gi...@gm...> - 2008-06-03 09:26:44
|
On Wed, 2008-05-28 at 09:28 -0400, Bob Rossi wrote: > On Sat, May 17, 2008 at 08:59:30PM +0300, Gilboa Davara wrote: > > > > On Sat, 2008-05-17 at 06:57 -0400, Bob Rossi wrote: > > > On Sat, May 17, 2008 at 06:41:12AM +0300, Gilboa Davara wrote: > > > > P.S. any idea when the next minor/major release is planned. > > > > I rather not push an svn version as a Fedora/RHEL update. > > > > > > I would like to do one very soon. There are a couple of bug fixes that > > > should get released. Perhaps in early June. It'll just be a minor > > > release however. > > > > > > Thanks, > > > Bob Rossi > > > > OK. Thanks for the update. > > Hi Gilboa, > > Sorry for the delay, I committed your patch. Also, if you build from svn > trunk, and use this command, > :map :k<CR> <ESC>iset<space>confirm<space>no<CR>kill<CR>set<space>confirm<space>yes<CR><ESC> > you should be able to get the kill functionality that you want. > > Please let me know if this works for you. Are there any other changes > that you wanted to get in before the next release? > > Thanks, > Bob Rossi Hello Bob, Thanks. I assume that permanent mapping can be saved in the .cgdbrc, right? - Gilboa |
|
From: Bob R. <bob...@co...> - 2008-06-03 10:52:55
|
On Tue, Jun 03, 2008 at 12:26:27PM +0300, Gilboa Davara wrote: > > On Wed, 2008-05-28 at 09:28 -0400, Bob Rossi wrote: > > On Sat, May 17, 2008 at 08:59:30PM +0300, Gilboa Davara wrote: > > > > > > On Sat, 2008-05-17 at 06:57 -0400, Bob Rossi wrote: > > > > On Sat, May 17, 2008 at 06:41:12AM +0300, Gilboa Davara wrote: > > > > > P.S. any idea when the next minor/major release is planned. > > > > > I rather not push an svn version as a Fedora/RHEL update. > > > > > > > > I would like to do one very soon. There are a couple of bug fixes that > > > > should get released. Perhaps in early June. It'll just be a minor > > > > release however. > > > > > > > > Thanks, > > > > Bob Rossi > > > > > > OK. Thanks for the update. > > > > Hi Gilboa, > > > > Sorry for the delay, I committed your patch. Also, if you build from svn > > trunk, and use this command, > > :map :k<CR> <ESC>iset<space>confirm<space>no<CR>kill<CR>set<space>confirm<space>yes<CR><ESC> > > you should be able to get the kill functionality that you want. > > > > Please let me know if this works for you. Are there any other changes > > that you wanted to get in before the next release? > > > > Thanks, > > Bob Rossi > > > Hello Bob, > > Thanks. > I assume that permanent mapping can be saved in the .cgdbrc, right? Yup, try it out, let me know if it works. Thanks, Bob Rossi |
|
From: Gilboa D. <gi...@gm...> - 2008-06-03 11:18:46
|
On Tue, 2008-06-03 at 06:52 -0400, Bob Rossi wrote: > On Tue, Jun 03, 2008 at 12:26:27PM +0300, Gilboa Davara wrote: > > > > On Wed, 2008-05-28 at 09:28 -0400, Bob Rossi wrote: > > > On Sat, May 17, 2008 at 08:59:30PM +0300, Gilboa Davara wrote: > > > > > > > > On Sat, 2008-05-17 at 06:57 -0400, Bob Rossi wrote: > > > > > On Sat, May 17, 2008 at 06:41:12AM +0300, Gilboa Davara wrote: > > > > > > P.S. any idea when the next minor/major release is planned. > > > > > > I rather not push an svn version as a Fedora/RHEL update. > > > > > > > > > > I would like to do one very soon. There are a couple of bug fixes that > > > > > should get released. Perhaps in early June. It'll just be a minor > > > > > release however. > > > > > > > > > > Thanks, > > > > > Bob Rossi > > > > > > > > OK. Thanks for the update. > > > > > > Hi Gilboa, > > > > > > Sorry for the delay, I committed your patch. Also, if you build from svn > > > trunk, and use this command, > > > :map :k<CR> <ESC>iset<space>confirm<space>no<CR>kill<CR>set<space>confirm<space>yes<CR><ESC> > > > you should be able to get the kill functionality that you want. > > > > > > Please let me know if this works for you. Are there any other changes > > > that you wanted to get in before the next release? > > > > > > Thanks, > > > Bob Rossi > > > > > > Hello Bob, > > > > Thanks. > > I assume that permanent mapping can be saved in the .cgdbrc, right? > > Yup, try it out, let me know if it works. > > Thanks, > Bob Rossi I'm off to a vacation tomorrow. I'll give it a run once I return. Thanks, - Gilboa |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X