Re: M-x compile for different file extensions

Re: M-x compile for different file extensions

[Richard Stallman]

    I have enhanced the Emacs `compile' package with some commands.

    1. Automatic selection of compile commands according to the file
       extension and DEBUG state. (defuns: `compile-main', `compile-sub',
       `compile-debug-toggle')

The debugging feature could make sense, but why isn't `make -k' a good
default regardless of the kind of file?  In other words, why isn't
"You should write a proper makefile" a good solution for this?

    4. An easy way to interact (send input to) with the compilation process
       (`compile-send-to-process').

This indeed is something important.

It is sort of unfortunate that we have the conflict between two
meanings we would like RET to have in the compilation buffer: "visit
the source code for a particular error message", and "send a line of
input".  We have used it for the former ever since that convention
existed in Emacs (several years ago), but would it be better to use
it for the latter instead?

Sometimes I think that compile.el should use comint and you should
be able to send input to the compiler just by typing a line ending
in RET.

    5. Run some commands with interactive input to them (when needed) in a
       compilation window, with an option to kill the compilation buffer.
       (`compile-commands', read the help carefully).

Why is this better than using a single shell command string, with `;'
and `sleep N' used as needed between the individual shell commands?

Re: M-x compile for different file extensions

[Ehud Karni]

On Sun, 20 Oct 2002 12:59:39 -0400, Richard Stallman <rms@gnu.org> wrote:
> 
> The debugging feature could make sense, but why isn't `make -k' a good
> default regardless of the kind of file?  In other words, why isn't
> "You should write a proper makefile" a good solution for this?

1. There are many independent (small) programs which are
   not part of a big project and so there is no need for make file.
2. We use the compile command on many type of files which are not
   real "programs" - shell scripts (run with arguments), sql queries,
   reports (printed by the `compile') and many, many others.
3. This makes it more easy to have a standard policy regarding saving
   places for "compilation" output. For example we have some local
   tool that work on *.pns files, our tool convert it to <name>.pnl
   our defined 


>     5. Run some commands with interactive input to them (when needed) in a
>        compilation window, with an option to kill the compilation buffer.
>        (`compile-commands', read the help carefully).
> 
> Why is this better than using a single shell command string, with `;'
> and `sleep N' used as needed between the individual shell commands?

This is really used for programs that use /dev/tty (and not standard
input), for security (programs that need pass words) or dynamic
answers. It also has the added advantage of running multiple processes,
each with its own buffer and different name automatically. 

Ehud.


-- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry

Re: M-x compile for different file extensions

[Stefan Monnier]

> On Sun, 20 Oct 2002 12:59:39 -0400, Richard Stallman <rms@gnu.org> wrote:
> > 
> > The debugging feature could make sense, but why isn't `make -k' a good
> > default regardless of the kind of file?  In other words, why isn't
> > "You should write a proper makefile" a good solution for this?
> 
> 1. There are many independent (small) programs which are
>    not part of a big project and so there is no need for make file.
> 2. We use the compile command on many type of files which are not
>    real "programs" - shell scripts (run with arguments), sql queries,
>    reports (printed by the `compile') and many, many others.
> 3. This makes it more easy to have a standard policy regarding saving
>    places for "compilation" output. For example we have some local
>    tool that work on *.pns files, our tool convert it to <name>.pnl
>    our defined 

Note that compile-command can hold an expression rather than a string,
so I think the best way to take care of some of those cases is with
something like

	(add-hook 'pns-mode-hook
	          (lambda ()
	            (set (make-local-variable 'compile-command)
	                 '(format "pnsrun %s" buffer-file-name))))


-- Stefan

Re: M-x compile for different file extensions

[Richard Stallman]

    1. There are many independent (small) programs which are
       not part of a big project and so there is no need for make file.

Isn't a makefile as good a way as any to specify the right commands
to use to compile them?

    2. We use the compile command on many type of files which are not
       real "programs" - shell scripts (run with arguments), sql queries,
       reports (printed by the `compile') and many, many others.

Ok, but if you do that, is it really the case that the command you want
to run follows from the current visited file?

    3. This makes it more easy to have a standard policy regarding saving
       places for "compilation" output. For example we have some local
       tool that work on *.pns files, our tool convert it to <name>.pnl
       our defined 

I don't quite understand this and how it relates to the issue.
Could you explain that?

    >     5. Run some commands with interactive input to them (when needed) in a
    >        compilation window, with an option to kill the compilation buffer.
    >        (`compile-commands', read the help carefully).
    > 
    > Why is this better than using a single shell command string, with `;'
    > and `sleep N' used as needed between the individual shell commands?

    This is really used for programs that use /dev/tty (and not standard
    input), for security (programs that need pass words) or dynamic
    answers. It also has the added advantage of running multiple processes,
    each with its own buffer and different name automatically. 

I don't see the connection--would you please explain?
These programs would relate to the other feature, having a way to send
input to the compilation process, but I don't see how they relate
to this feature.

Re: M-x compile for different file extensions

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     1. There are many independent (small) programs which are
>        not part of a big project and so there is no need for make file.
>
> Isn't a makefile as good a way as any to specify the right commands
> to use to compile them?

I think that people have an irrational fear of Makefiles.  For
example, colleagues were asking me about how to compile C++ programs
from within Emacs for a beginners' course on C++ "without using
makefiles because these are just beginners and not even CS students
and makefiles are so difficult".

Then I explained to them that the empty (or non-existing) makefile is
good enough (if they use GNU make at least, and call their programs
foo.cc).  They were really surprised and the last I heard from them
was "wow, that's simple".

But something that might be useful would be to auto-select a make
target, so that editing foo.cc means that the default command is
"make foo" (or "make -k foo", if you must) and not "make -k".  I
don't know if this is practical.

How about adding some more advertisement for make to the Emacs
documentation somewhere?  Strictly speaking, the Emacs manual is the
wrong spot for this, but maybe it would help a number of users.

[time passes, which is its job]

There is one argument in favor of automatically selecting the right
compile command.  Suppose a user has a lot of *.giggle files and they
want to run "mumblefrotz" on them to produce *.stiffle files.
Suppose that the *.giggle files are all over the place, not just in
one directory.  Then it might be convenient for these users to select
the compile-command based on the major mode of the buffer, instead of
writing makefiles everywhere with basically the same contents.  (The
user might not have the right to edit the global make.rules file.)

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: M-x compile for different file extensions

[Kevin Rodgers]

Kai Großjohann wrote:

> There is one argument in favor of automatically selecting the right
> compile command.  Suppose a user has a lot of *.giggle files and they
> want to run "mumblefrotz" on them to produce *.stiffle files.
> Suppose that the *.giggle files are all over the place, not just in
> one directory.  Then it might be convenient for these users to select
> the compile-command based on the major mode of the buffer, instead of
> writing makefiles everywhere with basically the same contents.  (The
> user might not have the right to edit the global make.rules file.)


Yes, and the doc string for compile-command and the Compilation node of
the manual both point the user in toward using a buffer local value for
the variable.  Perhaps the documentation just needs to be a little more
explicit for novice users, but I had no trouble figuring out:

(add-hook 'giggle-mode-hook
	  (lambda ()
	    (let ((giggle-file (file-name-nondirectory buffer-file-name)))
	      (set (make-local-variable 'compile-command)
		   (format "mumblefrotz -o %s.stiggle %s"
			   (file-name-sans-extension giggle-file)
			   giggle-file)))))

But it might be nice if the user could just do something like

(add-to-list 'auto-compile-command-alist
	     '("\\.giggle\\'" . "mumblefrotz -o %s.stiggle %s.giggle"))

-- 
Kevin

Re: M-x compile for different file extensions

[Ehud Karni]

On Tue, 22 Oct 2002 11:17:21 -0600, Kevin Rodgers <kevinr@ihs.com> wrote:
> 
> > There is one argument in favor of automatically selecting the right
> > compile command.  Suppose a user has a lot of *.giggle files and they
> > want to run "mumblefrotz" on them to produce *.stiffle files.
> > Suppose that the *.giggle files are all over the place, not just in
> > one directory.  Then it might be convenient for these users to select
> > the compile-command based on the major mode of the buffer, instead of
> > writing makefiles everywhere with basically the same contents.  (The
> > user might not have the right to edit the global make.rules file.)
> 
> 
> Yes, and the doc string for compile-command and the Compilation node of
> the manual both point the user in toward using a buffer local value for
> the variable.  Perhaps the documentation just needs to be a little more
> explicit for novice users, but I had no trouble figuring out:
> 
> (add-hook 'giggle-mode-hook
> 	  (lambda ()
> 	    (let ((giggle-file (file-name-nondirectory buffer-file-name)))
> 	      (set (make-local-variable 'compile-command)
> 		   (format "mumblefrotz -o %s.stiggle %s"
> 			   (file-name-sans-extension giggle-file)
> 			   giggle-file)))))
> 
> But it might be nice if the user could just do something like
> 
> (add-to-list 'auto-compile-command-alist
> 	     '("\\.giggle\\'" . "mumblefrotz -o %s.stiggle %s.giggle"))

This needs a fair knowledge of emacs lisp (It requires to define major
mode). It should be customizable to let lay people use it for their own
extensions. The ekcompl.el let the lay user do it interactively (by the
`compile-ext-edit' command).

Ehud.


-- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry

Re: M-x compile for different file extensions

[Richard Stallman]

    How about adding some more advertisement for make to the Emacs
    documentation somewhere?  Strictly speaking, the Emacs manual is the
    wrong spot for this, but maybe it would help a number of users.

I will add a cross reference to it in a useful place.  Thanks.

Re: M-x compile for different file extensions

[Ehud Karni]

On Mon, 21 Oct 2002 23:12:29 -0400, Richard Stallman <rms@gnu.org> wrote:
> 
>     2. We use the compile command on many type of files which are not
>        real "programs" - shell scripts (run with arguments), sql queries,
>        reports (printed by the `compile') and many, many others.
> 
> Ok, but if you do that, is it really the case that the command you want
> to run follows from the current visited file?

Yes, because we have our "standard" extensions for this kind of files.

>     >     5. Run some commands with interactive input to them (when needed) in a
>     >        compilation window, with an option to kill the compilation buffer.
>     >        (`compile-commands', read the help carefully).
>     > 
>     > Why is this better than using a single shell command string, with `;'
>     > and `sleep N' used as needed between the individual shell commands?
> 
>     This is really used for programs that use /dev/tty (and not standard
>     input), for security (programs that need pass words) or dynamic
>     answers. It also has the added advantage of running multiple processes,
>     each with its own buffer and different name automatically. 
> 
> I don't see the connection--would you please explain?
> These programs would relate to the other feature, having a way to send
> input to the compilation process, but I don't see how they relate
> to this feature.

An example may clarify it:
 (compile-commands '(("cd\n" 0)       ;; work in home dir
                     (". Xoper\n" 3)  ;; run this script (wait 3 seconds)
                     ("oper-pw\n" 3)) ;; send oper password (must read from /dev/tty)
       "Oper Xterm" 1))               ;; name of compilation buffer,
                                      ;; kill the compilation buffer after the process ends

The sending of the pass word uses the fact that the compilation buffer
make a pseudo terminal that connects with the sub shell.

Ehud.


-- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry

Re: M-x compile for different file extensions

[Richard Stallman]

    >     2. We use the compile command on many type of files which are not
    >        real "programs" - shell scripts (run with arguments), sql queries,
    >        reports (printed by the `compile') and many, many others.
    > 
    > Ok, but if you do that, is it really the case that the command you want
    > to run follows from the current visited file?

    Yes, because we have our "standard" extensions for this kind of files.

A number of people have asked for this, over the years, so I think
we may as well add the feature.

Using compilation commands that read passwords seems like a very
obscure thing to do.  I would rather not install added complexity in
compile.el for that.

Re: M-x compile for different file extensions

[Stefan Monnier]

>     I have enhanced the Emacs `compile' package with some commands.
> 
>     1. Automatic selection of compile commands according to the file
>        extension and DEBUG state. (defuns: `compile-main', `compile-sub',
>        `compile-debug-toggle')
> 
> The debugging feature could make sense, but why isn't `make -k' a good
> default regardless of the kind of file?  In other words, why isn't
> "You should write a proper makefile" a good solution for this?

I have missed the orinal post, where was it ?
[ was it in gnu.emacs.bug ?  My gnu.emacs.bug newsgroup has been empty
  for a while now. ]

>     4. An easy way to interact (send input to) with the compilation process
>        (`compile-send-to-process').
> 
> This indeed is something important.
> 
> It is sort of unfortunate that we have the conflict between two
> meanings we would like RET to have in the compilation buffer: "visit
> the source code for a particular error message", and "send a line of
> input".  We have used it for the former ever since that convention
> existed in Emacs (several years ago), but would it be better to use
> it for the latter instead?

We could probably let RET do something like
(if (eobp) (send-to-process) (goto-error))


	Stefan

Re: M-x compile for different file extensions

[Ehud Karni]

On Sun, 20 Oct 2002 15:52:49 -0400, Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> wrote:
> 
> >     4. An easy way to interact (send input to) with the compilation process
> >        (`compile-send-to-process').
> > 
> > This indeed is something important.
> > 
> > It is sort of unfortunate that we have the conflict between two
> > meanings we would like RET to have in the compilation buffer: "visit
> > the source code for a particular error message", and "send a line of
> > input".  We have used it for the former ever since that convention
> > existed in Emacs (several years ago), but would it be better to use
> > it for the latter instead?
> 
> We could probably let RET do something like
> (if (eobp) (send-to-process) (goto-error))

That may work, but please note that there 2 functions - 1 sends the
string with terminating new line, the other sends without the NL.

Ehud.


-- 
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 mailto:ehud@unix.mvs.co.il                  Better  Safe  Than  Sorry

Re: M-x compile for different file extensions

[Richard Stallman]

    > It is sort of unfortunate that we have the conflict between two
    > meanings we would like RET to have in the compilation buffer: "visit
    > the source code for a particular error message", and "send a line of
    > input".  We have used it for the former ever since that convention
    > existed in Emacs (several years ago), but would it be better to use
    > it for the latter instead?

    We could probably let RET do something like
    (if (eobp) (send-to-process) (goto-error))

This is a good solution if users prefer it.