cgdb-users — Users -- questions, answers, feature requests

Re: [Cgdb-users] compiling on OS X leopard

[Horst S. <sch...@us...>]

On Thu, 15 Nov 2007, Bob Rossi wrote:
> Well, we would first need to know how to open a pty on mac os 10.5. Once
> we figured that out, we can determine what's going wrong with psuedo.c.
> Do you have a /dev/ptmx directory? How about /dev/ptc?

I suggest looking at the location you borrowed that code from in the
first place, maybe they already have a solution that works for Leopard
(MacOS 10.5). As Cgdb builds fine on 10.4 here, it's very possible that
this is a 10.5 only issue.

(MacOS 10.4.11)
$ sudo port install cgdb
Password:
--->  Fetching cgdb
--->  Attempting to fetch cgdb-0.6.4.tar.gz from
http://downloads.sourceforge.net/cgdb
--->  Verifying checksum(s) for cgdb
--->  Extracting cgdb
--->  Configuring cgdb
--->  Building cgdb with target all
--->  Staging cgdb into destroot
--->  Installing cgdb 0.6.4_0
--->  Activating cgdb 0.6.4_0
--->  Cleaning cgdb
$

Kind regards,
 Horst

-- 
PGP-Key 0xD40E0E7A

Re: [Cgdb-users] compiling on OS X leopard

[Bob R. <bob...@co...>]

On Thu, Nov 15, 2007 at 10:51:54AM -0800, Badi' Abdul-Wahid wrote:
> Hi.
> I'm trying to get cgdb compiled and installed on my Apple laptop  
> running OS 10.5. I've tried compiling from source and using MacPorts.  
> They both halt compiling on the same error (this is from the MacPort  
> attempt):

Hmmm, neosun had this compiling at some point. Have you seen the
mac os X link here:
http://cgdb.sourceforge.net/download.php

It has a binary which you can use, unless you are relying on trunk/ for
some reason.

> pseudo.c: In function 'pty_open':
> pseudo.c:338: error: 'I_PUSH' undeclared (first use in this function)
> pseudo.c:338: error: (Each undeclared identifier is reported only once
> pseudo.c:338: error: for each function it appears in.)

Hmm, this could be a problem. I didn't write this code, I borrowed it
from the ssh project. So, either autoconf screwed up, and brought you
down the wrong path in psuedo.c or pseudo.c needs to be modified to work
on the specific OS you are compiling for.

> Does anyone have any idea as to what's going on? This seems to be  
> specific to the apple os, since I compiled and installed on a linux  
> box I have access to.

Well, we would first need to know how to open a pty on mac os 10.5. Once
we figured that out, we can determine what's going wrong with psuedo.c.
Do you have a /dev/ptmx directory? How about /dev/ptc?

Thanks,
Bob Rossi

[Cgdb-users] compiling on OS X leopard

