Re: Emacs vs GPS vs Eclipse, Ada vs Lisp vs Lua vs Java

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 12 Mar 2011 07:53:48 -0500, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 11 Mar 2011 04:12:40 -0500, Stephen Leake wrote:
>>>
>>>> Last I checked, GPS doesn't do VHDL, LaTeX, Maxima, Matlab, bash mode,
>>>> make mode, monotone, read/send mail; all tools I need in my integrated
>>>> development environment.
>
> I don't want a mail-sending IDE.

I often need to quote parts of code in email; it's convenient if the
code and the email are in the same tool.

In addition, many editing operations are similar between code and email;
cut/paste, fill, spellcheck. So I prefer a consistent interface, which
is much easier to achieve with a single tool.

>>>> If GPS can do dynamically loaded Ada with source-code debugging, that
>>>> would be a huge selling point.
>>> [...]
>>>> Apparently Java is used this way in Eclipse; does that have source-code
>>>> debugging for dynamically loaded subprograms?
>>>
>>> You can start GPS in a command mode listening for connections from the
>>> program being debugged and navigate the project sources from there. (It is
>>> a huge help when debugging GtkAda applications.) You can walk the call
>>> stack from an exception handler or at any point you wanted, without messing
>>> up with gdb (which does not work anyway).
>> 
>> I gather you are saying you can use one GPS instance to debug the Ada
>> code in another GPS instance.
>
> No, I mean that you can communicate to GPS from your Ada program, e.g.
> while debugging it.
>
>> That makes sense; in this mode, GPS is a
>> front-end for gdb. Emacs can do the same thing.
>
> gdb is garbage. 

You seem to not understand how GPS works; it uses gdb as the backend for
all debugging operations. This is true of all frontends for the Gnu toolset.

> But even if there were a decent debugger for GNAT, 

There is; gdb.

gdb is a backend. You can use it directly from the command line (I
actually often prefer that), or via a front end such as Emacs or GPS.
The front end displays the appropriate source, allows setting
breakpoints, and also displays specified variables, the current CPU
registers, etc. I don't think GPS  is significantly different in
functionality from Emacs here; it is  different in the details of how
the windows are manipulated.

> you may want to have some tracing tool. GPS gives you an opportunity
> to browse the sources while tracing.

That capability is based on gdb reporting the source line relevant to
the current code position. Emacs and GPS both provide ways to display
that source code.

>> But I have debugged GtkAda programs at that level, and it is not nearly
>> as productive (for the task of implementing simple GUIs for programmer
>> tools) as the Emacs environment. Mostly because the edit/compile/test
>> cycle for a single subprogram is much faster in the Emacs environment.
>
> I am not sure how it can be faster than in GPS: F4, shift+F2. 

That's just the first keystrokes. How long does it take after that
before the results are known?

In particular, since you have to restart GPS to see the change, you have
to rerun the steps needed to get to the point where the bug occured.
For example, suppose I'm working on DVC, the Emacs front end to
monotone. One operation is to review changed files, collect a commit
statement, and do the commit. If the last step is failing, I have to
repeat the other steps each time I want to try a bug fix.

In Emacs, the context doesn't change when I recompile one elisp
program; I don't have to repeat anything.

You'll have to try it to truly appreciate the difference.

> Debugging GtkAda with gdb cannot work, because GTK does not use
> exceptions to indicate errors. 

You can still set break points in the error handling code.

> Also if you stop GTK in an unfortunate
> state, you would corrupt GUI in a way unrelated to the original
> problem. 

Yes, that is true of GUIs in general.

But it is better in Emacs, because the elisp is at a higher level; the
low level GUI operations are not interrupted by elisp breakpoints.

So you are supporting my position that debugging GUIs is better in Emacs
than in GPS.

> It is similar to real-time applications, which break when stepped.
> Tracing works much better and an ability to ask GPS to show the source
> where the message came from is a great help.

What, exactly, do you mean by "tracing"?

Emacs elisp uses that term to mean roughly "display the source lines as
they are executed". I rarely use that mode in Emacs. In realtime code it
can be useful, but any IO can change the timing.

-- 
-- Stephe