From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Post-22.1 development? Date: Mon, 11 Jun 2007 21:08:04 +0200 Message-ID: <85tzte9unf.fsf@lola.goethe.zz> References: <878xb05ras.fsf@stupidchicken.com> <200706101559.l5AFxBFb006829@oogie-boogie.ics.uci.edu> <86fy4yg62v.fsf@lola.quinscape.zz> <200706111702.l5BH2Q2w000121@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181588900 1117 80.91.229.12 (11 Jun 2007 19:08:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 11 Jun 2007 19:08:20 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 11 21:08:18 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 1HxpFR-0006xl-Qy for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2007 21:08:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HxpFR-0000yK-HN for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2007 15:08:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HxpFM-0000tk-Ju for emacs-devel@gnu.org; Mon, 11 Jun 2007 15:08:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HxpFL-0000sx-Pt for emacs-devel@gnu.org; Mon, 11 Jun 2007 15:08:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HxpFL-0000sk-MG for emacs-devel@gnu.org; Mon, 11 Jun 2007 15:08:11 -0400 Original-Received: from mail-in-15.arcor-online.net ([151.189.21.55]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HxpFJ-0008Bg-G3; Mon, 11 Jun 2007 15:08:10 -0400 Original-Received: from mail-in-01-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19]) by mail-in-15.arcor-online.net (Postfix) with ESMTP id B8732A4047; Mon, 11 Jun 2007 21:08:07 +0200 (CEST) Original-Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 578922C6D52; Mon, 11 Jun 2007 21:08:07 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-022-040.pools.arcor-ip.net [84.61.22.40]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id ED7058C46F; Mon, 11 Jun 2007 21:08:06 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id A64BC1C3E01D; Mon, 11 Jun 2007 21:08:04 +0200 (CEST) In-Reply-To: <200706111702.l5BH2Q2w000121@oogie-boogie.ics.uci.edu> (Dan Nicolaescu's message of "Mon\, 11 Jun 2007 10\:02\:26 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-Virus-Scanned: ClamAV 0.90.3/3400/Mon Jun 11 19:41:37 2007 on mail-in-15.arcor-online.net X-Virus-Status: Clean 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:72637 Archived-At: Dan Nicolaescu writes: > David Kastrup writes: > > > Richard Stallman writes: > > > > > How about merging the multi-tty branch? The changes on that branch are > > > much more localized, so porting fixes from the trunk to the EMACS_22 > > > branch should not be a big issue. > > > > > > Does anyone see a problem with this idea? > > > > Well, the setenv/process-environment thing I wanted to have a look at: > > in the current state, it will require quite a few changes in existing > > packages (including packages not distributed as part of Emacs), and I > > think that the approach which I sketched out would pretty much > > eliminate that problem. > > Let me reiterate Karoly's (the multi-tty author) opinion on this, > which I also second as a contributor to that branch and as a (almost > exclusive) user for about 2 years: the environment variables thing > is a peripheral issue, and a rather obscure one. Dan, please either either _quote_ Karoly, or speak for yourself. I don't think that you do Karoly a favor by this sort of "reiteration". Anyway, we don't want obscure stuff entered into Emacs. We want to have things work as closely to before (and to the expected way) as possible. There is exactly _zero_ documentation of the multi-tty branch in either Emacs and Elisp manual as far as I can see. And we want to have the necessary documentation of the multi-tty functionality (similar to multi-display documentation currently) to be confined to a single chapter. The current entanglement of frame-local variables, terminal-local variables and environment variables, with complete semantics changes in all of the accessor functions of the environment as well as the data structures, is completely unfit for an isolated chapter since it pervades too much other stuff. If you feel differently, try creating Texinfo documentation for multi-tty that supplements the existing documentation, without touching too many existing chapters. > Changing this requires about 50-100 lines of code (including > comments) and it can be done without major impact on the rest of the > multi-tty functionality (it has happened a few times on the > multi-tty branch already). > > Karoly does not think there's a problem with the current > implementation (and I second that too), but he would have no > objection if David was to replace the current implementation. Look, I quoted code both in Emacs itself as well as in external packages that was affected. > > Merging multi-tty to the trunk now could mean that some people > > start patching up other packages inside or outside of Emacs to > > work with the current environment variable settings, while > > others will change the mechanisms eventually. > > The changes in question for external packages probably amount to 1-2 > lines of code. Plus I don't think we should be concerned about > external packages at this point. Most incompatible API changes don't amount to more than 1-2 lines of code in external packages. We still don't do them lightly. In particular, when they affect close to everything. That is the state of affairs with "locales", "specifiers" and "instantiators" in XEmacs. They provide a technical framework for displaying fonts, images, toolbars and other stuff on a variety of terminals and devices. They have provided multitty functionality on XEmacs for probably a decade or more. They have also made it pretty much impossible for anybody except a guru to create code dealing with images and similar stuff even on a single tty. We don't want a similar exposure of multi-tty building blocks to the programmer who is not interested in them. And people dealing with environment variables are more likely than not expecting to have multi-tty functionality getting in their way. > For the code in Emacs, if the implementation changes I volunteer to > go over and fix any issues. I guesstimate this to be less than 10 > minutes of work. But we don't want to have to change callers that are not logically involved with multi-tty functionality. > So in conclusion _my_ (quite informed) opinion is that this issue > should not stop a merge. I disagree. > Please let's move forward unless there are more serious issues that > need consideration. Breaking code in unrelated areas lightly is something which I consider serious. You call for ignoring that opinion. In that case I ask you to draft the necessary documentation in the Elisp and Emacs manuals so that people get a better feel of the extent of the effects. If this is not serious, existing chapters should hardly be affected, right? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum