From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: Post-22.1 development? Date: Mon, 11 Jun 2007 15:23:55 -0700 Message-ID: <200706112223.l5BMNt30021700@oogie-boogie.ics.uci.edu> References: <878xb05ras.fsf@stupidchicken.com> <200706101559.l5AFxBFb006829@oogie-boogie.ics.uci.edu> <86fy4yg62v.fsf@lola.quinscape.zz> <200706111702.l5BH2Q2w000121@oogie-boogie.ics.uci.edu> <85tzte9unf.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181600742 13186 80.91.229.12 (11 Jun 2007 22:25:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 11 Jun 2007 22:25:42 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 12 00:25:40 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 1HxsKQ-00082F-Dx for ged-emacs-devel@m.gmane.org; Tue, 12 Jun 2007 00:25:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HxsKP-0008EN-Q1 for ged-emacs-devel@m.gmane.org; Mon, 11 Jun 2007 18:25:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HxsKL-0008DF-Tm for emacs-devel@gnu.org; Mon, 11 Jun 2007 18:25:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HxsKJ-0008Cm-LP for emacs-devel@gnu.org; Mon, 11 Jun 2007 18:25:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HxsKJ-0008Cj-Hk for emacs-devel@gnu.org; Mon, 11 Jun 2007 18:25:31 -0400 Original-Received: from oogie-boogie.ics.uci.edu ([128.195.1.41]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HxsKG-0001dI-14; Mon, 11 Jun 2007 18:25:28 -0400 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id l5BMNt30021700; Mon, 11 Jun 2007 15:23:55 -0700 (PDT) In-Reply-To: <85tzte9unf.fsf@lola.goethe.zz> (David Kastrup's message of "Mon\, 11 Jun 2007 21\:08\:04 +0200") Original-Lines: 209 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: Solaris 9 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:72654 Archived-At: David Kastrup writes: > 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". I don't appreciate the snide remarks and your off the high horse attitude, if you find any factual inaccuracies in my statement, please point to them. The citation you asked for is below. I find my statements to be quite accurate. Now, for RMS' benefit: I am not sure what the point of your message was, but you have not disproved in your message the main arguments of my message: the environments issue is a side story for the multi-tty branch, it can easily be changed with minimal side effects after the merge IFF we find there is a problem with the current implementation. The code on the multi-tty branch is surely not perfect, and more issues might be discovered after it is merged, but it is functional today. Getting it into the hands of more developers will only help this process. You seem to have very strong opinions about this environment stuff, you are welcome to offer an alternative implementation that satisfies all the constraints the current one does, but please stop blocking progress because of that. -- citing earlier messages from a different thread as requested -- From: Karoly Lorentey Subject: Re: Multi-tty design (Re: Reordering etc/NEWS) Newsgroups: gmane.emacs.devel To: David Kastrup Cc: Andreas Schwab , Dan Nicolaescu , joakim@verona.se, emacs-devel@gnu.org Date: Fri, 18 May 2007 13:55:53 +0200 David Kastrup wrote: >> (Emacs may have been running in the background for weeks, and I may >> have just started working on my brand new TeX file in a recently >> started emacsclient session.) Both viewpoints should be catered >> for. > > I disagree. If a viewpoint can't be catered for without breaking a > _lot_ of things and guarantees, catering for it might be a bad idea. OK, I give up in disgust. Do whatever you want. I mean it: go ahead and implement whatever environment semantics you find most appropriate. I have presented all my best reasons why I think we should support local environments. I have even proposed what I think was a reasonable compromise. We simply can not reach a common ground if you keep discarding my entire viewpoint and use-cases. Clearly I won't convince you by repeating the same arguments over and over, and you will definitely not convince me either. There is no point in arguing for the sake of arguing. I throw in the towel, you win. Congratulations. Now that this area is finally taken care of, let us choose and discuss another part of multi-tty design instead. * * * I'm really not interested in arguing about environments any more, but since I have already written my response below, I'll post it for reference. > There is lots of Elisp code that does not even run in a frame: network > buffers, spell check buffers, background processes and the like. This code will also work fine for single-terminal users. All existing code would work fine for single-terminal users. Single-terminal users will not run into regressions. We are backward compatible. I think you are vastly overemphasizing the importance of environment variables in general and "future compatibility" in particular. [snip, the rest of the message can be found in the archives] From: Karoly Lorentey Subject: Re: Multi-tty design (Re: Reordering etc/NEWS) Newsgroups: gmane.emacs.devel To: David Kastrup Cc: Andreas Schwab , Dan Nicolaescu , joakim@verona.se, emacs-devel@gnu.org Date: Fri, 18 May 2007 19:40:53 +0200 David Kastrup wrote: > Karoly Lorentey writes: >>> We simply can not reach a common ground if you keep >> discarding my entire viewpoint and use-cases. > > I don't see that I do. Presenting existing use-cases and problems > with them does not mean that I discard your views and approaches. > It > just means that I don't consider them optimal. I want to make it clear that I'm not angry at you, just tired of the argument. I believe I have said everything I had to say on the topic of environment variables, and I simply don't think that continuing this conversation will help us advance towards a mutually satisfactory solution. My position is already available in the archives. I'll let you implement any solution that is acceptable to you. I promise I won't mind. Meanwhile, we can move on to discuss some other topics. User feedback will help us decide what (if anything) needs to be changed later. We are talking about some 50-100 lines of well-separated code, so it's not like it is going to be much work to experiment with alternative implementations. I'm sorry if it is unusual or impolite to just give up arguing like that. It is now clear to me that you care much more about how environments behave than I do. [snip, the rest of the message can be found in the archives] --- end citation --- > 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. What is your point with this statement? Do you want to imply that I am suggesting otherwise? If you are trying to have a discussion with me such remarks are completely unproductive. You do similar things several times in your message. > 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. RMS has not stated until now that having texinfo documentation is a merge precondition. I don't remember this being a common practice in emacs either. Quite the contrary, that is why there is a practice of using +++ and --- in the NEWS file for stuff that is implemented and still needs texinfo documentation. > > 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. And I addressed that: "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." > > > 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. This is an overly broad statement that you don't support with facts. You have several of those below. They are not really related to my original argument so I don't want to derail to discuss them.