unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Tim McNamara <timmcn@bitstream.net>
Subject: Re: Emacs from CVS question
Date: Sun, 30 Nov 2003 19:21:18 -0600	[thread overview]
Message-ID: <m2d6b91gfl.fsf@bitstream.net> (raw)
In-Reply-To: rquyb.373925$Fm2.375032@attbi_s04

Hugh Wolf <hwolf@deutsches.lieder.de> writes:

> On 2003-11-30, Tim McNamara <timmcn@bitstream.net> wrote:
>
>> Not mixing fink-built and non-fink-built dependencies makes sense.
>> Thus far 21.3 doesn't seem to be available via fink
>
> Time to make your own .info file :) It's very easy in this case,
> since you can copy one that's there already and modify it as needed.
> Put it in the local tree, so fink knows it's not part of its
> distribution.
>
>> (and in any event the Carbon build would not be available via fink
>
> Right, but this is completely standalone, it doesn't depend on
> anything at all other than what comes with the osx developer tools
> -- not on fink and not on anything else you might happen to have in
> /usr/local.

OK, that was over my head.  ;-)

>>> I haven't used XDarwin.app in a long time now, but this sounds
>>> like an .Xmodmap thing.  With X11.app my ~/.Xmodmap looks like
>>> this:
>>
>> Huh.  I don't have an ~/.Xmodmap file... 
>
> If you want option to be meta, you need one.  The standard osx X11
> key mapping makes command/apple act as meta and option/alt act as
> alt.

Even if my .emacs contains (setq mac-command-key-is-meta nil)?  Now,
in Terminal Option = Meta as there's a check box in Preferences for
this, but it doesn't carry over to X11 obviously.  And in the Carbon
version Option = Meta, so for the sake of consistency it'd be nice to
have the same functionality in the X11 version.  I'll look into using
an .Xmodmap file to set this.

>>> Mine is 15.6MB for emacs itself -- less than half the size of the
>>> X11 build (36.7MB).  Where are you seeing 95MB?
>>
>> Get Info on Emacs.app = 96.6 MB. 
>
> Right, ok, but that's with all the lisp and info files etc.  You'll
> see exactly the same thing with the X11 build, except those parts
> will be under /usr/local.
>
>> Oddly enough, neither the Carbon version nor the X11 version I
>> compiled can find the info files
>
> This works ok for me.

Which is what makes me wonder if I miscued the build process in some
way, missed a library that I'm supposed to have, etc..  I haven't
heard anything about this being a problem for other people building
from the CVS snapshot.

>> which are at the place that "make install" put them
>
> If you leave them wherever the install step puts them, it should
> work.  With the carbon emacs you should also be able to copy them
> into the application bundle (as you've apparently done).  I don't do
> this myself, but I did try it once, some time ago, and it seemed to
> work fine.

I didn't do anything with where anything was installed.  My
interaction with the compiling process amounted to:

(Using Andrew Choi's script for obtaining Emacs from CVS at Savannah;
then gunzipping/untar'ing the file, then cd'ing to the emacs source
directory where I invoked:)

./configure --with-carbon --without-x
make bootstrap
sudo make install

I invoked 'make distclean' after getting a working version for Carbon,
and then I decided to build a copy for X11 use:

./configure --with-x --without-carbon
make bootstrap
make install

> What symptom are you seeing -- 'meta-x info' shows nothing?

'M-x info' produces the Gnus info tree as the top level, but no other
info.  Using the menu bar Help item produces either nothing (e.g.,
selecting "About Emacs" with the mouse results in "menu-bar help-menu
about" in the minibuffer but no help screen; selecting "Read the Emacs
manual" results in "info file emacs does not exist" in the minibuffer
and a blank buffer frame named "info."

It's kind of interesting to me that *both* builds have the same
behavior in this regard.  Is there some way to check where Emacs
*thinks* the info files are?  Is it looking somewhere other than
/usr/local/info?

  reply	other threads:[~2003-12-01  1:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-29 15:56 Emacs from CVS question Tim McNamara
2003-11-30  6:20 ` Eli Zaretskii
     [not found] ` <mailman.805.1070176829.399.help-gnu-emacs@gnu.org>
2003-11-30  6:54   ` Tim McNamara
2003-11-30  7:12     ` Eli Zaretskii
2003-11-30 12:43 ` Glenn Morris
2003-11-30 19:30   ` Tim McNamara
2003-11-30 13:20 ` Piet van Oostrum
2003-11-30 19:32   ` Tim McNamara
2003-11-30 14:54 ` Martin Stemplinger
2003-11-30 19:36   ` Tim McNamara
2003-11-30 20:30 ` Hugh Wolf
2003-11-30 22:03   ` Tim McNamara
2003-11-30 22:45     ` Hugh Wolf
2003-12-01  1:21       ` Tim McNamara [this message]
2003-12-02  0:08         ` Hugh Wolf
2003-12-02  0:39           ` Tim McNamara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2d6b91gfl.fsf@bitstream.net \
    --to=timmcn@bitstream.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).