|
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: 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 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-10-04 12:53:33
|
On Fri, Sep 26, 2008 at 01:03:10PM -0400, Kuang He wrote: > 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 see from the mailing list archive that you've been meaning to > release this for some time. Looking forward to it! Yes, as soon as I hash out this issue I'll do a release. > 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? This is intended, although, it's annoying, I must agree. It's because we use readline with it's TERM set to "dumb". Perhaps I should have cgdb capture that specific key, and clear the window. I'll look into this as well. Bob Rossi |
|
From: Bob R. <bo...@br...> - 2008-12-17 03:14:41
|
On Fri, Sep 26, 2008 at 01:03:10PM -0400, Kuang He wrote: > 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? I just fixed this upstream. Hopefully I'll be able to get a release out soon. There is still a few more bug fixes I need to get done. If you type CTRL-L in CGDB, it now clears the entire GDB window with newlines. Bob Rossi |
|
From: Kuang H. <ic...@gm...> - 2009-01-20 10:54:17
|
On Wed, Dec 17, 2008 at 10:14 AM, Bob Rossi <bo...@br...> wrote: > On Fri, Sep 26, 2008 at 01:03:10PM -0400, Kuang He wrote: >> 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? > > I just fixed this upstream. Hopefully I'll be able to get a release out > soon. There is still a few more bug fixes I need to get done. > > If you type CTRL-L in CGDB, it now clears the entire GDB window with > newlines. Hi Bob, I've tested the feature, and it works OK! One small problem though: each time I press Ctrl+L, it would generate a chunk of empty lines in the command history (shown using PageUp/PageDn). This is no big problem, but I feel that I should point it out. Maybe it is due to the design that texts are shown at the bottom rather than at the top of the screen after clearing the screen. -- Kuang He |
|
From: Bob R. <bo...@br...> - 2009-07-25 23:52:25
|
On Tue, Jan 20, 2009 at 06:54:05PM +0800, Kuang He wrote: > On Wed, Dec 17, 2008 at 10:14 AM, Bob Rossi <bo...@br...> wrote: > > On Fri, Sep 26, 2008 at 01:03:10PM -0400, Kuang He wrote: > >> 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? > > > > I just fixed this upstream. Hopefully I'll be able to get a release out > > soon. There is still a few more bug fixes I need to get done. > > > > If you type CTRL-L in CGDB, it now clears the entire GDB window with > > newlines. > > Hi Bob, > > I've tested the feature, and it works OK! > > One small problem though: each time I press Ctrl+L, it would generate > a chunk of empty lines in the command history (shown using > PageUp/PageDn). This is no big problem, but I feel that I should point > it out. Maybe it is due to the design that texts are shown at the > bottom rather than at the top of the screen after clearing the screen. Hi, I'm trying to prepare a release of CGDB, and I didn't like the way I implemented this feature, so I'm working on fixing it. My patch has the gdb prompt starting at the top of the gdb window and it moves down, like it would if you use gdb from the terminal directly. Also, I made it so that when you hit Ctrl+l, that the prompt goes back to the top. My question is this, currently, my patch clears the history in the gdb window, so that if you hit Ctrl+l, you can't see the previous history anymore with page up. Is this desirable? I could alternatively move the gdb prompt to the top of the window, and keep the history. That would be a little more work for me... Anyone care? Bob Rossi |
|
From: Kuang He <ic...@gm...> - 2009-07-26 00:36:59
|
On Sat, Jul 25, 2009 at 6:51 PM, Bob Rossi<bo...@br...> wrote: > Hi, > > I'm trying to prepare a release of CGDB, and I didn't like the way I > implemented this feature, so I'm working on fixing it. > > My patch has the gdb prompt starting at the top of the gdb window > and it moves down, like it would if you use gdb from the terminal > directly. Also, I made it so that when you hit Ctrl+l, that the > prompt goes back to the top. > > My question is this, currently, my patch clears the history in the > gdb window, so that if you hit Ctrl+l, you can't see the previous > history anymore with page up. Is this desirable? I could > alternatively move the gdb prompt to the top of the window, and keep > the history. That would be a little more work for me... > > Anyone care? Dear Bob, I would say that it is certainly desirable to keep the history after clearing the screen using Ctrl+l. However, since you are the one who provides this patch, I think you should make the call. :-) Best regards, -- Kuang He |
