Emacs 22

Linonut wrote:

> I've been looking for an excuse to use emacs. I'd used micro-emacs
> years ago, but haven't really enjoyed it lately, for various reasons.
>
> I've also been looking for the "ideal" debugging environment. I
> actually wouldn't mind using bare gdb, except for one nagging issue: no
> "current line" pointer when listing code (as far as I've found, anyway).
> I do like cgdb, but it is also pretty bare-bones, adding only a
> source-code window and an optional output window. I've looked at
> Insight, tried to use vim plugins (which would really be my preference),
> I've tried the old xxgdb, I don't mind ddd, a bit ugly, though. I've
> thought about KDevelop or Anjuta, but am not keen on mucking about with
> an IDE just to debug, at this moment.
>
> So I hear about the new emacs, first major release in a few years, and
> how it has greatly enhanced the debugging. So I thought I'd give it
> another try.
>
> It's pretty cool. You can set it up to have 5 panes (source, stack,
> locals, gdb command-line, and breakpoints), and its got the
> click-n-drool interface, too. It will also bring up watch windows for
> keeping tabs on data/structures.
>
> It isn't perfect, and I don't really like emacs way of handling its
> configuration items, but I think this may get me to use emacs a little
> more, and start mastering those Ctrl-x Ctrl-y Ctrl-z commands.
>

You need to stick with it, there are some logical combinations. Within a
fairly short while (within the time it takes to do the tutorial realy) you
will have all the basic movement keys off pat, then the rest as and when
you use them.

It is always Control or Meter (ALT), but if you use the C and M as the
tutorials do, then some of the commands can be read in english, but others
make a nice little pattern which is easy for your subconcious to remember.
It will sink in particularly well if you are concentrating on your
programming and let your subconcious take care of remembering keys.

Many an emacs user, if you say 'What keys is it to do {something} with' will
answer 'I don't know', because even if it is an often used key combination,
it's the pattern they remember rather than the keys. So they have to do it
to tell you what the keys were. You would be like that too is a fairly
short time.

I bet that isn't too unlike the way you use Vim, How do you find and replace
text in Vi? Did you just mentally press the keys to remember, or did you
mind instantly provide an example line, something like this,
%s/dog/cat/gc

Your mind is great at remembering patterns and pattern matching, as long as
it can place words and numbers in pattern form into memory then you'll have
absolutely no trouble remembering them.


I was trying to remember the old Vi patterns we used to have apprentices do
years ago, I can't remember the more fun one, but one of them was you
started with 26 lines each containing the alphabet. Then you start by
moving to the virtical and horizontal centre.

You now have to spiral and delete as you go, so you would move right,
delete, down, delete, left, delete, up and so on. From about half way (or
less) you are no longer thinking of the key combinations at all, instead
you are only thinking right, delete, down, delete, left, delete, up ...

But you carry on anyway, because by the time you have deleted all of the
characters you will never have to think of those key combinations again,
just the direction you want to go.


Then they was another spiral that was words instead of characters, one in
particular was a seemingly random page of words, but if you did it right
you ended up with a line something like 'Well done you have mastered
words'.

But anyway although I don't have the page anymore, the theory is the same,
just a page of text and spiral down,by the end you should have the
combinations needed embedded in your mind.

LEE Sau Dan <danlee DeleteThis @informatik.uni-freiburg.de> writes:

> Did you ever try ECB?

ECB has nothing to do with gdb which he discusses there. But yes, ecb
and cedet can add a lot.

gdba is what he wants.

,----
| gdba is an interactive autoloaded Lisp function in `gdb-ui'.
| (gdba command-line)
|
| Run gdb on program FILE in buffer *gud-FILE*.
| The directory containing FILE becomes the initial working directory
| and source-file directory for your debugger.
|
| If `gdb-many-windows' is nil (the default value) then gdb just
| pops up the GUD buffer unless `gdb-show-main' is t. In this case
| it starts with two windows: one displaying the GUD buffer and the
| other with the source file with the main routine of the inferior.
|
| If `gdb-many-windows' is t, regardless of the value of
| `gdb-show-main', the layout below will appear unless
| `gdb-use-separate-io-buffer' is nil when the source buffer
| occupies the full width of the frame. Keybindings are shown in
| some of the buffers.
|
| Watch expressions appear in the speedbar/slowbar.
|
| The following commands help control operation :
|
| `gdb-many-windows' - Toggle the number of windows gdb uses.
| `gdb-restore-windows' - To restore the window layout.
|
| See Info node `(emacs)GDB Graphical Interface' for a more
| detailed description of this mode.
`----


