Very simple IDE for programming newbie

Very simple IDE for programming newbie

[Sean McAfee]

I've started teaching my fiancée some basic C programming.  After the
first few lessons on her Windows laptop, using Notepad as the editor
and a Cygwin shell for compiling and running, I decided that a more
integrated environment was called for (not to mention a more capable
editor).

Although I use Emacs every day, I thought that it might be too
overwhelming for someone with little programming experience.  I tried
Eclipse first, but after much wrangling I just couldn't get it to work
with Cygwin's compiler tools.  Though I'm ashamed to admit it, I tried
a free version of Microsoft's Visual Studio next, but it requires a
bunch of arcane Microsoft cruft in and around main() just to compile a
simple "Hello World!" type console program, and I wasn't comfortable
telling my student to just ignore it.  So, I was finally led back to
consider Emacs again.  I've been working through the tutorial with
her, and her response has been quite gratifying.  After learning about
Emacs's cursor-motion commands, she was excited that she'd be able to
save a lot of time at work (she's a nurse and has to enter a lot of
text using a dedicated application).  I sadly had to disappoint her by
telling her that her new skills weren't widely applicable outside of
Emacs.  But it was nice to see her get excited about editing text.

So now we're just about done with the tutorial and ready to get back
into actual coding again.  I've been thinking of whipping up a very
simple development environment for her, maybe as simple as a single
command that does the following:

* Execute the compile command using "gcc this-file.c" as the command
  to run.
* If there were any errors, halt.  (Then I teach her about
  next-error).
* Otherwise, launch the terminal emulator, killing any that might
  already exist, and run the newly-compiled executable in it.

Something this simple should suffice for quite some time, I think.  My
question is, does something similar already exist, possibly with other
useful features that I haven't thought of?

If nothing like that exists, I could use some pointers about detecting
when the (asynchronous) compile command has finished running, and
whether there were any errors.  That's the one part I haven't quite
figured out how to do yet.

Re: Very simple IDE for programming newbie

[Pascal J. Bourguignon]

Sean McAfee <eefacm@gmail.com> writes:

> I've started teaching my fiancée some basic C programming.  After the
> first few lessons on her Windows laptop, using Notepad as the editor
> and a Cygwin shell for compiling and running, I decided that a more
> integrated environment was called for (not to mention a more capable
> editor).
>
> Although I use Emacs every day, I thought that it might be too
> overwhelming for someone with little programming experience.  

If emacs can be used by american secretaries, why couldn't it be used
by your fiancée?

http://www.gnu.org/gnu/rms-lisp.html


> [...]  So, I was finally led back to
> consider Emacs again.  I've been working through the tutorial with
> her, and her response has been quite gratifying.  After learning about
> Emacs's cursor-motion commands, she was excited that she'd be able to
> save a lot of time at work (she's a nurse and has to enter a lot of
> text using a dedicated application).  I sadly had to disappoint her by
> telling her that her new skills weren't widely applicable outside of
> Emacs.  But it was nice to see her get excited about editing text.

Depends.  On MacOSX, most applications do not disable the "standard"
emacs keybindings of the NSTextField, so that there's no too much pain
in using MacOSX applications.


> So now we're just about done with the tutorial and ready to get back
> into actual coding again.  I've been thinking of whipping up a very
> simple development environment for her, maybe as simple as a single
> command that does the following:
>
> * Execute the compile command using "gcc this-file.c" as the command
>   to run.

M-x compile RET this-file RET
M-x recompile RET

Notice that make is able to compile a single-file C program without a
Makefile.


> * If there were any errors, halt.  (Then I teach her about
>   next-error).

