Re: Post-22.1 development?

[David Kastrup <dak@gnu.org>]

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".
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