installing emacs and X11 on OS X

installing emacs and X11 on OS X

[Hugues Joly]

Hi,
    I'd like to know if the mac/README and mac/INSTALL instructions of
the emacs-21.2.tar.gz archive enables to install a version of emacs that
is a full blown X11 application on mac OS X?

The version already installed on my machine (OS 10.2) only works in
terminal mode.

Thanks in advance.

Re: installing emacs and X11 on OS X

[Joseph Kiniry]

They do.  Better yet, just install Fink.

A "fink install emacs" downloads and builds the full dependency set.
I set up my box by simply doing "fink install emacs sawfish
windowmaker" and it installed Emacs, X, Gnome (via the sawfish
dependency), and WindowMaker.  

The latter was necessary due to a bug in librep under Sawfish which
evidences itself in high CPU use during idle situations, slowing down
X11 tremendously.  I do not suggest using a fink built sawfish on OS X
at this time.

Best,
Joe Kiniry

Hugues Joly <joly@colba.net> writes:

> Hi,
>     I'd like to know if the mac/README and mac/INSTALL instructions of
> the emacs-21.2.tar.gz archive enables to install a version of emacs that
> is a full blown X11 application on mac OS X?
>
> The version already installed on my machine (OS 10.2) only works in
> terminal mode.
>
> Thanks in advance.

Re: installing emacs and X11 on OS X

[Michael Hudson]

Hugues Joly <joly@colba.net> writes:

> Hi,
>     I'd like to know if the mac/README and mac/INSTALL instructions of
> the emacs-21.2.tar.gz archive enables to install a version of emacs that
> is a full blown X11 application on mac OS X?
> 
> The version already installed on my machine (OS 10.2) only works in
> terminal mode.

It's not hard to build Emacs with Carbon support.

The instructions here:

    http://members.shaw.ca/akochoi-emacs/

worked fine for me (well, that's a slight lie but all the difficulties
were totally my fault).

Not quite what you asked, but maybe a better answer.

Cheers,
M.

-- 
  This is an off-the-top-of-the-head-and-not-quite-sober suggestion,
  so is probably technically laughable.  I'll see how embarassed I
  feel tomorrow morning.            -- Patrick Gosling, ucam.comp.misc

Re: installing emacs and X11 on OS X

[Piet van Oostrum]

>>>>> Hugues Joly <joly@colba.net> (HJ) writes:

HJ> Hi,
HJ>     I'd like to know if the mac/README and mac/INSTALL instructions of
HJ> the emacs-21.2.tar.gz archive enables to install a version of emacs that
HJ> is a full blown X11 application on mac OS X?

HJ> The version already installed on my machine (OS 10.2) only works in
HJ> terminal mode.

Why would you want an X11 version? There is a Carbon version which is
nicer. The tar file mentioned above should compile into the Carbon version
if you configure with --without-x. Or checkout the cvs if you want the
newest (I use this all the time).
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <mailman.1035334713.26558.help-gnu-emacs@gnu.org>, Hugues
Joly wrote: 
>     I'd like to know if the mac/README and mac/INSTALL instructions of
> the emacs-21.2.tar.gz archive enables to install a version of emacs that
> is a full blown X11 application on mac OS X?

I haven't tried it that way, but you should be able to use fink to
build an emacs x11 client in darwin/osx.  You can certainly build an
xemacs x11 client this way.  Currently xemacs is a little easier to
build as an x11 client in osx than fsf emacs is.  

You might also consider building the carbon version of emacs mentioned
earlier.  This uses the native mac window system.  Earlier
incarnations of this were flakey but if you use the current cvs
sources, the result is quite stable and generally very nice.  I'm
using it compose this article (via slrn, which I installed using
fink).  Since it's carbon, you can presumably also run it in old
macos, though I've never bothered to try.

