From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?S8Ohcm9seSBMxZFyZW50ZXk=?= Newsgroups: gmane.emacs.devel Subject: Re: multi-tty branch created Date: Wed, 16 May 2007 22:48:38 +0200 Message-ID: References: <87sla0rgs4.fsf@catnip.gol.com> <85abw8pyk7.fsf@lola.goethe.zz> <85646wpuqn.fsf@lola.goethe.zz> <85ps503by4.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1927067346==" X-Trace: sea.gmane.org 1179348553 30447 80.91.229.12 (16 May 2007 20:49:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 May 2007 20:49:13 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 16 22:49:12 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HoQQm-0007ej-Bu for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 22:49:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoQYn-0005VW-DG for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 16:57:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HoQYj-0005UU-5A for emacs-devel@gnu.org; Wed, 16 May 2007 16:57:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HoQYg-0005U6-Kp for emacs-devel@gnu.org; Wed, 16 May 2007 16:57:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoQYg-0005U3-EZ for emacs-devel@gnu.org; Wed, 16 May 2007 16:57:18 -0400 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HoQQe-0006hD-Cl for emacs-devel@gnu.org; Wed, 16 May 2007 16:49:00 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HoQQW-0006T6-L5 for emacs-devel@gnu.org; Wed, 16 May 2007 22:48:52 +0200 Original-Received: from catv5403a040.pool.t-online.hu ([84.3.160.64]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 May 2007 22:48:52 +0200 Original-Received: from karoly by catv5403a040.pool.t-online.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 May 2007 22:48:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 87 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: catv5403a040.pool.t-online.hu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) In-Reply-To: <85ps503by4.fsf@lola.goethe.zz> X-Enigmail-Version: 0.95.0 X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:71193 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1927067346== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE641B8AA01E7258E1B88B3CB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE641B8AA01E7258E1B88B3CB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David Kastrup wrote: > "K=C3=A1roly L=C5=91rentey" writes: >>> emacsclient operation in multitty is different as compared to >>> previously. So people can't avoid multitty completely, meaning >>> that we can't bluntly state "situation can't be worse than >>> previously, no regression" but need to evaluate multitty somewhat >>> more closely before finding it suited for trunk, even if the >>> compilation problems on DOS/Windows/Mac have been tackled. >> Hold your horses. >=20 > You would not want me to: my concerns are likely similar to those of > others, so you want to get them discussed and refuted. Yes. But saying that multi-tty is somehow more suspect because it changes emacsclient sounds strange to me. Well of course it changes it. The entire point of the branch is to fix how emacsclient works. D'oh! I was arguing that all the existing functionality is retained by design. If there is a feature that was lost, then that's a bug. >> There is always "emacsclient --current-frame" to prevent emacsclient >> from creating a new terminal. This retains much of the >> functionality of the original emacsclient, including, I believe, >> things like C-#, and does not use multi-tty features. >=20 > Still, environments do no longer work the same even if you don't use > multi-tty features. Yes they do. "emacsclient --current-frame" does not create a new set of local environment variables, but reuses the original environment of the Emacs process. It should work exactly the same as emacsclient on the trunk. Does it not? As I said, the one and only truly incompatible change in the multi-tty branch is that even without any emacsclient connections, `process-environment' is nil by default, and there is a new `environment' function for listing all variables. I don't think you can argue with a straight face that all hell will break loose if we make such a change, or that it is unacceptable to make our hackers adapt existing code for these changes. After all, we are working on a new major version, and there aren't all that many Emacs packages that care about environment variables. A sizable portion of the few that do simply call getenv and setenv, or let-bind `process-environment', which works fine with multi-tty as well. I have presented my reasons for the change; I still think the client-local environment semantics are the right way to go, although the implementation may be improved. >> Keep in mind that improving emacsclient behaviour is one of the >> primary results of the multi-tty branch. >=20 > But we don't want secondary results interfering with the work of those > who don't make use of the primary results. As I have explained, "emacsclient --current-frame" is the way people can get back the original behaviour. If there are serious bugs, the legions of people who're now testing multi-tty will likely report them before the merge. Is that not sufficient to prevent undue interference? I encourage people on supported platforms to try their favourite emacsclient options in the multi-tty branch, and report anything that breaks. --=20 Karoly --------------enigE641B8AA01E7258E1B88B3CB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGS24p6eoyqA+yej8RAvZMAKCsXzr+YcuEXUUuk+gLu1/6gRFIHgCePTu0 0veVLRWK/LKEdnwxdMPff1o= =Pw1h -----END PGP SIGNATURE----- --------------enigE641B8AA01E7258E1B88B3CB-- --===============1927067346== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============1927067346==--