From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Simon Leinen Newsgroups: gmane.emacs.devel Subject: Re: Printing Date: Mon, 7 May 2012 19:20:35 +0200 Message-ID: References: <5f0660120903280331y780c80b7i57a8115dc4b029eb@mail.gmail.com> <49CE3A84.9070705@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d044473af00208504bf757dcf X-Trace: dough.gmane.org 1336411253 19331 80.91.229.3 (7 May 2012 17:20:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 May 2012 17:20:53 +0000 (UTC) Cc: YAMAMOTO Mitsuharu , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 07 19:20:48 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SRRc5-0005eY-8Q for ged-emacs-devel@m.gmane.org; Mon, 07 May 2012 19:20:45 +0200 Original-Received: from localhost ([::1]:60027 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRRc4-0007aO-HF for ged-emacs-devel@m.gmane.org; Mon, 07 May 2012 13:20:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRRc1-0007a8-Bz for emacs-devel@gnu.org; Mon, 07 May 2012 13:20:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRRbz-0002Mz-4q for emacs-devel@gnu.org; Mon, 07 May 2012 13:20:40 -0400 Original-Received: from mail-ob0-f169.google.com ([209.85.214.169]:65108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRRby-0002Ms-RO for emacs-devel@gnu.org; Mon, 07 May 2012 13:20:39 -0400 Original-Received: by obbwd18 with SMTP id wd18so10595981obb.0 for ; Mon, 07 May 2012 10:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xPhocB9Doznbe7ca6FU2zne/gZsaz5isVesxo2WFGfg=; b=DQZE1MOdDOvF8BZavk+ynh97YPAMZ2a+J3fbctgzw2EJU0uLSdKLn8T9nABFwbJ1yF hiZLDkR5qIPPyyjuWE6CICoBE86XJeTgOiqhfxzyfX2K2jZ9J/Ykk1IXZE4I0zz4r576 TPJShSIh0tp2nrsurkLpdgT4YdkawYMTaZFWn2aSk56Oy/4MvfdKgMDOjH6GzAvpD3dH vTVWpho4xwpsVR0ne6Mu8Hkz/o5GuCQpRF/PCd9ZxhE9KDvyJQ/1EKm/9RLUvzFQYUG8 8KiRYPkRcPvzeGi1utacWuxuFr7qRGSqykZfvqwdgiqTezwZWCa+LAmpJ2E0yos1Yj7K kSAQ== Original-Received: by 10.182.51.9 with SMTP id g9mr22867707obo.56.1336411236081; Mon, 07 May 2012 10:20:36 -0700 (PDT) Original-Received: by 10.182.246.39 with HTTP; Mon, 7 May 2012 10:20:35 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150358 Archived-At: --f46d044473af00208504bf757dcf Content-Type: text/plain; charset=ISO-8859-1 > > > Is anyone already working for supporting multiple types of graphical > > terminals simultaneously? > > Simon Leinen wanted to work on this a while ago, but I haven't heard > back from him about it, so I expect he was sufficiently busy with other > problems > Unfortunately that's exactly true. I never really got started with it, and won't get to it in the near or medium future. However I'm more than willing to help test this if someone does start implementing this. It would be a great to be able to use a single Emacs that can display on > a w32 display as well as X11 remote displays. > For me the motivation was similar (except Mac/NextStep instead of w32), but my current workaround is to just use X11 on the Mac. Improved TTY/X11(/...) coexistence could be another benefit. I allow myself to quote some useful hints from a private mail you sent me then (almost three years ago): Stefan> It'd would be a good change, yes. I don't think anybody has started Stefan> working on that (the same holds for w32+X11). Stefan> IIUC, the work necessary to get it to work is as follows: Stefan> - handle all the necessary renaming (many C functions have the same name Stefan> in the different backends). This may require introducing some Stefan> additional indirections to dynamically decide which of the backend Stefan> functions to use. We already have such indirections (to choose betwen Stefan> ty and GUI code), so most of the infrastructure should be there Stefan> already, but there's most likely still some things missing, especially Stefan> for the features which don't exist under ttys. Stefan> - change the various #ifdefs so that more than one of each GUI's code Stefan> can be compiled in at the same time. Stefan> - try and figure out what to do with all the remaining problems (similar Stefan> to what you're saying about the indirect problems introduced by the Stefan> multi-tty code, such as ssh-agent issues). It'll probably be a good Stefan> time to fix all the mess we still have around the "x-*" functions Stefan> (some of which are X11-specific but others aren't). Best regards, -- Simon. --f46d044473af00208504bf757dcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Is anyone already working for supporting multiple types of graphical<= br> > terminals simultaneously?

Simon Leinen wanted to work on this a while ago, but I haven't he= ard
back from him about it, so I expect he was sufficiently busy with other
problems

Unfortunately that's exact= ly true. =A0I never really got started with it, and won't get to it in = the near or medium future. =A0However I'm more than willing to help tes= t this if someone does start implementing this.

It would be a great to be able to use a single Emacs that can display on a w32 display as well as X11 remote displays.

For me the motivation was similar (except Mac/NextStep instead of w3= 2), but my current workaround is to just use X11 on the Mac. =A0Improved TT= Y/X11(/...) coexistence could be another benefit.

I allow myself to quote some useful hints from a privat= e mail you sent me then (almost three years ago):

=
Stefan> It'd would be a good change, yes. =A0 I don't = think anybody has started
Stefan> working on that (the same holds for w32+X11).
Ste= fan> IIUC, the work necessary to get it to work is as follows:
Stefan> - handle all the necessary renaming (many C functions have the = same name
Stefan> =A0 in the different backends). =A0This may require introdu= cing some
Stefan> =A0 additional indirections to dynamically d= ecide which of the backend
Stefan> =A0 functions to use. =A0We= already have such indirections (to choose betwen
Stefan> =A0 ty and GUI code), so most of the infrastructure should = be there
Stefan> =A0 already, but there's most likely stil= l some things missing, especially
Stefan> =A0 for the features= which don't exist under ttys.
Stefan> - change the various #ifdefs so that more than one of each = GUI's code
Stefan> =A0 can be compiled in at the same time= .
Stefan> - try and figure out what to do with all the remaini= ng problems (similar
Stefan> =A0 to what you're saying about the indirect problems i= ntroduced by the
Stefan> =A0 multi-tty code, such as ssh-agent= issues). =A0It'll probably be a good
Stefan> =A0 time to = fix all the mess we still have around the "x-*" functions
Stefan> =A0 (some of which are X11-specific but others aren't).=

Best regards,
--=A0
Simon.
--f46d044473af00208504bf757dcf--