C-x `


> * Otherwise, launch the terminal emulator, killing any that might
>   already exist, and run the newly-compiled executable in it.

M-x shell RET
./this-file


Also, for non-interactive programs, you can do it at once with:

M-x compile RET C-e && ./this-file RET


I also use this:

(defvar *compile-and-run-cflags*
  (let ((prefix "."))
    (format  "-I%s -L%s" prefix prefix)))

(defun compile-and-run (mode)
  (interactive "p")
  (flet ((name (path)
           (when (string-match "^.*/\\([^./]*\\)\\.[^/.]*$" path)
             (match-string 1 path)))
         (type (path)
           (when (string-match "^.*/[^./]*\\.\\([^/.]*\\)$" path)
             (match-string 1 path))))
    (let* ((src (buffer-file-name (current-buffer)))
           (compiler (or (cdr (assoc* (type src)
                                      '(("c++" . "g++")
                                        ("cpp" . "g++")
                                        ("cxx" . "g++")
                                        ("C" . "g++"))
                                      :test (function string=)))
                         "gcc")))
      (message "src=%S" src)
      (message "exe=%S"  (name src))
      (compile
       (format "SRC=%S ; EXE=%S ; %s %s -g3 -ggdb3 -o ${EXE} ${SRC} && %s ./${EXE} && echo status = $?"
               src (name src) compiler *compile-and-run-cflags*
               (case mode
                 ((4) "valgrind")
                 (otherwise "")))))))

which allows you to compile and run a single-file program with some
additionnal libraries configured in *Compile-and-run-cflags*.



> Something this simple should suffice for quite some time, I think.  My
> question is, does something similar already exist, possibly with other
> useful features that I haven't thought of?

There are more sophisticated features available in emacs,
(eg. speedbar, cedet, etc) but frankly, 99% of my C programming in
emacs is done only with those.

One thing that could be useful once you get at multi-file projects, is
etags and M-.



> If nothing like that exists, I could use some pointers about detecting
> when the (asynchronous) compile command has finished running, and
> whether there were any errors.  That's the one part I haven't quite
> figured out how to do yet.

You don't have to wait for the end of the compilation to browse the
errors.  Otherwise, just watch the status bar of the *compilation*
window, it will say (Compilation:exit [<status-code>]) when done.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Very simple IDE for programming newbie

[Sean McAfee]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Sean McAfee <eefacm@gmail.com> writes:
> Also, for non-interactive programs, you can do it at once with:
>
> M-x compile RET C-e && ./this-file RET

Hmm, good idea.  I'm trying to look ahead to when we get to
interactive programs too, though.

> You don't have to wait for the end of the compilation to browse the
> errors.  Otherwise, just watch the status bar of the *compilation*
> window, it will say (Compilation:exit [<status-code>]) when done.

I know; my question was how to a) know when the asynchronous
compilation process has finished, and b) tell whether there were any
errors, so that if there were none, I can immediately launch the
newly-compiled program in a terminal emulator.

I think the terminal emulator would be preferable to shell-mode, since
in the former case there's only one keystroke that could introduce
some confusion (C-c) and in the latter case there are many.

Re: Very simple IDE for programming newbie

[Pascal J. Bourguignon]

Sean McAfee <eefacm@gmail.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> Sean McAfee <eefacm@gmail.com> writes:
>> Also, for non-interactive programs, you can do it at once with:
>>
>> M-x compile RET C-e && ./this-file RET
>
> Hmm, good idea.  I'm trying to look ahead to when we get to
> interactive programs too, though.
>
>> You don't have to wait for the end of the compilation to browse the
>> errors.  Otherwise, just watch the status bar of the *compilation*
>> window, it will say (Compilation:exit [<status-code>]) when done.
>
> I know; my question was how to a) know when the asynchronous
> compilation process has finished, and b) tell whether there were any
> errors, so that if there were none, I can immediately launch the
> newly-compiled program in a terminal emulator.
>
> I think the terminal emulator would be preferable to shell-mode, since
> in the former case there's only one keystroke that could introduce
> some confusion (C-c) and in the latter case there are many.

I would just do that:

M-x compile RET C-e && ( xterm -e ./this-file & ) RET


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Very simple IDE for programming newbie

[Richard Riley]

Sean McAfee <eefacm@gmail.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
>> Sean McAfee <eefacm@gmail.com> writes:
>> Also, for non-interactive programs, you can do it at once with:
>>
>> M-x compile RET C-e && ./this-file RET
>
> Hmm, good idea.  I'm trying to look ahead to when we get to
> interactive programs too, though.
>
>> You don't have to wait for the end of the compilation to browse the
>> errors.  Otherwise, just watch the status bar of the *compilation*
>> window, it will say (Compilation:exit [<status-code>]) when done.
>
> I know; my question was how to a) know when the asynchronous
> compilation process has finished, and b) tell whether there were any
> errors, so that if there were none, I can immediately launch the
> newly-compiled program in a terminal emulator.
>
> I think the terminal emulator would be preferable to shell-mode, since
> in the former case there's only one keystroke that could introduce
> some confusion (C-c) and in the latter case there are many.
>

I would get into the habit of running/testing it using gdb too. Google
up gud-gdb. Nice emacs interface to the debugger.

Interesting nurse...
 

Re: Very simple IDE for programming newbie

[Peter Dyballa]

Am 03.01.2010 um 17:10 schrieb Sean McAfee:

> I know; my question was how to a) know when the asynchronous
> compilation process has finished, and b) tell whether there were any
> errors, so that if there were none, I can immediately launch the
> newly-compiled program in a terminal emulator.


The *compilation* buffer's mode-line expresses such things.

--
Greetings

   Pete

A lot of us are working harder than we want, at things we don't like  
to do. Why? ...In order to afford the sort of existence we don't care  
to live.
				– Bradford Angier

Re: Very simple IDE for programming newbie

[Sean McAfee]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 03.01.2010 um 17:10 schrieb Sean McAfee:
>> I know; my question was how to a) know when the asynchronous
>> compilation process has finished, and b) tell whether there were any
>> errors, so that if there were none, I can immediately launch the
>> newly-compiled program in a terminal emulator.
>
>
> The *compilation* buffer's mode-line expresses such things.

Actually, by "I" above I meant the special compilation function I'm
planning to write.  Something like:

(defun my-compile ()
  (interactive)
  (compile (format "gcc %s" (file-name-nondirectory (buffer-file-name))))
  (when-compilation-is-complete
   (lambda ()
     (when (not (there-were-errors))
       (kill-buffer "*term*")
       (term "./a.out")))))

What I'm not quite clear on at the moment is how to write the
when-compilation-is-complete and there-were-errors functions.

Actually, for there-were-errors I could obviously parse the content of
the *compilation* buffer, but I was hoping the same information might
be available more directly.

Re: Very simple IDE for programming newbie

[despen]

Sean McAfee <mcafee@sean-mcafees-macbook-pro.local> writes:

> Peter Dyballa <Peter_Dyballa@Web.DE> writes:
>
>> Am 03.01.2010 um 17:10 schrieb Sean McAfee:
>>> I know; my question was how to a) know when the asynchronous
>>> compilation process has finished, and b) tell whether there were any
>>> errors, so that if there were none, I can immediately launch the
>>> newly-compiled program in a terminal emulator.
>>
>>
>> The *compilation* buffer's mode-line expresses such things.
>
> Actually, by "I" above I meant the special compilation function I'm
> planning to write.  Something like:
>
> (defun my-compile ()
>   (interactive)
>   (compile (format "gcc %s" (file-name-nondirectory (buffer-file-name))))
>   (when-compilation-is-complete
>    (lambda ()
>      (when (not (there-were-errors))
>        (kill-buffer "*term*")
>        (term "./a.out")))))
>
> What I'm not quite clear on at the moment is how to write the
> when-compilation-is-complete and there-were-errors functions.
>
> Actually, for there-were-errors I could obviously parse the content of
> the *compilation* buffer, but I was hoping the same information might
> be available more directly.

You know a compilation is good by it's return code.
If you set compilation command to "make", this would check the
return code and run the test:

make && ./myprog

But smarter is to create a Makefile and make running of the test
dependent on the compile.

You don't need to parse for errors, all that's already built in.