--

>>>>> "Linonut" == Linonut <linonut RemoveThis @bellsouth.net> writes:

Linonut> I've also been looking for the "ideal" debugging
Linonut> environment. I actually wouldn't mind using bare gdb,
Linonut> except for one nagging issue: no "current line" pointer
Linonut> when listing code (as far as I've found, anyway).

What? If you started gdb with M-x gdb, you should get a "current
line" mark. This has been so for more than 10 years.


Linonut> It's pretty cool. You can set it up to have 5 panes
Linonut> (source, stack, locals, gdb command-line, and
Linonut> breakpoints), and its got the click-n-drool interface,
Linonut> too. It will also bring up watch windows for keeping
Linonut> tabs on data/structures.

Did you ever try ECB?



--
Lee Sau Dan §õ¦u´° ~{@nJX6X~}

E-mail: danlee RemoveThis @informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

After takin' a swig o' grog, LEE Sau Dan belched out this bit o' wisdom:

>>>>>> "Linonut" == Linonut <linonut.DeleteThis@bellsouth.net> writes:
>
> Linonut> I've also been looking for the "ideal" debugging
> Linonut> environment. I actually wouldn't mind using bare gdb,
> Linonut> except for one nagging issue: no "current line" pointer
> Linonut> when listing code (as far as I've found, anyway).
>
> What? If you started gdb with M-x gdb, you should get a "current
> line" mark. This has been so for more than 10 years.

I was talking about standalone gdb. I thought it would mark the active
source-code line with an asterisk or some other marker, the way cgdb
does.

> Linonut> It's pretty cool. You can set it up to have 5 panes
> Linonut> (source, stack, locals, gdb command-line, and
> Linonut> breakpoints), and its got the click-n-drool interface,
> Linonut> too. It will also bring up watch windows for keeping
> Linonut> tabs on data/structures.
>
> Did you ever try ECB?

No. But it looks pretty cool, almost like an IDE. I'll try to try it
out sometime soon.

--
Tux rox!

On Mon, 30 Jul 2007 19:51:04 GMT, Linonut <linonut RemoveThis @bellsouth.net> wrote:
> After takin' a swig o' grog, LEE Sau Dan belched out this bit o' wisdom:

>> What? If you started gdb with M-x gdb, you should get a "current
>> line" mark. This has been so for more than 10 years.
>
> I was talking about standalone gdb. I thought it would mark the active
> source-code line with an asterisk or some other marker, the way cgdb
> does.

gdb --tui


--
-| Bob Hauck
-| "Reality has a well-known liberal bias." -- Stephen Colbert
-| http://www.haucks.org/

After takin' a swig o' grog, Bob Hauck belched out this bit o' wisdom:

> On Mon, 30 Jul 2007 19:51:04 GMT, Linonut <linonut.DeleteThis@bellsouth.net> wrote:
>> After takin' a swig o' grog, LEE Sau Dan belched out this bit o' wisdom:
>
>>> What? If you started gdb with M-x gdb, you should get a "current
>>> line" mark. This has been so for more than 10 years.
>>
>> I was talking about standalone gdb. I thought it would mark the active
>> source-code line with an asterisk or some other marker, the way cgdb
>> does.
>
> gdb --tui

Thanks, Bob!

Makes me wonder why that guy wrote cgdb.

Makes me wonder how I missed that little option!

--
Tux rox!

There's also dbvi: http://dbvi.sourceforge.net/

dbvi integrates vi and gdb by actually using vi, so you can the full
functionality of vi.

It also is useful for debugging other full-screen terminal based
applications as it detects terminal control characters and opens an
xterm to display the screen for the app (or allows screen toggling
between the app and the dbvi window on non X terminals).