Re: installing emacs and X11 on OS X

[tfb@mudslide.OCF.Berkeley.EDU (Thomas F. Burdick)]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On 27 Oct 2002, Thomas F. Burdick wrote:
> 
> > This doesn't let me differentiate between Carbon-Emacs on OS X, and
> > X11-Emacs on the same OS.  system-type is darwin on both, and
> > display-graphic-p is t on both.  However, it makes a lot of sense (to
> > me) that someone might want to make the Carbon one behave more like a
> > Carbon application, and the X11 one behave like an X11 application.
> 
> If there's a difference between these two configurations, there should be 
> a way to distinguish between them.  Doesn't system-configuration fit the 
> bill? or maybe system-configuration-options?

No, because the determination really needs to be made at runtime.

> > Out of curiosity, why is it depricated?  Because people abuse it where
> > specific feature tests would be better?
> 
> Yes.  And that makes application code, including users' .emacs, bitrot 
> alot when functionality of some window-system changes due to 
> development.  I already mentioned the problem with .emacs files that 
> assumed window-system being nil means no colors.

Well, the conjunction doesn't belong there -- abusing it this way
certainly will introduce bit-rot.

> > If so, that seems like a bad
> > reason ... people can abuse anything
> 
> People will abuse less if they have less opportunities for abuse.

I guess so long as a new facility for determining what environment
you're working in, is introduced, this is a fine decision.  I imagine,
though, that any time you give people the ability to ask what
look-and-feel environment they're operating in, they'll abuse it to
test for display features.

> > but AFAIK, window-system is the
> > only way to determine what window system you're on.
> 
> A small study into the uses of window-system in Emacs's own code that we 
> did shows that it is used to test for a small number of features, but those 
> features are implicit: they are neither stated clearly in the code nor 
> even clearly understood in some cases.  So it seems like window-system is 
> a powerful tool for obfuscating Lisp code.
> 
> By contrast, the explicit predicates such as display-multi-font-p 
> actually say exactly what is the feature that's being tested.  And the 
> maintenance effort needed to keep a small number of predicates in sync 
> with Emacs development is much less than what would be needed to go 
> through all the *.el files and modify them whenever some window-system 
> gets an extra feature it didn't have before.  As an example, consider a 
> future development of drop-down menus on a character terminal.

Oh, I'm not questioning the wisdom of using the display-*-p functions.

> > Or is there a
> > plan to replace this with a more competant introspection api?
> 
> Such a plan is already in place: those are the display-*-p predicates 
> advertized by NEWS in the same item which says window-system should not 
> be used.

What's there is good, but more is needed.  I guess that possiblity is
part of why window-system was depricated, instead of removed, huh?

> > [ It would be cool to be able to have something like a window-system-p
> >   function, so I could ask (window-system-p 'carbon) or
> >   (window-system-p 'x11) or (window-system-p 'gtk).
> 
> I think system-configuration and/or system-configuration-options should 
> allow you to do this.

I think what's needed is the ability to ask run-time questions like
the above.  So either a look-and-feel-p predicate, or a series of
display-look&feel-*-p predicates, so I could write code like this:

  (when (display-look&feel-carbon-p)
    (setup-carbon-look&feel))

  (when (display-look&feel-x11-p)
    ;; Things like mouse-2 for paste
    (setup-x11-look&feel))

  (when (display-look&feel-mswin-p)
    ;; No mouse-2 for pasting, use cua-mode instead
    (setup-mswin-look&feel))

  (when (display-look&feel-gtk-p)
    ;; Whatever is needed for GTK integration
    (setup-gtk-look&feel))

That way, I could write setup-*-look&feel functions that do only what
that feature requires, so for example mouse-2-as-paste wouldn't be a
part of the GTK l&f function, it would go with X11.  That way if there
was an Emacs someday that ran under GTK/MSWin, it wouldn't have weird
pasting behavior.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'