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/