[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: installing emacs and X11 on OS X
From: |
Thomas F. Burdick |
Subject: |
Re: installing emacs and X11 on OS X |
Date: |
28 Oct 2002 13:25:27 -0800 |
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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Re: installing emacs and X11 on OS X, Hugo Wolf, 2002/10/23
Re: installing emacs and X11 on OS X, John Paul Wallington, 2002/10/24
Re: installing emacs and X11 on OS X, Hugo Wolf, 2002/10/28
Re: installing emacs and X11 on OS X,
Thomas F. Burdick <=
Re: installing emacs and X11 on OS X, Hugo Wolf, 2002/10/29
Re: installing emacs and X11 on OS X, Stefan Monnier <address@hidden>, 2002/10/29