From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Hugo Wolf Newsgroups: gmane.emacs.help Subject: Re: installing emacs and X11 on OS X Date: Tue, 29 Oct 2002 13:42:58 GMT Organization: AT&T Broadband Sender: help-gnu-emacs-admin@gnu.org Message-ID: References: NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1035899214 23092 80.91.224.249 (29 Oct 2002 13:46:54 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 29 Oct 2002 13:46:54 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 186Whl-0005zk-00 for ; Tue, 29 Oct 2002 14:46:49 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 186WhK-0005io-00; Tue, 29 Oct 2002 08:46:22 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!nntp-server.caltech.edu!attla2!ip.att.net!attbi_feed3!attbi_feed4!attbi.com!sccrnsc03.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: slrn/0.9.7.4 (Darwin) Original-Lines: 42 Original-NNTP-Posting-Host: 66.31.41.137 Original-X-Complaints-To: abuse@attbi.com Original-X-Trace: sccrnsc03 1035898978 66.31.41.137 (Tue, 29 Oct 2002 13:42:58 GMT) Original-NNTP-Posting-Date: Tue, 29 Oct 2002 13:42:58 GMT Original-Xref: shelby.stanford.edu gnu.emacs.help:106493 Original-To: help-gnu-emacs@gnu.org Errors-To: help-gnu-emacs-admin@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.help:3043 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:3043 In article , 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.