[Badi' Abdul-W. <ali...@gm...>]

Hi.
I'm trying to get cgdb compiled and installed on my Apple laptop  
running OS 10.5. I've tried compiling from source and using MacPorts.  
They both halt compiling on the same error (this is from the MacPort  
attempt):

[~/src/cvs-svn/cgdb]: port install cgdb
--->  Building cgdb with target all
Error: Target org.macports.build returned: shell command " cd "/opt/ 
local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_devel_cgdb/work/cgdb-0.6.4" && make all "  
returned error 2
Command output: make  all-recursive
Making all in lib
Making all in gdbmi
make  all-recursive
Making all in src
make[5]: Nothing to be done for `all'.
make[5]: Nothing to be done for `all-am'.
make[3]: Nothing to be done for `all-am'.
Making all in various
Making all in util
Making all in src
if gcc -DHAVE_CONFIG_H -I. -I. -I../../..   -I/opt/local/include - 
I./../include -O2 -MT pseudo.o -MD -MP -MF ".deps/pseudo.Tpo" -c -o  
pseudo.o pseudo.c; \
         then mv -f ".deps/pseudo.Tpo" ".deps/pseudo.Po"; else rm -f  
".deps/pseudo.Tpo"; exit 1; fi
pseudo.c: In function 'pty_open':
pseudo.c:338: error: 'I_PUSH' undeclared (first use in this function)
pseudo.c:338: error: (Each undeclared identifier is reported only once
pseudo.c:338: error: for each function it appears in.)
make[4]: *** [pseudo.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Does anyone have any idea as to what's going on? This seems to be  
specific to the apple os, since I compiled and installed on a linux  
box I have access to.

Thanks.

Re: [Cgdb-users] key bindings

[Bob R. <bob...@co...>]

> On Sun, Aug 12, 2007 at 10:56:34PM -0400, Bob Rossi wrote:
> > On Sat, Aug 11, 2007 at 11:36:25PM +0100, William Pursell wrote:
> > Sorry for the delay in checking this.  Although remapping
> > cgdbmodekey works in this version, there is something wrong.
> > The following key sequence causes cgdb to hang, and I'm having
> > to SIGKILL it:
> > 
> > set args foo<esc>bc
> > 
> > Many of the readline commands work as expected (I've
> > checked: xhjklAaIifFtTbwBW), but 'c' and 'd' are locking
> > it up; it looks like rl_callback_read_char() is never
> > returning.
> 
> Aaaa, I see. That's to bad. I'll try to reproduce this behavior, but it
> seems that readline is probably not honoring the callback interface.
> I've had this happen before and hat to patch readline, which is why
> cgdb depends on a fairly recent version of readline.
> 
> If this is true, I'll have to talk with the readline maintainer about
> fixing this problem. He's on vacation for another 2 weeks, afaik. If we
> get a fix, you'll have to build the modified readline with cgdb to
> verify that it works. If this is the issue, it'll probably be a few
> months before readline is releaesd, and cgdb works with an official
> version. In the long run though, it's probably worth it.

Just so you know, I did verify that this was a readline bug. I'm still
waiting for a response from the readline maintainer. In the event that
you have more time than him, you could always modify readline and send
in a patch.

Bob Rossi

Re: [Cgdb-users] key bindings

[Bob R. <bob...@co...>]

On Sat, Aug 11, 2007 at 11:36:25PM +0100, William Pursell wrote:
> Bob Rossi wrote:
> > On Tue, Aug 07, 2007 at 05:30:53PM -0400, Bob Rossi wrote:
> >> On Tue, Aug 07, 2007 at 09:24:41PM +0100, William Pursell wrote:
> >>> Bob Rossi wrote:
> >>>> On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
> >>>>> Is there a workaround for this?
> >>>> Try downloading and installing 
> >>>> http://brasko.net:81/bob/cgdb-20070807.tar.gz
> >>>>
> >>>> Then in your ~/.cgdb/cgdbrc do 'set cgdbmodekey=key'. Key can be any
> >>>> normal key on the keyboard, or a keycode string. For example, <F1> or
> >>>> <PageUp>.
> >>>>
> >>>> Make sure to give us feedback on if this is useful. If so, we'll
> >>>> consider adding it for the next release.
> >>> This works to remap the key, but <esc> is now (apparently) ignored
> >>> and I can't get readline into command mode.  
> >> Oops, I think I see the problem and I've fixed it. I'm not able to get
> >> into and out of command mode in readline, in cgdb. Try this version and
> >> let me know.
> >>
> >> http://brasko.net:81/bob/cgdb-20070807.tar.gz
> >>
> >> The above is a different version of the code, even though it has the
> >> same name.
> > 
> > I've committed these changes allong with the documentation. You should
> > be able to use CGDB with readline in vi mode now.
> 
> Sorry for the delay in checking this.  Although remapping
> cgdbmodekey works in this version, there is something wrong.
> The following key sequence causes cgdb to hang, and I'm having
> to SIGKILL it:
> 
> set args foo<esc>bc
> 
> Many of the readline commands work as expected (I've
> checked: xhjklAaIifFtTbwBW), but 'c' and 'd' are locking
> it up; it looks like rl_callback_read_char() is never
> returning.

Aaaa, I see. That's to bad. I'll try to reproduce this behavior, but it
seems that readline is probably not honoring the callback interface.
I've had this happen before and hat to patch readline, which is why
cgdb depends on a fairly recent version of readline.

If this is true, I'll have to talk with the readline maintainer about
fixing this problem. He's on vacation for another 2 weeks, afaik. If we
get a fix, you'll have to build the modified readline with cgdb to
verify that it works. If this is the issue, it'll probably be a few
months before readline is releaesd, and cgdb works with an official
version. In the long run though, it's probably worth it.

Bob Rossi

Re: [Cgdb-users] key bindings

[William P. <bil...@gm...>]

Bob Rossi wrote:
> On Tue, Aug 07, 2007 at 05:30:53PM -0400, Bob Rossi wrote:
>> On Tue, Aug 07, 2007 at 09:24:41PM +0100, William Pursell wrote:
>>> Bob Rossi wrote:
>>>> On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
>>>>> Is there a workaround for this?
>>>> Try downloading and installing 
>>>> http://brasko.net:81/bob/cgdb-20070807.tar.gz
>>>>
>>>> Then in your ~/.cgdb/cgdbrc do 'set cgdbmodekey=key'. Key can be any
>>>> normal key on the keyboard, or a keycode string. For example, <F1> or
>>>> <PageUp>.
>>>>
>>>> Make sure to give us feedback on if this is useful. If so, we'll
>>>> consider adding it for the next release.
>>> This works to remap the key, but <esc> is now (apparently) ignored
>>> and I can't get readline into command mode.  
>> Oops, I think I see the problem and I've fixed it. I'm not able to get
>> into and out of command mode in readline, in cgdb. Try this version and
>> let me know.
>>
>> http://brasko.net:81/bob/cgdb-20070807.tar.gz
>>
>> The above is a different version of the code, even though it has the
>> same name.
> 
> I've committed these changes allong with the documentation. You should
> be able to use CGDB with readline in vi mode now.

Sorry for the delay in checking this.  Although remapping
cgdbmodekey works in this version, there is something wrong.
The following key sequence causes cgdb to hang, and I'm having
to SIGKILL it:

set args foo<esc>bc

Many of the readline commands work as expected (I've
checked: xhjklAaIifFtTbwBW), but 'c' and 'd' are locking
it up; it looks like rl_callback_read_char() is never
returning.

Re: [Cgdb-users] key bindings

[Bob R. <bob...@co...>]

On Tue, Aug 07, 2007 at 05:30:53PM -0400, Bob Rossi wrote:
> On Tue, Aug 07, 2007 at 09:24:41PM +0100, William Pursell wrote:
> > Bob Rossi wrote:
> > > On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
> > >> Is there a workaround for this?
> > > 
> > > Try downloading and installing 
> > > http://brasko.net:81/bob/cgdb-20070807.tar.gz
> > > 
> > > Then in your ~/.cgdb/cgdbrc do 'set cgdbmodekey=key'. Key can be any
> > > normal key on the keyboard, or a keycode string. For example, <F1> or
> > > <PageUp>.
> > > 
> > > Make sure to give us feedback on if this is useful. If so, we'll
> > > consider adding it for the next release.
> > 
> > This works to remap the key, but <esc> is now (apparently) ignored
> > and I can't get readline into command mode.  
> 
> Oops, I think I see the problem and I've fixed it. I'm not able to get
> into and out of command mode in readline, in cgdb. Try this version and
> let me know.
> 
> http://brasko.net:81/bob/cgdb-20070807.tar.gz
> 
> The above is a different version of the code, even though it has the
> same name.

I've committed these changes allong with the documentation. You should
be able to use CGDB with readline in vi mode now.

Enjoy,
Bob Rossi

Re: [Cgdb-users] key bindings

[Bob R. <bob...@co...>]

On Tue, Aug 07, 2007 at 09:24:41PM +0100, William Pursell wrote:
> Bob Rossi wrote:
> > On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
> >> Is there a workaround for this?
> > 
> > Try downloading and installing 
> > http://brasko.net:81/bob/cgdb-20070807.tar.gz
> > 
> > Then in your ~/.cgdb/cgdbrc do 'set cgdbmodekey=key'. Key can be any
> > normal key on the keyboard, or a keycode string. For example, <F1> or
> > <PageUp>.
> > 
> > Make sure to give us feedback on if this is useful. If so, we'll
> > consider adding it for the next release.
> 
> This works to remap the key, but <esc> is now (apparently) ignored
> and I can't get readline into command mode.  

Oops, I think I see the problem and I've fixed it. I'm not able to get
into and out of command mode in readline, in cgdb. Try this version and
let me know.

http://brasko.net:81/bob/cgdb-20070807.tar.gz

The above is a different version of the code, even though it has the
same name.

Thanks,
Bob Rossi

Re: [Cgdb-users] key bindings

[Bob R. <bob...@co...>]

On Tue, Aug 07, 2007 at 09:24:41PM +0100, William Pursell wrote:
> Bob Rossi wrote:
> > On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
> >> Is there a workaround for this?
> > 
> > Try downloading and installing 
> > http://brasko.net:81/bob/cgdb-20070807.tar.gz
> > 
> > Then in your ~/.cgdb/cgdbrc do 'set cgdbmodekey=key'. Key can be any
> > normal key on the keyboard, or a keycode string. For example, <F1> or
> > <PageUp>.
> > 
> > Make sure to give us feedback on if this is useful. If so, we'll
> > consider adding it for the next release.
> 
> This works to remap the key, but <esc> is now (apparently) ignored
> and I can't get readline into command mode.  I will try to
> spend some time looking into this, but I'm going on a 3 week
> trip in about 9 days, so it will be quite some time before I'm
> able to offer any useful contribution.  I'm very pleased by the code
> layout and look forward to digging in.

OK, give me a quick test case to try, step by step that doesn't work.

For example, 
  start cgdb
  type i to get into cgdb window
  type ....

I'd like to reproduce that the example doesn't work for me, and then
I'll make sure that it does work.

Bob Rossi

Re: [Cgdb-users] key bindings

[William P. <bil...@gm...>]

Bob Rossi wrote:
> On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
>> Is there a workaround for this?
> 
> Try downloading and installing 
> http://brasko.net:81/bob/cgdb-20070807.tar.gz
> 
> Then in your ~/.cgdb/cgdbrc do 'set cgdbmodekey=key'. Key can be any
> normal key on the keyboard, or a keycode string. For example, <F1> or
> <PageUp>.
> 
> Make sure to give us feedback on if this is useful. If so, we'll
> consider adding it for the next release.

This works to remap the key, but <esc> is now (apparently) ignored
and I can't get readline into command mode.  I will try to
spend some time looking into this, but I'm going on a 3 week
trip in about 9 days, so it will be quite some time before I'm
able to offer any useful contribution.  I'm very pleased by the code
layout and look forward to digging in.

Re: [Cgdb-users] key bindings

[Bob R. <bob...@co...>]

On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
> Is there a workaround for this?

Try downloading and installing 
http://brasko.net:81/bob/cgdb-20070807.tar.gz

Then in your ~/.cgdb/cgdbrc do 'set cgdbmodekey=key'. Key can be any
normal key on the keyboard, or a keycode string. For example, <F1> or
<PageUp>.

Make sure to give us feedback on if this is useful. If so, we'll
consider adding it for the next release.

Thanks,
Bob Rossi

Re: [Cgdb-users] key bindings

[Bob R. <bob...@co...>]

On Tue, Aug 07, 2007 at 07:43:48AM -0400, Peter Kovacs wrote:
> On Tue, Aug 07, 2007 at 05:32:46AM +0100, William Pursell wrote:
> > > One solution, which wouldn't be super friendly, is to provide a way to 
> > > send esc to readline by having an escape key. For instance, if you type 
> > > '<esc><esc>',  than that escape goes to gdb. These solutions tend to be 
> > > a pain on users I think though.
> 
> Why not add a new key-code like <gdb-esc> which sends the <esc> directly
> to gdb instead of cgdb?  Its been a while since I looked at the code,
> but maybe that's a little easier to do, and a little more
> self-documenting.

OK, here is the summary of our situation. This problem hits deep into
the design of cgdb.

Currently, libcex hasn't been written yet. libcex is inteded to be a
library that allows CGDB to map any set of keys to any CGDB action.
This library is still in the design phase, as it might stay for a long
time without developer contribution. 

There are 2 possible designs for this library, one is what I call the 
'vi style' design, which hardcodes keys to a particular action. You can't
change what keys cause which actions. Thus the library wouldn't support
having a vim and an emacs mode style interface. The advantage to this 
design is that because the keys are specific to a commamd, it's easy
to have CGDB do command specific things while the user is actively 
typing the keys. Think of how vim allows you to type, 'd/foo<Enter>'
After you type the /, in the middle of the delete command, it starts
searching for foo. Now that's context! With this design, the library
will simply be an abstraction of what keys do what action. The user can
not modify this.

The other design is what I call the 'mutt' design. They essentially
allow you to map any set of keys to any command. So, each cgdb command
will have a name, and potentially a set of parameters. This allows for
the user to customize the front end with multiple feels (vi, emacs).
The downside is you loose context during interactive typing, unless you
create some sort of very complicated description of the command.

Now, I mention all of this because what you are asking for would
essentially require a higher level library to allow the user to tune 
CGDB to understand what command it should do based on what the user 
typed.

With all of this in mind, since it will be a while before this
particular feature is available cleanly, it was suggested by Peter, 
that we make a config option, 'set escape-key key' that will allow
us to define what the escape key is. The default would be, 
'set escape-key <Esc>'. You could change that to whatever you want.
That would allow you to setup CGDB so that a different key would be
responsible for you to get in and out of CGDB/GDB mode.

Now, after that is implemented, it might just automatically work they
way you want. Since, there would be no reason to eat the <Esc> key to 
go into insert mode, CGDB would just send it to GDB/readline.

This is an initial idea, does anyone see any holes in it? Does anyone
object? The main issue is that vim doesn't have a 'set escape-key'
command. So, once we wrote libcex, we may have to end up dropping the
command.

Thanks,
Bob Rossi

Re: [Cgdb-users] key bindings

[Peter K. <pe...@ko...>]

On Tue, Aug 07, 2007 at 05:32:46AM +0100, William Pursell wrote:
> > One solution, which wouldn't be super friendly, is to provide a way to 
> > send esc to readline by having an escape key. For instance, if you type 
> > '<esc><esc>',  than that escape goes to gdb. These solutions tend to be 
> > a pain on users I think though.

Why not add a new key-code like <gdb-esc> which sends the <esc> directly
to gdb instead of cgdb?  Its been a while since I looked at the code,
but maybe that's a little easier to do, and a little more
self-documenting.

- Peter

Re: [Cgdb-users] key bindings

[William P. <bil...@gm...>]

Bob Rossi wrote:
> On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
>>
>> I just started using cgdb a few weeks ago, and I'm loving it.  This
>> is a great tool.  Thanks!
>>
>> I'm having a problem that seems related to the discussion in the
>> archive around Aug '04 with the thread subject "key bindings".
> 
> Hi William, 
>  
> There currently isn't a workaround that I know of. However, I would love 
> to see this issue fixed. I don't use readline in vi mode, so I have 
> never run into this problem. 
>  
> For starters, how do you put readline in vi mode when using cgdb? Do you 
> have to put something in your .inputrc? If so, what do you put in there? 

set editing-mode vi

I actually set that as the first line in /etc/inputrc on all
boxes on which I have root.  Well, not quite all, but any box
that I "own"...my co-workers hate me for it, but I think
it's good for them as they might otherwise never even realize that
readline has options.

> 
>> When in GDB mode and with readline in vi-mode, I can do:
>> '<esc>kkAfoo' to append the text 'foo' to the command
>> executed 2 instances back in the history, but I can't
> 
> OK, I'm confused as to why this works for you, I would like to reproduce 
> it. After you type '<esc>kkAfoo', you are still in GDB mode? I would 
> except that you would be put into the source window. 

Yes, still in gdb mode.  I can edit the line as long as I don't
go into insert mode.  (ie, I can delete characters with 'x' and
replace single characters with 'r', but if I use 'i', 'a', or 'R',
I can't get back to command mode in readline)
> 
>> edit the line beyond that.  Ie, if I try to replace
>> 'foo' with 'bar', I would normally do: '<esc>FfRbar',
>> but the esc there is being grabbed by cgdb and sending
>> me into the source window.
> 
> Yes, this currently makes sense to me. 
> 
>> Is there a workaround for this?
> 
> Not that I know of. However, I think if we can come up with a solution 
> to this problem, it shouldn't be to hard to add to CGDB. Is the issue 
> that sometimes when you hit <Esc> you want to stay in GDB mode and 
> sometimes you want to go to CGDB mode? How would CGDB know the 
> difference? 
>  
> One solution, which wouldn't be super friendly, is to provide a way to 
> send esc to readline by having an escape key. For instance, if you type 
> '<esc><esc>',  than that escape goes to gdb. These solutions tend to be 
> a pain on users I think though.

I agree that it would be a pain.  Personally, I would prefer
that esc always go to readline, and some other key be used to
switch to the cgdb window, but I can't see that being an
acceptable solution at all.  Perhaps that could simply be
made an option with an alternate key-binding as a value.
I haven't yet had a chance to read through very much of
the cgdb documentation yet, so I'm not going to have much
insight into what would be appropriate.

Re: [Cgdb-users] key bindings

[Bob R. <bob...@co...>]

On Sun, Aug 05, 2007 at 08:19:13AM +0100, William Pursell wrote:
> 
> 
> I just started using cgdb a few weeks ago, and I'm loving it.  This
> is a great tool.  Thanks!
> 
> I'm having a problem that seems related to the discussion in the
> archive around Aug '04 with the thread subject "key bindings".

Hi William, 
 
There currently isn't a workaround that I know of. However, I would love 
to see this issue fixed. I don't use readline in vi mode, so I have 
never run into this problem. 
 
For starters, how do you put readline in vi mode when using cgdb? Do you 
have to put something in your .inputrc? If so, what do you put in there? 

> When in GDB mode and with readline in vi-mode, I can do:
> '<esc>kkAfoo' to append the text 'foo' to the command
> executed 2 instances back in the history, but I can't

OK, I'm confused as to why this works for you, I would like to reproduce 
it. After you type '<esc>kkAfoo', you are still in GDB mode? I would 
except that you would be put into the source window. 

> edit the line beyond that.  Ie, if I try to replace
> 'foo' with 'bar', I would normally do: '<esc>FfRbar',
> but the esc there is being grabbed by cgdb and sending
> me into the source window.

Yes, this currently makes sense to me. 

> Is there a workaround for this?

Not that I know of. However, I think if we can come up with a solution 
to this problem, it shouldn't be to hard to add to CGDB. Is the issue 
that sometimes when you hit <Esc> you want to stay in GDB mode and 
sometimes you want to go to CGDB mode? How would CGDB know the 
difference? 
 
One solution, which wouldn't be super friendly, is to provide a way to 
send esc to readline by having an escape key. For instance, if you type 
'<esc><esc>',  than that escape goes to gdb. These solutions tend to be 
a pain on users I think though. 
 
Any ideas? 
 
Bob Rossi 

[Cgdb-users] key bindings

[William P. <bil...@gm...>]

I just started using cgdb a few weeks ago, and I'm loving it.  This
is a great tool.  Thanks!

I'm having a problem that seems related to the discussion in the
archive around Aug '04 with the thread subject "key bindings".
When in GDB mode and with readline in vi-mode, I can do:
'<esc>kkAfoo' to append the text 'foo' to the command
executed 2 instances back in the history, but I can't
edit the line beyond that.  Ie, if I try to replace
'foo' with 'bar', I would normally do: '<esc>FfRbar',
but the esc there is being grabbed by cgdb and sending
me into the source window.

Is there a workaround for this?

Re: [Cgdb-users] Going from 5.3 to 6.3, identifying the active window became harder

[Bob R. <bob...@co...>]

On Wed, Nov 29, 2006 at 09:04:54AM +0100, Karsten Sievert wrote:
> Hi, Mike,
> 
> thanks for verifying.  If I understand my setup correctly, it's not
> Cygwin which is providing the terminal emulation; it should be
> eXceed.  Cygwin is then used to mirror the whole screen of the
> terminal PC onto my desktop.
> 
> My observation is that the line and the center line number (when
> blue) is never bold; for you it was always bold.  That may be the
> same issue, if the bold/non-bold switch doen't work, though.
> More details later, I have to start working.
> 

Hi Karsten,

Any more details?

I'm trying to push out another release. It could be a few weeks, but
if you want this fixed, let us know.

Bob Rossi

Re: [Cgdb-users] Going from 5.3 to 6.3, identifying the active window became harder

[Karsten S. <kar...@sy...>]

Hi, Mike,

thanks for verifying.  If I understand my setup correctly, it's not
Cygwin which is providing the terminal emulation; it should be
eXceed.  Cygwin is then used to mirror the whole screen of the
terminal PC onto my desktop.

My observation is that the line and the center line number (when
blue) is never bold; for you it was always bold.  That may be the
same issue, if the bold/non-bold switch doen't work, though.
More details later, I have to start working.


Thanks
-Karsten

Mike Mueller wrote:
> Karsten's right, I just tested this on cygwin.  In 0.5.3, the vertical
> line is bold when the source window is focused.  In 0.6.3, it's always
> bold, whether focused or not.  It does seem like the relevant code
> hasn't changed, but clearly something broke.  I'll take a look.
> 
> Mike

Re: [Cgdb-users] Going from 5.3 to 6.3, identifying the active window became harder

[Mike M. <mi...@su...>]

Karsten,

I misunderstood your original problem statement, sorry

I never run CGDB on a white background, personally.  When I tested it
with a black background, everything was bold all the time, which is a
bug we should fix.

However, just now I tested it with a white background on Cygwin.  The
vertical bar toggles between gray when focused and black when not
focused.  I'm not sure if this behavior was intended or not.  I'm not
seeing any blue bars anywhere, though. :)

Is there a way you can post a screenshot of what you're seeing?  We
can try to work out a more intuitive way of indicating focus, too.

Thanks for the comments.

Thanks,
Mike

On 11/28/06, Mike Mueller <mi...@su...> wrote:
> Karsten's right, I just tested this on cygwin.  In 0.5.3, the vertical
> line is bold when the source window is focused.  In 0.6.3, it's always
> bold, whether focused or not.  It does seem like the relevant code
> hasn't changed, but clearly something broke.  I'll take a look.
>
> Mike
>
> On 11/28/06, Karsten Sievert <kar...@sy...> wrote:
> > Hi, Bob,
> >
> > thanks for the quick response.
> >
> > Bob Rossi wrote:
> > > Well, the svn version of CGDB has support for macros. That is,
> > > it supports the "map" command. It hasn't been released yet
> > > because it's not fully tested, and there is no documentation
> > > for the commands, and if you do a 'map a a' it will loop
> > > forever, and never return. With that in mind, you could try
> > > the svn version, and see if you could make some macro's that
> > > would suit your needs. Currently it only supports the 'map'
> > > and 'unmap' command. However, if you desired support for the
> > > 'imap' command, I could code that up without to much effort
> > > based on the existing code. Let me know if you are interested
> > > in any of this.
> >
> > Yes, I might be.  This is what I'm gonna do:  If I manage to
> > check out the SVN version (time is the limiting factor here),
> > then I'll ask for dos and don'ts and try to come up with
> > something useful.
> >
> > > OK, something isn't correct here. There was no intention of
> > > changing CGDB's behavior between .5.3 and .6.3. In fact, when
> > > I run .5.3 and .6.3 in a white xterm, both versions show the
> > > vertical line as being bold.
> > ...
> > > If you are happy with the A_BOLD functionality, but this
> > > changes the color of your vertical line somehow, we need more info.
> > > Have you tested both .5.3 and .6.3 in the same term environment and
> > > noticed these differences?
> >
> > Yes, it was even the same window, I used a different window to
> > compile 0.6.3 and restarted cgdb in the first; what was black BG
> > first became white BG now.  I'm using eXceed xterms which show a
> > linux shell, and remote-display that through Cytrix.  If I am not
> > mistaken, than cgdb sees the Hummingbird eXceed terminal emulation
> > in this setup.  The separator switches from black to blue if I
> > activate the source window, but is not bold.  The current line
> > number in the middle of the screen when I scroll is also not bold.
> > The active line (green arrow), the red breakpoint line numbers,
> > and fixed strings and much more in C style syntax highlight are
> > bold, though.  I can see the statement "return" colored in
> > bold blue.  There must be subtle difference somewhere...
> >
> > If you think this is no longer a "users" thread, pls. answer on
> > "devel".
> >
> >
> > Thanks for the support!
> > -Karsten
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Cgdb-users mailing list
> > Cgd...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgdb-users
> >
>

Re: [Cgdb-users] Going from 5.3 to 6.3, identifying the active window became harder

[Bob R. <bob...@co...>]

Karsten, what environment are you running CGDB in? 
ie. xterm/linux putty/cygwin ?

Thanks,
Bob Rossi

On Tue, Nov 28, 2006 at 01:35:56PM -0500, Mike Mueller wrote:
> Karsten's right, I just tested this on cygwin.  In 0.5.3, the vertical
> line is bold when the source window is focused.  In 0.6.3, it's always
> bold, whether focused or not.  It does seem like the relevant code
> hasn't changed, but clearly something broke.  I'll take a look.
> 
> Mike
> 
> On 11/28/06, Karsten Sievert <kar...@sy...> wrote:
> > Hi, Bob,
> >
> > thanks for the quick response.
> >
> > Bob Rossi wrote:
> > > Well, the svn version of CGDB has support for macros. That is,
> > > it supports the "map" command. It hasn't been released yet
> > > because it's not fully tested, and there is no documentation
> > > for the commands, and if you do a 'map a a' it will loop
> > > forever, and never return. With that in mind, you could try
> > > the svn version, and see if you could make some macro's that
> > > would suit your needs. Currently it only supports the 'map'
> > > and 'unmap' command. However, if you desired support for the
> > > 'imap' command, I could code that up without to much effort
> > > based on the existing code. Let me know if you are interested
> > > in any of this.
> >
> > Yes, I might be.  This is what I'm gonna do:  If I manage to
> > check out the SVN version (time is the limiting factor here),
> > then I'll ask for dos and don'ts and try to come up with
> > something useful.
> >
> > > OK, something isn't correct here. There was no intention of
> > > changing CGDB's behavior between .5.3 and .6.3. In fact, when
> > > I run .5.3 and .6.3 in a white xterm, both versions show the
> > > vertical line as being bold.
> > ...
> > > If you are happy with the A_BOLD functionality, but this
> > > changes the color of your vertical line somehow, we need more info.
> > > Have you tested both .5.3 and .6.3 in the same term environment and
> > > noticed these differences?
> >
> > Yes, it was even the same window, I used a different window to
> > compile 0.6.3 and restarted cgdb in the first; what was black BG
> > first became white BG now.  I'm using eXceed xterms which show a
> > linux shell, and remote-display that through Cytrix.  If I am not
> > mistaken, than cgdb sees the Hummingbird eXceed terminal emulation
> > in this setup.  The separator switches from black to blue if I
> > activate the source window, but is not bold.  The current line
> > number in the middle of the screen when I scroll is also not bold.
> > The active line (green arrow), the red breakpoint line numbers,
> > and fixed strings and much more in C style syntax highlight are
> > bold, though.  I can see the statement "return" colored in
> > bold blue.  There must be subtle difference somewhere...
> >
> > If you think this is no longer a "users" thread, pls. answer on
> > "devel".
> >
> >
> > Thanks for the support!
> > -Karsten
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Cgdb-users mailing list
> > Cgd...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgdb-users
> >
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Cgdb-users mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-users

Re: [Cgdb-users] Going from 5.3 to 6.3, identifying the active window became harder

[Mike M. <mi...@su...>]

Karsten's right, I just tested this on cygwin.  In 0.5.3, the vertical
line is bold when the source window is focused.  In 0.6.3, it's always
bold, whether focused or not.  It does seem like the relevant code
hasn't changed, but clearly something broke.  I'll take a look.

Mike

On 11/28/06, Karsten Sievert <kar...@sy...> wrote:
> Hi, Bob,
>
> thanks for the quick response.
>
> Bob Rossi wrote:
> > Well, the svn version of CGDB has support for macros. That is,
> > it supports the "map" command. It hasn't been released yet
> > because it's not fully tested, and there is no documentation
> > for the commands, and if you do a 'map a a' it will loop
> > forever, and never return. With that in mind, you could try
> > the svn version, and see if you could make some macro's that
> > would suit your needs. Currently it only supports the 'map'
> > and 'unmap' command. However, if you desired support for the
> > 'imap' command, I could code that up without to much effort
> > based on the existing code. Let me know if you are interested
> > in any of this.
>
> Yes, I might be.  This is what I'm gonna do:  If I manage to
> check out the SVN version (time is the limiting factor here),
> then I'll ask for dos and don'ts and try to come up with
> something useful.
>
> > OK, something isn't correct here. There was no intention of
> > changing CGDB's behavior between .5.3 and .6.3. In fact, when
> > I run .5.3 and .6.3 in a white xterm, both versions show the
> > vertical line as being bold.
> ...
> > If you are happy with the A_BOLD functionality, but this
> > changes the color of your vertical line somehow, we need more info.
> > Have you tested both .5.3 and .6.3 in the same term environment and
> > noticed these differences?
>
> Yes, it was even the same window, I used a different window to
> compile 0.6.3 and restarted cgdb in the first; what was black BG
> first became white BG now.  I'm using eXceed xterms which show a
> linux shell, and remote-display that through Cytrix.  If I am not
> mistaken, than cgdb sees the Hummingbird eXceed terminal emulation
> in this setup.  The separator switches from black to blue if I
> activate the source window, but is not bold.  The current line
> number in the middle of the screen when I scroll is also not bold.
> The active line (green arrow), the red breakpoint line numbers,
> and fixed strings and much more in C style syntax highlight are
> bold, though.  I can see the statement "return" colored in
> bold blue.  There must be subtle difference somewhere...
>
> If you think this is no longer a "users" thread, pls. answer on
> "devel".
>
>
> Thanks for the support!
> -Karsten
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Cgdb-users mailing list
> Cgd...@li...
> https://lists.sourceforge.net/lists/listinfo/cgdb-users
>

Re: [Cgdb-users] Going from 5.3 to 6.3, identifying the active window became harder

[Karsten S. <kar...@sy...>]

Hi, Bob,

thanks for the quick response.

Bob Rossi wrote:
> Well, the svn version of CGDB has support for macros. That is,
> it supports the "map" command. It hasn't been released yet 
> because it's not fully tested, and there is no documentation 
> for the commands, and if you do a 'map a a' it will loop
> forever, and never return. With that in mind, you could try
> the svn version, and see if you could make some macro's that
> would suit your needs. Currently it only supports the 'map' 
> and 'unmap' command. However, if you desired support for the 
> 'imap' command, I could code that up without to much effort 
> based on the existing code. Let me know if you are interested
> in any of this. 

Yes, I might be.  This is what I'm gonna do:  If I manage to
check out the SVN version (time is the limiting factor here),
then I'll ask for dos and don'ts and try to come up with
something useful.

> OK, something isn't correct here. There was no intention of 
> changing CGDB's behavior between .5.3 and .6.3. In fact, when
> I run .5.3 and .6.3 in a white xterm, both versions show the 
> vertical line as being bold.
...
> If you are happy with the A_BOLD functionality, but this 
> changes the color of your vertical line somehow, we need more info.
> Have you tested both .5.3 and .6.3 in the same term environment and
> noticed these differences?

Yes, it was even the same window, I used a different window to
compile 0.6.3 and restarted cgdb in the first; what was black BG
first became white BG now.  I'm using eXceed xterms which show a
linux shell, and remote-display that through Cytrix.  If I am not
mistaken, than cgdb sees the Hummingbird eXceed terminal emulation
in this setup.  The separator switches from black to blue if I
activate the source window, but is not bold.  The current line
number in the middle of the screen when I scroll is also not bold.
The active line (green arrow), the red breakpoint line numbers,
and fixed strings and much more in C style syntax highlight are
bold, though.  I can see the statement "return" colored in
bold blue.  There must be subtle difference somewhere...

If you think this is no longer a "users" thread, pls. answer on
"devel".


Thanks for the support!
-Karsten

Re: [Cgdb-users] Going from 5.3 to 6.3, identifying the active window became harder

[Bob R. <bob...@co...>]

On Tue, Nov 28, 2006 at 01:06:54PM +0100, Karsten Sievert wrote:
> Hi, Team,
> 
> let me first mention that I am very happy about CGDB.
> It's fast, lean, and matches my preferred editor's user
> interface -- great.
> 
> The feature which I'm missing most is the stack window,
> and a way to display variables from the source window,
> but that's another story.

This is a planned feature, but it'll be a long time before
it's implemented. I'm currently very busy, and in the 
small time I get, am working on the communication between
cgdb and gdb.

> Since I mentioned this:  I find myself typing "p varname"
> into the source window again and again, and only then
> realize that I just set a breakpoint and triggered other
> random actions, dependent on the variable name.  Can I
> create a macro which sets me into "insert" (tgdb) mode
> or on the command line (probably more consistent) when I
> type the 'p', and returns me to the source window after
> hitting 'Enter'?  That would be neat.  But back to the
> subject:

Well, the svn version of CGDB has support for macros. That is,
it supports the "map" command. It hasn't been released yet 
because it's not fully tested, and there is no documentation 
for the commands, and if you do a 'map a a' it will loop
forever, and never return. With that in mind, you could try
the svn version, and see if you could make some macro's that
would suit your needs. Currently it only supports the 'map' 
and 'unmap' command. However, if you desired support for the 
'imap' command, I could code that up without to much effort 
based on the existing code. Let me know if you are interested
in any of this. 

> With the new highlighting scheme, (which is great!) I
> noticed that it has become harder to identify the active
> window.  In 5.3, the vertical bar which separated the
> line numbers from the source code used to be bold if the
> source window was active; not it changes from black to
> blue, which on white BG is very subtle.  Now, the cursor
> on the tgdb prompt is the better indication, but that's
> as far away from the source code as can be.

OK, something isn't correct here. There was no intention of 
changing CGDB's behavior between .5.3 and .6.3. In fact, when
I run .5.3 and .6.3 in a white xterm, both versions show the 
vertical line as being bold.

The code in .6.3 that draws the vertical bar looks like:
                if (focus)
                    wattron(sview->win, A_BOLD);
                waddch(sview->win, VERT_LINE);
                if (focus)
                    wattroff(sview->win, A_BOLD);

> Have I overlooked a highlight group which represents this
> separator, or is the color change on it hard coded?
> Does anybody have a non-approved patch, may be, which
> helps me?  ;-)

There isn't a highlight group which represents the separator.
It's hardcoded to A_BOLD. It wouldn't be much effort to add 
the new group if you are not happy with the A_BOLD functionality.
I can explain how, and will accept a patch, but I don't have the 
time to work on it.

If you are happy with the A_BOLD functionality, but this 
changes the color of your vertical line somehow, we need more info.
Have you tested both .5.3 and .6.3 in the same term environment and
noticed these differences?

Thanks,
Bob Rossi

[Cgdb-users] Going from 5.3 to 6.3, identifying the active window became harder

[Karsten S. <kar...@sy...>]

Hi, Team,

let me first mention that I am very happy about CGDB.
It's fast, lean, and matches my preferred editor's user
interface -- great.

The feature which I'm missing most is the stack window,
and a way to display variables from the source window,
but that's another story.

Since I mentioned this:  I find myself typing "p varname"
into the source window again and again, and only then
realize that I just set a breakpoint and triggered other
random actions, dependent on the variable name.  Can I
create a macro which sets me into "insert" (tgdb) mode
or on the command line (probably more consistent) when I
type the 'p', and returns me to the source window after
hitting 'Enter'?  That would be neat.  But back to the
subject:

With the new highlighting scheme, (which is great!) I
noticed that it has become harder to identify the active
window.  In 5.3, the vertical bar which separated the
line numbers from the source code used to be bold if the
source window was active; not it changes from black to
blue, which on white BG is very subtle.  Now, the cursor
on the tgdb prompt is the better indication, but that's
as far away from the source code as can be.

Have I overlooked a highlight group which represents this
separator, or is the color change on it hard coded?
Does anybody have a non-approved patch, may be, which
helps me?  ;-)


Thanks for the work and support!
-Karsten

Re: [Cgdb-users] Re: cgdb green arrow to current line of source to be executed

[Benjamin F. <bf...@gm...>]

I'll compile it next time i get a chance.  thanks for the change

-ben

On 6/20/05, Bob Rossi <bo...@br...> wrote:
> On Fri, Jun 17, 2005 at 08:46:40PM -0400, Mike Mueller wrote:
> > This is definitely doable, I'll check into it and get back to you.
>=20
> Hi all,
>=20
> In case anyone's interested, Mike committed this change to CVS. It will
> be a few weeks before I get another release out because I'm extremely
> busy and I also want to package readline with CGDB. So Benjamin, if you
> want to try that feature right away, try out CVS, it's stable enough to
> use.
>=20
> Here are the features mike told me about, since it's still uncommented.
>=20
>    :set arrowstyle=3Dshort (default)
>       The usual little arrow that we provide
>    :set arrowstyle=3Dlong
>       An arrow that extends from the line number out to the start of the
>       given line.  Not too obtrusive but easier to follow.
>    :set arrowstyle=3Dhighlight
>       No actual arrow drawn.  The line is drawn in black-on-green
>       text, so the entire line is highlighted across the screen.  Very
>       obtrusive.
>=20
> The short version of arrowstyle is "as". So, "set as=3Dlong".
>=20
> Just in case anyone's interested, "long" is my personal favorite and is
> going to go into my .cgdb/cgdbrc for now :)
>=20
> Thanks Mike!
> Bobby
>=20
>=20
>