Of course if you want to run it remotely, the carbon build won't do
you any good.  I currently have three emacs-en on my osx boxes: emacs
21.1.1 as supplied by Apple; xemacs 21.4.9, which I use when I'm
connected remotely and I want a window'd emacs; and a carbon build of
emacs 21.3.50.1, which I use for most editing when I'm at the console.

-- 
d f-d

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <wzfzuxz71g.fsf@localhost.cs.uu.nl>, Piet van Oostrum wrote:
> Why would you want an X11 version? There is a Carbon version 

Which is great at the console but no more useful than the preinstalled
one if you're connected remotely,


> which is nicer.

In some ways.

Unless you're running a pure standalone system it's a good idea to
have both.  The only tricky bit about that is conditionalizing the
startup files, in case you want the environment to be different for
the two cases.

Which leads me to a new question: is there a variable or function
which identifies the carbon build?  At the moment I'm using 

 (fboundp 'do-applescript)

which really feels like hack.  Is there a cleaner check?

-- 
d f-d

Re: installing emacs and X11 on OS X

[John Paul Wallington]

Hugo Wolf <hwolf@deutsches.lieder.net> wrote:

> Which leads me to a new question: is there a variable or function
> which identifies the carbon build?  At the moment I'm using 
>
>  (fboundp 'do-applescript)
>
> which really feels like hack.  Is there a cleaner check?

The value of the variable `window-system' is `x' under X-Windows,
`mac' under Carbon, and `tty' for a Terminal.

e.g.: (eq window-system 'mac) could replace your check.

Also, it may be better to test for specific capabilities, so that when
the Carbon build gets them your configuration will use them.  e.g.:

(if (display-images-p)
    (auto-image-file-mode t))

-- 
John Paul Wallington

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

On Wed, 23 Oct 2002, John Paul Wallington wrote:

> The value of the variable `window-system' is `x' under X-Windows,
> `mac' under Carbon, and `tty' for a Terminal.

Correction: window-system is nil on a character terminal.

> Also, it may be better to test for specific capabilities, so that when
> the Carbon build gets them your configuration will use them.  e.g.:
> 
> (if (display-images-p)
>     (auto-image-file-mode t))

That is indeed much, much better than testing the value of window-system.

Re: installing emacs and X11 on OS X

[John Paul Wallington]

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

>> The value of the variable `window-system' is `x' under X-Windows,
>> `mac' under Carbon, and `tty' for a Terminal.
>
> Correction: window-system is nil on a character terminal.

*blush* !

-- 
John Paul Wallington

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <87elah9ril.fsf@bundalo.shootybangbang.com>, John Paul
Wallington wrote: 
> e.g.: (eq window-system 'mac) could replace your check.

Perfect; thanks.


> Also, it may be better to test for specific capabilities

In this case the window-system check is exactly the right level of
specificity for what I'm after, which is to add a few global
keybindings iff emacs is running in a mac-native window system.




-- 
d f-d

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Hugo Wolf <hwolf@deutsches.lieder.net>
> Date: Thu, 24 Oct 2002 12:43:29 GMT
> 
> > Also, it may be better to test for specific capabilities
> 
> In this case the window-system check is exactly the right level of
> specificity for what I'm after

It might be perfect today, but as the capabilities of the mac port
changes with time, your customizations will suffer from bitrot.
Testing for specific capabilities avoids the burden to constantly
maintain your init files due to such changes.

Re: installing emacs and X11 on OS X

[Schone Mullerin]

In article <mailman.1035484120.27029.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 
>> In this case the window-system check is exactly the right level of
>> specificity for what I'm after
> 
> It might be perfect today, but as the capabilities of the mac port
> changes with time, your customizations will suffer from bitrot.
> Testing for specific capabilities avoids the burden to constantly
> maintain your init files due to such changes.

Well, thanks for the opinion.  I can only repeat, the window system
tag _is_ the capability in this case.  No other test has any
relevance.  Why this possibility should disturb you so much, I don't
know.

Fwiw I'm well-accustomed to maintaining emacs init files, having done
so for a little over 20 years. It's never been much of a burden, and
I've yet to see any signs of rot (of course I add/remove things as new
versions of emacs make that possible/necessary).


-- 
d f-d

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> Date: Thu, 24 Oct 2002 20:01:27 GMT
> 
> > It might be perfect today, but as the capabilities of the mac port
> > changes with time, your customizations will suffer from bitrot.
> > Testing for specific capabilities avoids the burden to constantly
> > maintain your init files due to such changes.
> 
> Well, thanks for the opinion.  I can only repeat, the window system
> tag _is_ the capability in this case.  No other test has any
> relevance.  Why this possibility should disturb you so much, I don't
> know.

It didn't disturb me.  As someone who knows a bit about Emacs
development in this area, I was trying to help you construct a .emacs
that would be less prone to future changes in functionality.  (An
example of such changes is the color support on character terminals:
many people had their .emacs use window-system to differentiate
between color and colorless Emacs; they got bitten when Emacs 21 was
released.)

I'm sorry if my attempts to help annoyed you.

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Hugo Wolf <hwolf@deutsches.lieder.net>
> Date: Sat, 26 Oct 2002 14:39:38 GMT
> 
> So tell me: what iyo is the right test for "set variables and add key
> bindings so that the l&f of emacs is a little closer to the standard
> aqua l&f for text processing if and only it's running in aqua"?

I don't know what is "l&f" and what is "standard aqua" (never worked
on a Mac), but if you tell what specific functionality does Emacs
have on that system, I will happily suggest a test that doesn't use
window-system.

> > I'm sorry if my attempts to help annoyed you.
> 
> Arrogance annoys me.

Then I gues I'm safe.

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <mailman.1035620182.18482.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 
> It didn't disturb me.  As someone who knows a bit about Emacs
> development in this area, I was trying to help you construct a .emacs
> that would be less prone to future changes in functionality....

So tell me: what iyo is the right test for "set variables and add key
bindings so that the l&f of emacs is a little closer to the standard
aqua l&f for text processing if and only it's running in aqua"?  If
you have a test for this that you think is more appropriate than (eq
window-system 'mac), please share it and I assure you I'll thank you
for it and I'll use it.  If you don't, just admit you made a mistake
and move on.  That's what grownups do.


> I'm sorry if my attempts to help annoyed you.

Arrogance annoys me.

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <mailman.1035645140.22359.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 
>> So tell me: what iyo is the right test for "set variables and add key
>> bindings so that the l&f of emacs is a little closer to the standard
>> aqua l&f for text processing if and only it's running in aqua"?
> 
> I don't know what is "l&f 

Look and feel.


> and what is "standard aqua" 

Aqua is something like a combination window-manager/desktop-manager.
It's what you're looking at and mousing in when you run osx.


> on a Mac), but if you tell what specific functionality does Emacs
> have on that system

<sigh>

All I want to do is make emacs match the l&f conventions of the gui
environment in which it's running.  That's all. Emacs "functionality"
doesn't enter into it.  When it's running in X11, I want the l&f to
match X11 conventions as best it can (which it already does by
default).  When it's running in Aqua, I want the l&f to match Aqua
conventions.  When it's running in a terminal, there is no gui so I
don't want to do anything special.  Given that emacs uses the variable
window-system to represent the gui environment, it seems perfectly
obvious to me that I should use that variable to control these l&f
specializations.

I don't understand why it's so hard to grasp that the gui environment
itself, which emacs represents in the variable window-system, could be
_the_ relevant feature for a certain set of modifications.

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Hugo Wolf <hwolf@deutsches.lieder.net>
> Date: Sat, 26 Oct 2002 21:41:46 GMT
> 
> > I don't know what is "l&f 
> 
> Look and feel.

Thanks.

> When it's running in X11, I want the l&f to
> match X11 conventions as best it can (which it already does by
> default).  When it's running in Aqua, I want the l&f to match Aqua
> conventions.  When it's running in a terminal, there is no gui so I
> don't want to do anything special.

Then I suggest this test:

     (and (eq system-type 'macos) (display-graphic-p))

(I assume that system-type's value is `macos' on Aqua, but I cannot
verify if that's indeed so.)

> I don't understand why it's so hard to grasp that the gui environment
> itself, which emacs represents in the variable window-system, could be
> _the_ relevant feature for a certain set of modifications.

window-system was never meant to be used by user-level code, its use
is deprecated (see etc/NEWS in the Emacs distribution), and it might
disappear altogether in a future Emacs version.  That's why I think
it's basicaly a mistake to use it for anything.

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <mailman.1035672257.29530.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 
> window-system ... is deprecated


Thank you. Finally a _sensible_ reason to avoid using this variable.
Not because it's semantically or morally wrong, as has been claimed so
far -- in fact, it's exactly right -- but because it's deprecated.  I
probably shouldn't ask why this little issue wasn't mentioned earlier
in the discussion...



>      (and (eq system-type 'macos) (display-graphic-p))

There's no logical difference I can see between this and (eq
window-system 'mac) -- i.e., no circumstance I can imagine in which
one would be true and the other false.  Can you think of one?  But if
the emacs developer community is getting away from the use of
window-system, that's reason enough to switch.

The only problem with this is that I can't use it in xemacs, which
doesn't have display-graphic-p. Since almost all of my init code is
shared between xemacs and gnuemacs, I'll need an additional test now,
and I'll also need to find out what the xemacs equivalent of
display-graphic-p is.  The window-system test works in both variants.






> (I assume that system-type's value is `macos' on Aqua, but I cannot
> verify if that's indeed so.)

In osx it's actually 'darwin.  Darwin is the bsd core that underlies
osx.  I don't know what it is in old, pre-unix MacOS.


Thanks again for a real answer.  This is much more useful than all the
earlier posturing.

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Hugo Wolf <hwolf@deutsches.lieder.net>
> Date: Sun, 27 Oct 2002 15:07:18 GMT
> 
> Thank you. Finally a _sensible_ reason to avoid using this variable.
> Not because it's semantically or morally wrong, as has been claimed so
> far -- in fact, it's exactly right -- but because it's deprecated.  I
> probably shouldn't ask why this little issue wasn't mentioned earlier
> in the discussion...

Because I never realized that this aspect has such a profound meaning
for you.  Most people to whom I explained this in the past were
convinced by the other issues I mentioned in this thread.

> >      (and (eq system-type 'macos) (display-graphic-p))
> 
> There's no logical difference I can see between this and (eq
> window-system 'mac)

There's a significant difference: system-type has a precise and fixed
meaning -- the OS on which Emacs runs -- while window-system's
semantics is vague and changes with time.

> The only problem with this is that I can't use it in xemacs, which
> doesn't have display-graphic-p.

Hopefully, they will in the future.  In the meantime, you could pick
up the simple definitions of the display-*-p functions from Emacs,
which I think should work in XEmacs with minimal changes, and plant
them into your .emacs conditioned on XEmacs.

> Thanks again for a real answer.  This is much more useful than all the
> earlier posturing.

You are welcome.  It's sometimes hard to know what will be the
convincing argument; sorry I didn't think about this one before.

Re: installing emacs and X11 on OS X

[Piet van Oostrum]

>>>>> Hugo Wolf <hwolf@deutsches.lieder.net> (HW) writes:

>> (and (eq system-type 'macos) (display-graphic-p))

HW> There's no logical difference I can see between this and (eq
HW> window-system 'mac) -- i.e., no circumstance I can imagine in which
HW> one would be true and the other false.  Can you think of one?  But if
HW> the emacs developer community is getting away from the use of
HW> window-system, that's reason enough to switch.


>> (I assume that system-type's value is `macos' on Aqua, but I cannot
>> verify if that's indeed so.)

HW> In osx it's actually 'darwin.  Darwin is the bsd core that underlies
HW> osx.  I don't know what it is in old, pre-unix MacOS.

Theoretically it could also be 'darwin on a non-macos system.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: installing emacs and X11 on OS X

[Thomas F. Burdick]

Hugo Wolf <hwolf@deutsches.lieder.net> writes:

> In article <mailman.1035672257.29530.help-gnu-emacs@gnu.org>, Eli
> Zaretskii wrote: 
> > window-system ... is deprecated

This sounds like a bad idea to me (see below)

> Thank you. Finally a _sensible_ reason to avoid using this variable.
> Not because it's semantically or morally wrong, as has been claimed so
> far -- in fact, it's exactly right -- but because it's deprecated.  I
> probably shouldn't ask why this little issue wasn't mentioned earlier
> in the discussion...
> 
> >      (and (eq system-type 'macos) (display-graphic-p))
> 
> There's no logical difference I can see between this and (eq
> window-system 'mac) -- i.e., no circumstance I can imagine in which
> one would be true and the other false.  Can you think of one?  But if
> the emacs developer community is getting away from the use of
> window-system, that's reason enough to switch.

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 window-system goes away, I'd have to resort to something truly evil
to determine which system I'm on.

Out of curiosity, why is it depricated?  Because people abuse it where
specific feature tests would be better?  If so, that seems like a bad
reason ... people can abuse anything, but AFAIK, window-system is the
only way to determine what window system you're on.  Or is there a
plan to replace this with a more competant introspection api?

[ 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).  Especially
  because you could then be more specific, because a theoretical
  GTK-Emacs could run under X11 or a framebuffer or... ]

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

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <wzadkz6er2.fsf@cs.uu.nl>, Piet van Oostrum wrote:
> 
> HW> In osx it's actually 'darwin.  Darwin is the bsd core that underlies
> HW> osx.  I don't know what it is in old, pre-unix MacOS.
> 
> Theoretically it could also be 'darwin on a non-macos system.

Yes, darwin can run on other hardware.  Or so I'm told.

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <xcvpttvzodk.fsf@apocalypse.OCF.Berkeley.EDU>, 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.  

Yow!  You're right.  So I _still_ need to use window-system,
deprecated or not.  The non-deprecated solution is indeed semantically
different, just as you say, and it doesn't do what I want.


> 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.

Absolutely.  This is exactly the behavior I want and the behavior I
was getting by checking window-system.



> If window-system goes away, I'd have to resort to something truly evil
> to determine which system I'm on.

Yep.


> Out of curiosity, why is it depricated?  Because people abuse it where
> specific feature tests would be better?  If so, that seems like a bad
> reason ... people can abuse anything, but AFAIK, window-system is the
> only way to determine what window system you're on.  

I've been trying to make this argument for awhile now, so far without
luck.  Maybe you'll do better....



> [ 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).  Especially
>   because you could then be more specific, because a theoretical
>   GTK-Emacs could run under X11 or a framebuffer or... ]

Sounds good to me.  In any case I'm glad at least one other person
out there understands that it's useful to conditionalize emacs l&f
based on the windowing system under which it's running.

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <mailman.1035737630.1161.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 
> Because I never realized that this aspect has such a profound meaning
> for you.  Most people to whom I explained this in the past were
> convinced by the other issues I mentioned in this thread.

No, it's quite sensible to want to conditionalize based on the gui
environment.  If my ability to do so is about to be taken away from
me, I'll have to do something else -- "it's going away" is as
convincing an argument as anyone could make.  But the _right_ test
here is indeed window-system, since that's the closest thing emacs has
to a representation of what gui environment if any emacs is running
in.



>> There's no logical difference I can see between this and (eq
>> window-system 'mac)
> 
> There's a significant difference: system-type has a precise and fixed
> meaning -- the OS on which Emacs runs -- while window-system's
> semantics is vague and changes with time.

See Thomas F. Burdick's response.  The two are different but not for
the reasons you claim.  There's really nothing very vague about X11
windowing vs MacOS windowing vs Windows windowing vs no windowing, at
least not in my mind.  And it's a stretch to claim these change very
often.  It's not as if emacs ports to new windowing systems appear
with any frequency.

No, the two proposed solutions are different because I can run emacs
under Aqua in osx and also under X11 in osx and your proposal won't
distinguish the two, whereas (eq window-system 'mac) will.  Since I
_want_ this distinction, I can't use your suggestion after all.

Given which, what would you recommend?

Re: installing emacs and X11 on OS X

[Chris Lott]

Hugo Wolf <hwolf@deutsches.lieder.net> writes:

> Thanks again for a real answer. This is much more useful than all the
> earlier posturing.

For someone getting free help from a consistenly helpful Emacs
developer/programmer who gives freely of his time to develop the
system you are using and who is only trying to help you not make a
mistake that might end up being a problem in the future, you sure are
acting like a rude bastard.

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

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?

> 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.

> If so, that seems like a bad
> reason ... people can abuse anything

People will abuse less if they have less opportunities for abuse.

> 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.

> 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.

> [ 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.

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <mailman.1035784882.23705.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 
> If there's a difference between these two configurations, there should be 
> a way to distinguish between them.  

There are actually three runtime gui environments in osx.
Distinguishing them is very easy -- window-system does it in a clean,
reliable and consistent way, and as an added bonus works in both
xemacs and gnuemacs.


> Doesn't system-configuration fit the 
> bill? or maybe system-configuration-options?

system-configuration has the same value for any emacs running in osx,
so it obviously can't be used to make any distinctions at
all. system-configuration-options can currently distinguish in a very
ugly way between an emacs that was _built_ with mac-windowing support
and one that wasn't but of course says nothing at all about whether or
not it's actually _running_ in that window system at any given time.

By definition, build-time options can't work as a way to discover
runtime distinctions. This or that individual runtime feature doesn't
work either. To think about it that way is to misunderstand the nature
of a gui environment.  What we're talking about here is not at the
level of "do I have color available".  It's at the level of "do I want
to follow Mac l&f".

You're obviously a very knowledgeable emacs guy and even you don't
seem to be able to find anything other than window-system that works
for this.  Doesn't that tell you something?

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Hugo Wolf <hwolf@deutsches.lieder.net>
> Date: Mon, 28 Oct 2002 12:45:36 GMT
> 
> system-configuration has the same value for any emacs running in osx,
> so it obviously can't be used to make any distinctions at
> all. system-configuration-options can currently distinguish in a very
> ugly way between an emacs that was _built_ with mac-windowing support
> and one that wasn't but of course says nothing at all about whether or
> not it's actually _running_ in that window system at any given time.

Then perhaps a bug report is on order, with a request to provide a way
to distinguish the two configurations you are interested in.

> You're obviously a very knowledgeable emacs guy

I obviously don't know enough about the Mac, so my attempts to help
are less efficient than they could have been.

> and even you don't
> seem to be able to find anything other than window-system that works
> for this.  Doesn't that tell you something?

No, not really.  What should that tell me?

Re: installing emacs and X11 on OS X

[Schone Mullerin]

In article <mailman.1035832709.18867.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 
> Then perhaps a bug report is on order, with a request to provide a way
> to distinguish the two configurations you are interested in.

Of course there already is a nice clean way to make this distinction,
because emacs already has a variable which captures exactly the right
information.  That variable is window-system.  The only bug is that
it's deprecated.  

Are you suggesting a bug report that says "either un-deprecate
window-system or provide an alternative, since it provides information
that isn't otherwise available by any other means"?  If so, we've
reached agreement.



>> and even you don't
>> seem to be able to find anything other than window-system that works
>> for this.  Doesn't that tell you something?
> 
> No, not really.  What should that tell me?

That in emacs as it stands today, window-system is essential.  What
other conclusion could there be?  From which it follows that it's the
right variable to use in some cases -- in fact, in this very one we're
discussing.  From that it follows that the blanket condemnations of
all uses of window-system can't possibly be right.

Re: installing emacs and X11 on OS X

[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!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

On Mon, 28 Oct 2002, Schone Mullerin wrote:

> Of course there already is a nice clean way to make this distinction,
> because emacs already has a variable which captures exactly the right
> information.  That variable is window-system.  The only bug is that
> it's deprecated.

I tried to explain at length why it is not nice and not clean.  As 
another example, it doesn't fit into the future Emacs model where GUI and 
text (a.k.a. tty) frames can be supported in the same session.  On a Mac, 
it's possible that there are several frames each one with its distinct 
look and feel.

Anyway, the need for the specific distinction that was raised in this 
thread is something new, at least to me (I don't think I ever heard it 
before), and seems at present to be specific to the Mac.  I suggest to 
file a feature request.

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

On 28 Oct 2002, Thomas F. Burdick wrote:

> > 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.

There's a difference.  Abuse because there's no alternative means to do 
what you want is more likely and more justified than if the means to do 
it right do exist.

> 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 wasn't removed simply because such abrupt changes are bad practice, 
they hurt back-compatibility too much.

> 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))

Yes, this sounds to me like a good idea.  Please suggest this on 
emacs-devel.

>   (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))

This is IMHO not such a good idea.  If there's a need to know something 
about the functionality of mouse-2, or about the lack thereof, there 
should be a specific predicate for that.  The very reason that you needed 
to put a comment explaining why X11 differs from MS-Windows is an 
evidence that the predicate is going to be a grabbag of indicators for 
support of several unrelated features, features that are not explicitly 
obvious from the predicate name.  If we want to dostinguish between 
2-button and 3-button Emacs, let's do that explicitly, let's not hide 
behind some look and feel.

Re: installing emacs and X11 on OS X

[Hugo Wolf]

In article <mailman.1035870384.15595.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 

> I tried to explain at length why it is not nice and not clean.  

You explained that it's been misued in the past, and I believe
you. That's an excellent reason to get rid of the variable but not any
kind of reason to jettison the concept which window-system is
currently providing ("runtime window system" or "gui environment" or
whatever you call to call it). 


> As 
> another example, it doesn't fit into the future Emacs model where GUI and 
> text (a.k.a. tty) frames can be supported in the same session.  

This suggests that the abstract concept of "runtime window system" is
perfectly valid but that's it's frame-specific.  I have no problem
with that at all.  In fact I like it.  I'm not wedded to the variable
'window-system'.  I'm using it now because I have no choice now --
this is one and only hook emacs provides me.  What it's important to
me is the concept, not the access point.

For emacs as it exists today, I hope we agree that it's a bit silly to
recommend against using the only tool available if you believe that
the concept it's supporting is legitimate.


> Anyway, the need for the specific distinction that was raised in this 
> thread is something new, at least to me (I don't think I ever heard it 
> before)

That's why vigorous discussions are healthy (and why the "how dare you
criticize the developers" attitude is so unhealthy).



> and seems at present to be specific to the Mac.  

Afaik osx is the only platform for which there are native builds of
emacs for two completely different window systems. If this is so, I'm
not surprised the issues we're discussing here never came up before.

Re: installing emacs and X11 on OS X

[Stefan Monnier <foo@acm.com>]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
> 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.

That's true and I generally completely agree that it's not the right
tool, but in the present case, the user wants the behavior to depend
on the kind of window system in use, really and the `window-system'
variable is the best there is for this right now.

And the only problem I can think of with that variable is "what happens
if the running Emacs has some frames open in X others in Gtk others
in a tty and yet others in carbon" ?

Of course, this can't happen right now, so it's not a problem yet.

The only reason to deprecate the use of window-system is because it's
generally misused.  And realistically, it's not going to go away any
time soon, even if it's deprecated because many many many people use
it.  So we should just live with it.  If people misuse it, let's educate
them.

The same problem appears with (string-match "Lucid\\|XEmacs" emacs-version),
yet we're not deprecating string-match, are we ?


        Stefan

Re: installing emacs and X11 on OS X

[Kevin Rodgers]

Hugo Wolf wrote:

> In article <mailman.1035870384.15595.help-gnu-emacs@gnu.org>, Eli
> Zaretskii wrote: 
> 
>>As 
>>another example, it doesn't fit into the future Emacs model where GUI and 
>>text (a.k.a. tty) frames can be supported in the same session.  
>>
> 
> This suggests that the abstract concept of "runtime window system" is
> perfectly valid but that's it's frame-specific.  I have no problem
> with that at all.  In fact I like it.  I'm not wedded to the variable
> 'window-system'.  I'm using it now because I have no choice now --
> this is one and only hook emacs provides me.  What it's important to
> me is the concept, not the access point.


Cool.  So window-system becomes a frame parameter.  And if it's passed to
make-frame, it determines what kind of frame to create.  Nice and clean.

-- 
<a href="mailto:&lt;kevinr&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Hugo Wolf <hwolf@deutsches.lieder.net>
> Date: Tue, 29 Oct 2002 13:42:58 GMT
> 
> That's why vigorous discussions are healthy (and why the "how dare you
> criticize the developers" attitude is so unhealthy).

I didn't say anything like that in this whole thread.  In fact, I
(indirectly) said exactly the opposite: I patiently tried to explain
the motivation for deprecating the use of window-system, so that those
reasons could be subject to public scrutiny and perhaps bug reports or
feature requests.

I'm at a loss why did you need to accuse me of such a nasty attitude.

> Afaik osx is the only platform for which there are native builds of
> emacs for two completely different window systems. If this is so, I'm
> not surprised the issues we're discussing here never came up before.

Yes, that seems to be the reason.

Re: installing emacs and X11 on OS X

[Eli Zaretskii]

> From: "Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@rum.cs.yale.edu>
> Newsgroups: gnu.emacs.help
> Date: 29 Oct 2002 10:41:09 -0500
> 
> The only reason to deprecate the use of window-system is because it's
> generally misused.  And realistically, it's not going to go away any
> time soon, even if it's deprecated because many many many people use
> it.  So we should just live with it.  If people misuse it, let's educate
> them.

Absolutely.  That's what I was trying to do here: educate people as to
why window-system is generally the wrong tool.

Re: installing emacs and X11 on OS X

[Stefan Monnier <foo@acm.com>]

> Absolutely.  That's what I was trying to do here: educate people as to
> why window-system is generally the wrong tool.

But of course, the present case is one where window-system is
the best choice, so it's not the best example to use to educate
people about not using window-system ;-)


        Stefan

Re: installing emacs and X11 on OS X

[Schone Mullerin]

In article <mailman.1035924328.7472.help-gnu-emacs@gnu.org>, Eli
Zaretskii wrote: 
>> That's why vigorous discussions are healthy (and why the "how dare you
>> criticize the developers" attitude is so unhealthy).
> 
> I'm at a loss why did you need to accuse me of such a nasty attitude.

I'm sorry, I thought it was clear I was referring to another post from
another contributor, one who took me to task for daring to criticize a
developer.  Look back a couple of days, you'll see it.  It is, just as
you say, an offensive (and idiotic) attitude.

But I didn't mean to suggest it was _your_ attitude.  Quite the
contrary, I think this discussion has gone very well.

Sorry again if the reference was unclear.