help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: font handling broken in cvs emacs --with-ns (MacOS X)


From: B Smith-Mannschott
Subject: Re: font handling broken in cvs emacs --with-ns (MacOS X)
Date: Mon, 5 Jan 2009 12:31:38 +0100

On Mon, Jan 5, 2009 at 12:28 AM, Peter Dyballa <Peter_Dyballa@web.de> wrote:

> Am 04.01.2009 um 23:22 schrieb B Smith-Mannschott:
>
>>> Documentation clearly states that after an update you need to do a 'make
>>> bootstrap' unless you wish to have a GNU mess.
>>>
>>>>   make install
>>
>> I do it this way because it works.
>
> If your way would work, then you would not need to consider writing a bug
> report ...

Noted, see end of message

>> And I don't need the build to be fast.
>
> A bootstrap built build is not faster – it just has up-to-date ELC files.

Noted, see end of message

>> It would be different if I were hacking on emacs myself because
>> the long edit-compile-run cycle would be terrible.
>
> There are experienced GNU Emacs developers who take that burden from you!
> And this makes the difference: you're not using the stable GNU Emacs 22.3
> (also in Carbon available) but the not yet released GNU Emacs 23.0.60 *from
> CVS*. And therefore building it needs 'make bootstrap.'

Yes, I'm aware that I'm using the bleeding edge version. I'm also
aware that it will contain bugs, though on the whole it's been very
stable.

>> I found the reference to make bootstrap in INSTALL.CVS (thanks grep).
>> I had been reading INSTALL, which doesn't breathe a word of it.
>> Scrubbing the source directory seems to force a make bootstrap, which
>> is good. If I find I need emacs to build faster, then I'll look into
>> INSTALL.CVS more carefully.
>
> You're mixing up a few things! In a regular and stable GNU Emacs release you
> won't see the INSTALL.CVS file. Does this help?

Not really. I'm building form CVS. By force of habit the first thing I
look for when building unix software from source is INSTALL (or
failing that README).  If I find said document and it seems to
describe how to build the software, I generally stop looking and just
do what it says.

>>> You don't need that Carbon stuff! Just choose from the Options menu "Set
>>> Default Font…"! Isn't it clearly documented?
>>
>> I may have missed it among emacs' *1.9 million words* of documentation.
>> ;-)
>
> Well, maybe you came too late to Emacs.app, because some weeks ago it has
> lost from the Help menu an entry to read the part on Emacs.app. Right now
> you can easily find in the Emacs node one on
>
>        * Mac OS / GNUstep::    Using Emacs under Mac OS and GNUstep.

Thanks for the pointer. I remember skimming the info file for this (in
source), but obviously didn't remember everything I'd read.  I'll read
it again.

>> Is all that gets written. still, it's obviously storing the setting
>> somewhere, because the change I made is maintained across restarts of
>> emacs...
>>
>> ~/Library/Preferences/org.gnu.Emacs.plist
>>
>> Fascinating. I see a lot of other stuff here too. settings for
>> org-mode, for example. Does Emacs.app write all customizations here
>> instead of custom.el?
>
> I don't think so. Only its "options" are saved in this XML file. (The
> defaults command or Property List Editor also work on this file.)

The presence of org-mode entries seems to contradict this. (But either
way, this isn't causing problems for me.)

>> How will that jive with my attempts to keep a
>> single emacs configuration (in version control) across my Mac and
>> Linux machines?
>
>
> Well, I make most of my changes into a *system* of init files. From ~/.emacs
> particular init and customisation files are read, mostly depending on
> emacs-major-number and window-system.

I did something like that for a while, until it started to drive me
crazy because I was making the same config changes multiple times
(once for each window system, in my case). I switched to keeping most
customizations in my ~/.emacs.d/init.el and just using conditionals
there to, e.g. select the correct font depending on windowing
system. This limits the usefulness of customize and on balance I find
this only marginally better than what I was doing previously. live and
learn.


In summary, you seem to be making two assertions:

(1) running ( ./configure --with-ns ; make ; make install ) is not the
    same as running ( ./configure --with-ns ; make bootstrap ; make ;
    make install )

(2) This difference results in the misbehavior I am seeing. ("If your
    way would work, then you would not need to consider writing a bug
    report ...")

I've decided to take a more careful look at both of these points:

(1) The build logs with and without make bootstrap do differ. (see
    build-u.diff.)

- A large chunk of the difference is removing files which are not
  there. (Remember I'm starting from a clean checkout with no build
  products.)
- The next difference is the regeneration of the Makefiles, which is
  only necessary because the previous difference blew them away.
- The makeinfo runs for all the texi files occur earlier in the
  "bootstrap" build.
- There are two minor differences in the "List of all Regions"
  produced by temacs --batch --load loadup bootstrap. I don't know the
  significance of these.
- There is a sequence of "make all" calls in lib-src, src, lisp, leim
  which don't appear to actually do anything in my particular case.

The resulting build products do differ.

When I inspected a random sampling of the *.o and *.elc files that
differed, I found only differences in the compilation time stamp
(*.elc) and source directory path (*.o).

Given that the differences appear so minor, I would expect no
significant difference in the behavior of the two resulting builds of
Emacs.app.

(2) The behavior of Emacs.app wrt font handling issues under
    discussion does not differ.

Using the Emacs.app resulting from the build that *did* use "make
bootstrap":

(2.1) Emacs >> Preferences >> Default Font
      Does not set the default font.

This does not appear to be a bug; it's a documented misfeature:

    Note that if you use the 'Default Font' button on the Preferences
    panel, you must click on a frame before selecting a font,
    otherwise nothing will happen.                    (ns-emacs.info)

Normally (on a Mac), one would expect the default font set through the
*Application-Wide* Preferences window to be, well, an application-wide
default and not per-frame setting.  So really, this button in "Emacs
Preferences" is just a really clumbsy way of executing "Options >> Set
Default Font...". Is that sensible?

(2.2) set-default-font
      Offers no completions for setting the default font.

C-h f, however reveals that: This function is obsolete since 23.1; use
set-frame-font instead. I had not previously noticed this. My bad.

set-frame-font: Offers no completions. Is the user meant to guess?

(2.3) M-x set-face-font
      Offers only three possible completions, just as described in the
      initial posting on this thread.

   -*-*-*-*-*-*-*-*-*-*-*-*-fontset-default
   -apple-Monaco-medium-normal-normal-Regular-*-*-*-*-*-*-fontset-startup
   -ns-*-*-*-*-*-10-*-*-*-*-*-fontset-standard

(2.4) Context menu (S-mouse-1)
      Menu still missing. This has already been identified as a bug.

Conclusion:

I've learned something about make bootstrap and INSTALL.CVS [1], which is
always nice.  Having known this earlier, however, would not have
prevented the issues I am describing here.

"make bootstrap" does not make the font-related misbehavior go away.

[1] Indeed, I remember "make bootstrap" dimly from the last time I
    regularly built emacs from sources which was probably five years
    ago. When I began building from source again a few months ago and
    didn't find it mentioned in INSTALL, I assumed (silly me) that
    "make bootstrap" kicking around in my head must have been
    obsoleted in the interim.

-- 
// Ben Smith-Mannschott

Attachment: build-u.diff
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]