Suggestion: split grep functionality out of compile.el

I have been looking at the grep functionality and it is natural for it
to utilize the compile.el functionality, but I don't see why it has to
be so closely nit into the compilation facility that it shares the
same file and customization group `compilation'.

I would suggest splitting out the grep functionality into a new file
grep.el, and make a new customization group for it `grep'.

Does anyone object to me doing this?

--

-- 
Kim F. Storm <storm <at> cua.dk> http://www.cua.dk

Mac OS X make-package extra root stuff patch

This patch takes files from a directory "mac/image-root-extras" and puts 
them into the disk image (in the root directory) as it builds it. Perhaps 
COPYING and the other Emacs Readme's should be put in there by default...

-David

Index: make-package
===================================================================
RCS file: /cvsroot/emacs/emacs/mac/make-package,v
retrieving revision 1.7
diff -u -r1.7 make-package
--- make-package	30 Nov 2002 22:06:23 -0000	1.7
+++ make-package	30 Nov 2002 23:58:53 -0000
 <at>  <at>  -362,6 +386,12  <at>  <at> 
 fi

 cp -R Emacs.pkg /Volumes/Emacs
+
+# Copy in extra stuff into the root of the disk image if the
+# image-root-extras directory exists and has stuff in it.
+if [ -d image-root-extras -a "`ls -1 image-root-extras/ | wc -l | sed -e 's/ //g'`" != 0 ]; then
+	cp -R image-root-extras/* /Volumes/Emacs
+fi

 ## Converting Disk Image to read-only
 echo 'Converting Disc Image to read-only'

Re: Mac OS X make-package extra root stuff patch

On 11/30/02 4:10 PM -0800 David Caldwell wrote:

> This patch takes files from a directory "mac/image-root-extras" and puts
> them into the disk image (in the root directory) as it builds it. Perhaps
> COPYING and the other Emacs Readme's should be put in there by default...
>
> -David

Oops. My dumb email client destoyed the patch. Get it from here:

<http://death.porkrind.org/make-package.extra-root-stuff.patch>

-David

Mac OS X make-package shell-wrapper patch

This patch makes bin/emacs be a small shell script that launches emacs from 
within its app wrapper (which is stored in libexec).

<http://death.porkrind.org/make-package.shell-wrapper.patch>

This references emacs.sh which is available here:
(renamed .txt because my apache is misconfigured :-/).
<http://death.porkrind.org/emacs.txt>

-David

Re: Mac OS X GNU Emacs Installer (make-package)

>> This is the solution that Andrew proposes.  /usr/local/bin/emacs 
>> would be
>> a shell script that calls /usr/local/bin/emacs-21.3.50 -nw $*.  I 
>> don't
>> like that solution very much.  This is a patch I placed on the list
>> earlier; it causes the executable to determine if it is inside an
>> application bundle.  If it is not, it will cause it to
>> inhibit_windowing_system.  I placed the call to this right after the 
>> call
>> to init_mac_osx_environment inside emacs.c:main
> [..]
>
> That was my initial idea. But in the end I like the way the shell 
> script works better. Typing plain "emacs" gives you a new window, 
> while "emacs -nw" gives you the console. It works just like under X 
> Windows. Otherwise there is no way to get a nice window from the 
> command line, except by writing your own shell wrapper. To me that is 
> the only reason to choose the shell script road over the patch you 
> propose (Although I think patch should be there as well, since emacs 
> should never segfault).

Yeah, I think you are right.  The one concern that I had was what would 
happen if the location of the Emacs.app was moved.  Your solution fixes 
that by creating a "shadow" application.  Why not make the whole 
Emacs.app directory be a link to the lib-exec one?  That way you 
wouldn't have the problem of dealing with two sets of files depending 
on whether you did it from the command line or from the finder.  The 
downside is that the icon in the Applications menu would be a little 
screwed up.

Re: Mac OS X GNU Emacs Installer (make-package)

On Sat, Nov 30, 2002 at 05:53:05PM -0800, Steven Tamm wrote:
> As another aside, I think the make-package script should eventually be 
> rewritten in perl because of the guarantee that it exists on Mac OS X.  
> Any objections.

You mean script that currently uses /bin/sh?

I really don't think /bin/sh is going to go away...

-Miles
--

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Mac OS X GNU Emacs Installer (make-package)

>
>> As another aside, I think the make-package script should eventually be
>> rewritten in perl because of the guarantee that it exists on Mac OS X.
>> Any objections.
>
> You mean script that currently uses /bin/sh?
>
> I really don't think /bin/sh is going to go away...

Oh that's not what I meant at all, but it is what I wrote.

I think the script would be easier to maintain in perl than in /bin/sh. 
  This is only interesting because Perl is guaranteed to be on the 
system (unlike most *nix flavours).

-Steven 

Re: Mac OS X GNU Emacs Installer (make-package)

On 11/30/02 5:53 PM -0800 Steven Tamm wrote:

> Yeah, I think you are right.  The one concern that I had was what would
> happen if the location of the Emacs.app was moved.  Your solution fixes
> that by creating a "shadow" application.  Why not make the whole
> Emacs.app directory be a link to the lib-exec one?  That way you wouldn't
> have the problem of dealing with two sets of files depending on whether
> you did it from the command line or from the finder.  The downside is
> that the icon in the Applications menu would be a little screwed up.

I really wanted to do cp -lr but OS X cp doesn't support -l. In the end I 
did this:

[david <at> Bluey ~/src/emacs-dev/emacs-cvs/mac]$ find /Applications/Emacs.app 
-type f | xargs du -s
8       /Applications/Emacs.app/Contents/.cvsignore
8       /Applications/Emacs.app/Contents/Info.plist
14168   /Applications/Emacs.app/Contents/MacOS/Emacs
8       /Applications/Emacs.app/Contents/PkgInfo
104     /Applications/Emacs.app/Contents/Resources/Emacs.icns
16      /Applications/Emacs.app/Contents/Resources/Emacs.rsrc
8 
/Applications/Emacs.app/Contents/Resources/English.lproj/InfoPlist.strings

And decided that it was negligible to have a complete copy in libexec (as 
long as Contents/MacOS/Emacs was a link...).

> As another aside, I think the make-package script should eventually be
> rewritten in perl because of the guarantee that it exists on Mac OS X.
> Any objections.

[PATCH] Better test than #ifdef BSD_SYSTEM in three places

I noticed the getwd usage warning from gcc today and saw that
emacsclient.c is mistakenly using getwd on BSD systems.
configure looks for getcwd already, so i just changed it to test
HAVE_GETCWD.  I did a quick check over the rest of the tree and
corrected two other abuses of BSD_SYSTEM (fcntl.h in fileio.c and
sysdep.c).  Undoubtedly there are others, but these are the only
ones i'm sure of.

Index: lib-src/emacsclient.c
===================================================================
RCS file: /cvsroot/emacs/emacs/lib-src/emacsclient.c,v
retrieving revision 1.54
diff -a -u -r1.54 emacsclient.c
--- lib-src/emacsclient.c	1 Oct 2002 00:45:30 -0000	1.54
+++ lib-src/emacsclient.c	1 Dec 2002 03:28:19 -0000
 <at>  <at>  -418,19 +418,19  <at>  <at> 
       fail (argc, argv);
     }

-#ifdef BSD_SYSTEM
-  cwd = getwd (string);
-#else
+#ifdef HAVE_GETCWD
   cwd = getcwd (string, sizeof string);
+#else
+  cwd = getwd (string);
 #endif
   if (cwd == 0)
     {
       /* getwd puts message in STRING if it fails.  */

Re: TODO additions

    >     For 21.3, you might want other changes for gnu-linux mipsle, hp and
    >     s390 targets, but they're inconsistent with the treatment in the
    >     current head sources.  (I just made a trivial change which should get
    >     mipsle OK.)
    > 
    > Could you say more concretely which part of the code we're talking
    > about?

    Just the {m,s}/*.h files, and trivial changes to configure.in.

What is "inconsistent" about this?