cgdb-devel Mailing List for the curses debugger (Page 3)
Brought to you by:
bobbybrasko,
crouchingturbo
Menu
▾
▴
cgdb-devel — Development activity -- bug reports, patches, related questions
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(19) |
Mar
(15) |
Apr
(6) |
May
|
Jun
(13) |
Jul
(8) |
Aug
(15) |
Sep
(43) |
Oct
(14) |
Nov
(9) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(4) |
Feb
(9) |
Mar
(15) |
Apr
(5) |
May
(1) |
Jun
|
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(12) |
May
(7) |
Jun
(7) |
Jul
(21) |
Aug
(7) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2006 |
Jan
(3) |
Feb
(2) |
Mar
(5) |
Apr
(2) |
May
(5) |
Jun
(6) |
Jul
|
Aug
(7) |
Sep
|
Oct
(13) |
Nov
|
Dec
(7) |
| 2007 |
Jan
(3) |
Feb
(16) |
Mar
(6) |
Apr
(8) |
May
(7) |
Jun
(19) |
Jul
(14) |
Aug
(23) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(3) |
Jul
|
Aug
|
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2009 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(11) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(8) |
Dec
(1) |
| 2011 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bob R. <bob...@co...> - 2008-09-28 21:29:30
|
On Fri, Sep 26, 2008 at 01:10:29PM -0400, Kuang He wrote: > Hi, > > [ I sent the following message yesterday, but it did not seem to get > through. Sorry for the duplicates if any. ] > > People might want to make cgdb-specific customizations in their > ~/.inputrc files. Committed. Thanks. Bob Rossi |
|
From: Kuang H. <ic...@gm...> - 2008-09-26 17:10:40
|
Hi, [ I sent the following message yesterday, but it did not seem to get through. Sorry for the duplicates if any. ] People might want to make cgdb-specific customizations in their ~/.inputrc files. For example, a possible snippet of ~/.inputrc: $if cgdb "\C-p": history-search-backward "\C-n": history-search-backward $endif A small patch to do that: $ diff -ub ./various/rline/src/rline.c.old ./various/rline/src/rline.c --- ./various/rline/src/rline.c.old 2008-09-26 01:57:43.000000000 -0400 +++ ./various/rline/src/rline.c 2008-09-26 03:23:13.000000000 -0400 @@ -96,6 +96,7 @@ rline->rline_rl_last_func = NULL; rline->rline_rl_completion_query_items = rl_completion_query_items; + rl_readline_name = "cgdb"; rl_instream = rline->input; rl_outstream = rline->output; Best regards, Kuang He |
|
From: Kuang H. <ic...@gm...> - 2008-09-26 17:03:24
|
Hi Bob, On Fri, Sep 26, 2008 at 10:08 AM, Bob Rossi <bob...@co...> wrote: > On Fri, Sep 26, 2008 at 03:21:59AM -0400, Kuang He wrote: >> I'm using cgdb 0.6.4 on a linux box (Ubuntu 8.04), with libreadline >> v5.2. The default readline hotkeys Alt-X (e.g. Alt-P/N for >> history-search-backward/history-search-forward, Alt-F/B for moving a >> word forward/backward) do not work in cgdb on my machine. Any Alt-X >> combination key in the gdb window will result in switching to the >> source code window, just as an ESC would do. I've tried to read cgdb's >> source code to figure out why, but the code is more complex than I've >> thought. Any enlightenment would be welcome. > > OK, here is the real issue. This comes directly from the vim manual, > > By default Vim assumes that pressing the ALT key sets the 8th bit of a typed > character. Most decent terminals can work that way, such as xterm, aterm and > rxvt. If your <A-k> mappings don't work it might be that the terminal is > prefixing the character with an ESC character. But you can just as well type > ESC before a character, thus Vim doesn't know what happened (except for > checking the delay between characters, which is not reliable). > > Please type ':help alt-keys' to read more about this. Thanks for the explanation! > Does typing Alt-P work for you in bash? I'm assuming that the terminal > is sending Esc-p for you in this case. Yes, Alt-P/N/F/B work fine for me in bash, and other applications on my system that use readline. I guess the terminal is sending ESC- sequences when I press Alt+ other keys, since in vim, when I press Alt+i, it is equivalent to ESC followed by an i key, etc. > The problem is that some terminals set the 8th bit of the ascii char, to > tell you that alt was being pushed and some termainls send esc-char. To > seperate characters. cgdb initially supported reading esc-char as an > alt charachter. However, I found as I started to type esc-o to get into > the file dialog, I would type it to fast, and cgdb would recognize it as > alt-o. This frustrated me, I learned more, and then disabled the > alt processing. I believe vim has also disabled this processing. > > I'm considering resurrecting this functionality, and making it optional. I have the following in my ~/.inputrc: set input-meta on set output-meta on set convert-meta off I tried to toggle their values from on->off or off->on in different combinations, but it did not help. >> Also, I personally like to define PageUp/PageDown in my ~/.inputrc to >> do the same thing as Alt-P/N, but since PageUp/PageDown have been used >> by cgdb to scroll the screen, I could not use these hotkeys as I like >> to. I've changed the code to fix that (for myself), but I guess there >> is no generic solution since all the hotkeys cgdb use are hard coded >> into the source. > > The version of cgdb in svn trunk/, which I really want to release soon, > has the ability to map keys. I see from the mailing list archive that you've been meaning to release this for some time. Looking forward to it! By the way, when I press CTRL-L in the gdb window, it does not clear the screen, but rather generates a new input line. Is this intended, or a bug? Best regards, Kuang He |
|
From: Bob R. <bob...@co...> - 2008-09-26 15:10:15
|
On Fri, Sep 26, 2008 at 03:21:59AM -0400, Kuang He wrote: > Hi all, > > I'm a new user of cgdb and find it very useful. The vi key binding is > very nice, too, since I'm a vim user. Thank you, cgdb developers! I'm glad you enjoy it. > I'm using cgdb 0.6.4 on a linux box (Ubuntu 8.04), with libreadline > v5.2. The default readline hotkeys Alt-X (e.g. Alt-P/N for > history-search-backward/history-search-forward, Alt-F/B for moving a > word forward/backward) do not work in cgdb on my machine. Any Alt-X > combination key in the gdb window will result in switching to the > source code window, just as an ESC would do. I've tried to read cgdb's > source code to figure out why, but the code is more complex than I've > thought. Any enlightenment would be welcome. OK, here is the real issue. This comes directly from the vim manual, By default Vim assumes that pressing the ALT key sets the 8th bit of a typed character. Most decent terminals can work that way, such as xterm, aterm and rxvt. If your <A-k> mappings don't work it might be that the terminal is prefixing the character with an ESC character. But you can just as well type ESC before a character, thus Vim doesn't know what happened (except for checking the delay between characters, which is not reliable). Please type ':help alt-keys' to read more about this. Does typing Alt-P work for you in bash? I'm assuming that the terminal is sending Esc-p for you in this case. The problem is that some terminals set the 8th bit of the ascii char, to tell you that alt was being pushed and some termainls send esc-char. To seperate characters. cgdb initially supported reading esc-char as an alt charachter. However, I found as I started to type esc-o to get into the file dialog, I would type it to fast, and cgdb would recognize it as alt-o. This frustrated me, I learned more, and then disabled the alt processing. I believe vim has also disabled this processing. I'm considering resurrecting this functionality, and making it optional. > Also, I personally like to define PageUp/PageDown in my ~/.inputrc to > do the same thing as Alt-P/N, but since PageUp/PageDown have been used > by cgdb to scroll the screen, I could not use these hotkeys as I like > to. I've changed the code to fix that (for myself), but I guess there > is no generic solution since all the hotkeys cgdb use are hard coded > into the source. The version of cgdb in svn trunk/, which I really want to release soon, has the ability to map keys. So, you could make a map like, imap <PageUp> <A-p> however, because of the alt issue, this binding doesn't work yet. You can test out the bindings by trying something like, imap <PageUp> <S-p> and you should notice that if you hit PageUp in gdb mode, that P is produced. Let me look into this more, and see what I can come up with. Thanks, Bob Rossi |
|
From: Kuang H. <ic...@gm...> - 2008-09-26 07:28:16
|
Hi, A small patch to enable people to make cgdb-specific customizations in their ~/.inputrc files. For example, a possible snippet of ~/.inputrc: $if cgdb "\C-p": history-search-backward "\C-n": history-search-backward $endif $ diff -ub ./various/rline/src/rline.c.old ./various/rline/src/rline.c --- ./various/rline/src/rline.c.old 2008-09-26 01:57:43.000000000 -0400 +++ ./various/rline/src/rline.c 2008-09-26 03:23:13.000000000 -0400 @@ -96,6 +96,7 @@ rline->rline_rl_last_func = NULL; rline->rline_rl_completion_query_items = rl_completion_query_items; + rl_readline_name = "cgdb"; rl_instream = rline->input; rl_outstream = rline->output; Best regards, -- Kuang He |
|
From: Kuang H. <ic...@gm...> - 2008-09-26 07:22:06
|
Hi all, I'm a new user of cgdb and find it very useful. The vi key binding is very nice, too, since I'm a vim user. Thank you, cgdb developers! I'm using cgdb 0.6.4 on a linux box (Ubuntu 8.04), with libreadline v5.2. The default readline hotkeys Alt-X (e.g. Alt-P/N for history-search-backward/history-search-forward, Alt-F/B for moving a word forward/backward) do not work in cgdb on my machine. Any Alt-X combination key in the gdb window will result in switching to the source code window, just as an ESC would do. I've tried to read cgdb's source code to figure out why, but the code is more complex than I've thought. Any enlightenment would be welcome. Also, I personally like to define PageUp/PageDown in my ~/.inputrc to do the same thing as Alt-P/N, but since PageUp/PageDown have been used by cgdb to scroll the screen, I could not use these hotkeys as I like to. I've changed the code to fix that (for myself), but I guess there is no generic solution since all the hotkeys cgdb use are hard coded into the source. Best regards, -- Kuang He |
|
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 |
|
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 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-05-28 13:49:20
|
On Tue, May 20, 2008 at 11:24:03PM -0400, Mike Mueller wrote: > Bob, > > When you get a chance, I'd like you to review the attached patch. > It does the following things: > > 1. Bug fix: If you start searching for something, but abort (hit ESC), > the regex_line variable was obliterated, so 'n' or 'N' no longer finds > the last searched regex. I renamed regex_line to regex_last, and > created a regex_cur for the currently-being-typed regex. Now if you > give up searching, you can still 'n' for the last searched string. Excellent bug fix. I did not a small bug in the new functionality however while testing it. Here is the test case I used, 39| long_func(); 40| 41| fprintf(stderr, "HAHAAHA\n"); 42| fprintf(stderr, "AHAAHA\n"); 43| fprintf(stderr, "HAAHA\n"); 44| fprintf(stderr, "AAHA\n"); put the cursor above line 39. - search for stderr. - hit 'n', 'n', 'n'. (now you should be on line 44) - reverse search for long_, and then hit <ESC> to cancel out - hit 'N', you end up on line 41, instead of 43. This bug only occurs if you do the reverse search step, otherwise it successfully takes you to line 43. Can you reproduce this? Do you mind fixing it? > 2. Bug fix: Start cgdb, hit ESC, start searching for something, hit ESC, > hit ':' and the status bar displays :(null). Fixed this. Whoa, nasty bug. That would certainly cause a crash on some system! Good find. > 3. Feature: If you are typing a :ex command or a regex search, and you > backspace when the command/regex is empty, the command or search is > aborted (like vim does). Excellent. > 4. Fixed a warning about casting pointer to int of different size > compiling on a 64-bit platform. > > I tried to test this well, but I wanted your input before I commit it. Other than that one use case I found, everything looks great. Bob Rossi |
|
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: Horst S. <sch...@us...> - 2008-05-21 08:22:13
|
On Tue, 20 May 2008, Mike Mueller wrote: > When you get a chance, I'd like you to review the attached patch. > It does the following things: > [...] Would be way easier to review if each change was in a separate patch ... -Horst -- PGP-Key 0xD40E0E7A |
|
From: Mike M. <mi...@su...> - 2008-05-21 03:46:50
|
On Tue, May 20, 2008 at 11:24:03PM -0400, Mike Mueller wrote:
> When you get a chance, I'd like you to review the attached patch.
> It does the following things:
>
> 1. Bug fix: If you start searching for something, but abort (hit ESC),
> the regex_line variable was obliterated, so 'n' or 'N' no longer finds
> the last searched regex. I renamed regex_line to regex_last, and
> created a regex_cur for the currently-being-typed regex. Now if you
> give up searching, you can still 'n' for the last searched string.
>
> 2. Bug fix: Start cgdb, hit ESC, start searching for something, hit ESC,
> hit ':' and the status bar displays :(null). Fixed this.
>
> 3. Feature: If you are typing a :ex command or a regex search, and you
> backspace when the command/regex is empty, the command or search is
> aborted (like vim does).
>
> 4. Fixed a warning about casting pointer to int of different size
> compiling on a 64-bit platform.
>
> I tried to test this well, but I wanted your input before I commit it.
I made one more change after creating this patch: Fix the segfault when
you try to search and cgdb isn't displaying any file (i.e. start cgdb
with no arguments, type '/'). I put this test in internal_if_input:
case '/':
case '?':
+ if (src_win->cur != NULL) {
Otherwise, if it's NULL, it simply ignores the attempt to search. I
noticed this is how cgdb 0.6.4 behaves, so this bug was introduced in
svn and hasn't gotten out in the wild yet. :)
--
Mike Mueller
mi...@su...
|
|
From: Mike M. <mi...@su...> - 2008-05-21 03:24:12
|
Bob, When you get a chance, I'd like you to review the attached patch. It does the following things: 1. Bug fix: If you start searching for something, but abort (hit ESC), the regex_line variable was obliterated, so 'n' or 'N' no longer finds the last searched regex. I renamed regex_line to regex_last, and created a regex_cur for the currently-being-typed regex. Now if you give up searching, you can still 'n' for the last searched string. 2. Bug fix: Start cgdb, hit ESC, start searching for something, hit ESC, hit ':' and the status bar displays :(null). Fixed this. 3. Feature: If you are typing a :ex command or a regex search, and you backspace when the command/regex is empty, the command or search is aborted (like vim does). 4. Fixed a warning about casting pointer to int of different size compiling on a 64-bit platform. I tried to test this well, but I wanted your input before I commit it. Thanks! Mike -- Mike Mueller mi...@su... |
|
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-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 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 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-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-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-07 09:12:41
|
Patch 3: Textinfo update. - Gilboa |
|
From: Gilboa D. <gi...@gm...> - 2008-05-07 08:35:08
|
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: Gilboa D. <gi...@gm...> - 2008-05-07 08:13:53
|
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: Bob R. <bob...@co...> - 2007-08-28 13:27:48
|
On Tue, Aug 28, 2007 at 04:09:49PM +0300, Gilboa Davara wrote: > On Sun, 2007-08-26 at 14:20 -0400, Bob Rossi wrote: > > 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. Great! Can't wait to see them. Bob Rossi |
|
From: Gilboa D. <gi...@gm...> - 2007-08-28 13:10:02
|
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 |
35 messages has been excluded from this view by a project administrator.
