Re: Post-22.1 development?

[Dan Nicolaescu <dann@ics.uci.edu>]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >   > Richard Stallman <rms@gnu.org> 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 <karoly@lorentey.hu>
     Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
     Newsgroups: gmane.emacs.devel
     To: David Kastrup <dak@gnu.org>
     Cc: Andreas Schwab <schwab@suse.de>, Dan Nicolaescu <dann@ics.uci.edu>, 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 <karoly@lorentey.hu>
     Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
     Newsgroups: gmane.emacs.devel
     To: David Kastrup <dak@gnu.org>
     Cc: Andreas Schwab <schwab@suse.de>, Dan Nicolaescu <dann@ics.uci.edu>, joakim@verona.se, emacs-devel@gnu.org
     Date: Fri, 18 May 2007 19:40:53 +0200
                                                                
     
     David Kastrup wrote:
     > Karoly Lorentey <karoly@lorentey.hu> 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.