Reordering etc/NEWS

Reordering etc/NEWS

[Richard Stallman]

Would someone please go through etc/NEWS and, within each page for the
coming release, reorder the subsections in the best order you can
find?

What makes an order good is a combination of _most important first_
and _related things together_.  There's not necessarily any one single
right order, but some orders are much better than others.  The current
order was not chosen for this, so it is probably very easy to improve.

Re: Reordering etc/NEWS

[Glenn Morris]

Richard Stallman wrote:

> Would someone please go through etc/NEWS and, within each page for the
> coming release, reorder the subsections in the best order you can
> find?

I gave it a go. It's all rather subjective, and it so enormous it's
hard to make a dent. If someone wants to re-arrange it again, they
should feel free.

Please, what now is your plan for making a release? April 23rd was the
original date that everyone seemed to consider reasonable. That is now
nearly two weeks ago. Nothing major has happened since then to force a
delay, things just keep dragging on.

Why not make a decision about python and tetris based on the currently
available information, and make a release?

Re: Reordering etc/NEWS

[Jason Rumney]

Glenn Morris wrote:
> Please, what now is your plan for making a release? April 23rd was the
> original date that everyone seemed to consider reasonable. That is now
> nearly two weeks ago. Nothing major has happened since then to force a
> delay

Apart from a recent change to process.c, which apparently breaks Gnus 
and requires changes to the Lisp Reference.

Re: Reordering etc/NEWS

[Richard Stallman]

    I gave it a go. It's all rather subjective, and it so enormous it's
    hard to make a dent. If someone wants to re-arrange it again, they
    should feel free.

Did you give this attention to the whole of NEWS, or just part?  If
you covered all the file, I expect that your work is good enough.
There is no one right answer.  Maybe someone else could make it a
little better, but that isn't crucial.

    Please, what now is your plan for making a release? April 23rd was the
    original date that everyone seemed to consider reasonable. That is now
    nearly two weeks ago.

After 5 years, waiting two weeks is not a big deal.  Please don't
make a mountain out of a molehill on the peak of a mountain.

The main thing that is delaying the release now is what to do
about python.el.  I am talking with a lawyer about it now.
I think we will be able to use it.

    Why not make a decision about python and tetris based on the currently
    available information, and make a release?

I found out that we need not do anything regarding tetris.

Re: Reordering etc/NEWS

[Glenn Morris]

Richard Stallman wrote:

> Did you give this attention to the whole of NEWS, or just part? 

All of it.

Re: Reordering etc/NEWS

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 06 May 2007 13:57:11 -0400
> Cc: emacs-devel@gnu.org
> 
>     Please, what now is your plan for making a release? April 23rd was the
>     original date that everyone seemed to consider reasonable. That is now
>     nearly two weeks ago.
> 
> After 5 years, waiting two weeks is not a big deal.  Please don't
> make a mountain out of a molehill on the peak of a mountain.

I think you overreact.  A simple request for your current release plan
hardly qualifies as making a mountain out of a molehill.  I think
people who worked so very hard for the release deserve to know that
much.

> The main thing that is delaying the release now is what to do
> about python.el.

We know that.  But, while waiting for this issue to be resolved,
there's no need to install changes that do not fix very grave bugs.
If no grave bugs are reported, there's nothing wrong in waiting
without installing anything at all.

Re: Reordering etc/NEWS

[Richard Stallman]

    I think you overreact.  A simple request for your current release plan
    hardly qualifies as making a mountain out of a molehill.

No.  What qualifies as making a mountain out of a molehill
is making a big deal out of 2 weeks.

Thus, the message as a whole constitutes badgering.  It demanded that
I state my "current release plan", and to back up this demand, it made
a mountain out of this 2-week molehill.

When people badger me, I do not give them what they want.  Thus, of
course I gave absolutely nothing of what was demanded.

I will consider the proposal if it is requested by a substantial group
of people who are treating me with respect over a period of time.

Re: Reordering etc/NEWS

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I think you overreact.  A simple request for your current release plan
>     hardly qualifies as making a mountain out of a molehill.
>
> No.  What qualifies as making a mountain out of a molehill
> is making a big deal out of 2 weeks.
>
> Thus, the message as a whole constitutes badgering.  It demanded that
> I state my "current release plan", and to back up this demand, it made
> a mountain out of this 2-week molehill.
>
> When people badger me, I do not give them what they want.  Thus, of
> course I gave absolutely nothing of what was demanded.
>
> I will consider the proposal if it is requested by a substantial group
> of people who are treating me with respect over a period of time.

You will consider the proposal of actually telling the developers what
kind of work should be done on what branches only if a substantial
group of people who are treating you with respect over a period of
time will make it?  The last time I looked, this request _was_ placed
by a substantial amount of developers that have treated you with
respect for years.

Indeed, there is still nobody who does any commits against your
wishes, even though you don't even bother to tell people this wishes.
Whatever one wants to think of your purported impression of
"badgering", development _and_ motivation of developers is stalled.

And the situation where nobody knows anymore what branch is supposed
to contain what work, and what kind of work can even be done at the
moment, is very, very bad for Emacs development, and I don't see that
badgers have any involvement with that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Jan Djärv]

David Kastrup skrev:

> 
> Indeed, there is still nobody who does any commits against your
> wishes, even though you don't even bother to tell people this wishes.
> Whatever one wants to think of your purported impression of
> "badgering", development _and_ motivation of developers is stalled.

I, as I'm sure many others, have things that we have postponed to check in 
"after the release".  It is a bit confusing that HEAD can't be opened for that 
work.  I understand that the release has been held up (by the python issue for 
example), and that makes perfect sense.  But development has stalled, and I 
have not seen any motivation for it (I might have missed it though).

	Jan D.

Re: Reordering etc/NEWS

[Glenn Morris]

Richard Stallman wrote:

> Thus, the message as a whole constitutes badgering.  It demanded that
> I state my "current release plan", and to back up this demand, it made
> a mountain out of this 2-week molehill.

For the record, I disagree with your statements that I was "badgering"
you and "making demands". I can certainly understand you feeling
besieged at the moment, and obviously I can't be objective about how
my message reads.

Anyway, apologies to all for triggering a non-productive thread.
Let's move on.

Re: Reordering etc/NEWS

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> Richard Stallman wrote:
>
>> Thus, the message as a whole constitutes badgering.  It demanded
>> that I state my "current release plan", and to back up this demand,
>> it made a mountain out of this 2-week molehill.
>
> For the record, I disagree with your statements that I was
> "badgering" you and "making demands".

Well, you completed rearranging NEWS according to Richard's request in
an unexpectedly short time.

> Anyway, apologies to all for triggering a non-productive thread.
> Let's move on.

How could we?  We need the word about what can be done in which branch
for that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: spect. [Was: Reordering etc/NEWS]

[Alan Mackenzie]

On Mon, May 07, 2007 at 12:50:25PM -0400, Richard Stallman wrote:

> I will consider the proposal if it is requested by a substantial group
> of people who are treating me with respect over a period of time.

A conjecture regarding respect:  In every pair of hackers in this
mailing list, each has some specialist skill or knowledge useful to
the project that the other lacks.  Therefore respect is due from
everybody to everybody else.

More to the point: respect is due from everybody to everybody simply as
fellow travellers on the weary road of existence.  We all want the same
thing - Emacs 22.1.  I think a lot of us are feeling stressed and
frustrated right now - so it's not a good time to squabble.

Richard has to decide when Emacs is ready to release, and that's a
decision fraught with uncertainty and stress.  So everyone, please stop
bugging him!

-- 
Alan Mackenzie (Ittersbach, Germany).

Re: spect. [Was: Reordering etc/NEWS]

[Mathias Dahl]

> Richard has to decide when Emacs is ready to release, and that's a
> decision fraught with uncertainty and stress.  So everyone, please stop
> bugging him!

Amen to that.

Re: Reordering etc/NEWS

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: rgm@gnu.org, emacs-devel@gnu.org
> Date: Mon, 07 May 2007 12:50:25 -0400
> 
> When people badger me, I do not give them what they want.

When my enemies badger me, I do not give them what they want, and the
more they badger me, the more steadfastly I resist.

But we are not your enemies, and this is not a conspiracy to badger
you.  It just happened that quite a few of us disagree with your ideas
of what should and what shouldn't go in so close to the release.
Please, let us get back to proportions and treat a disagreement as
just that.

Re: Reordering etc/NEWS

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> CC: rgm@gnu.org, emacs-devel@gnu.org
>> Date: Mon, 07 May 2007 12:50:25 -0400
>> 
>> When people badger me, I do not give them what they want.
>
> When my enemies badger me, I do not give them what they want, and
> the more they badger me, the more steadfastly I resist.

Which means that you can be manipulated by them.  Indifference might
be a more prudent goal.

> But we are not your enemies, and this is not a conspiracy to badger
> you.  It just happened that quite a few of us disagree with your
> ideas of what should and what shouldn't go in so close to the
> release.

Another problem is that there are no guidelines to follow.  At the
moment, Richard is pretty much the only person who has an idea about
where a particular patch should end up, if at all.  Given the number
of Emacs developers, this situation would already constitute a
bottleneck even if he did not have so many other things to do than
work on Emacs.

> Please, let us get back to proportions and treat a disagreement as
> just that.

It is not like it would be the first time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Richard Stallman]

    But we are not your enemies, and this is not a conspiracy to badger
    you.  It just happened that quite a few of us disagree with your ideas

And some of them have been badgering me to do things their way.  I don't
want to participate in discussions with that feel to them.

Re: Reordering etc/NEWS

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     But we are not your enemies, and this is not a conspiracy to
>     badger you.  It just happened that quite a few of us disagree
>     with your ideas
>
> And some of them have been badgering me to do things their way.  I don't
> want to participate in discussions with that feel to them.

Richard, you are still the maintainer and policy setter.  Whether you
feel badgered, angry, disappointed or whatever does not change the
fact that badgers and nice guys alike are unable to do any work on
Emacs unless you _tell_ people what the CVS branches are supposed to
be used for.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     But we are not your enemies, and this is not a conspiracy to badger
>     you.  It just happened that quite a few of us disagree with your ideas
>
> And some of them have been badgering me to do things their way.  I don't
> want to participate in discussions with that feel to them.

I don't know if you feel that _I_ have been badgering you, but that
has never been my intention -- my only concern has been for the best
of the project.

You obviously have very specific ideas and principles on how to "make
progress towards" a release -- but it is also a fact (IMO) that those
ideas are not efficient in terms of actually "making" a release.

In my professional work, I have a lot of experience with making
releases actually happen -- at regular and _planned_ intervals, as
well as making interrim (often customer specific) releases of big and
complex software.  So I know that _my_ principles works!

I don't understand why you take it as a personal offence to even
question or discuss your principles.  AFAICS, most people on the team
agree that they have failed miserably.  Ok, we are very close to a
release now, but it's been 6 years since the last major release.

The problem with your principles is not only the (forever delayed)
release as such, but just as much the implied "feature freeze" which
is really blocking a lot of new development on the project.

The current feature freeze has now lasted for more than 3 years,
during which Emacs _development_ has practically been at a
stand-still, so it is no wonder your team of _loyal_ developers is
getting frustrated and starts to question your principles, and
may start looking for other (more productive) projects to work on.

That -- and only that -- is my concern.  

Whether you then feel offended or badgered by my concerns and the ways
I have expressed them (I admit to have been exaggerating at times due
to my growing frustration) is your choice.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Reordering etc/NEWS

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     But we are not your enemies, and this is not a conspiracy to
>>     badger you.  It just happened that quite a few of us disagree
>>     with your ideas
>>
>> And some of them have been badgering me to do things their way.  I
>> don't want to participate in discussions with that feel to them.
>
> I don't know if you feel that _I_ have been badgering you, but that
> has never been my intention -- my only concern has been for the best
> of the project.
>
> You obviously have very specific ideas and principles on how to
> "make progress towards" a release -- but it is also a fact (IMO)
> that those ideas are not efficient in terms of actually "making" a
> release.

The suitability depends on what one wants to release.  For GPLv3, it
is quite appropriate to take all the time it takes for the finishing
touches.

But Emacs is not a work to be _finished_, it is a work to be
continued.  And the continuation has been blocked for years by the
release.  At the current point of time we have reached the state where
nobody knows what the HEAD and release branches are supposed to be
for, respectively.

The situation has been bad for development for years.  Right now it is
catastrophic for _any_ work since there is no place in CVS which is
designated for work of any particular kind.

Creating additional branches unnecessarily to get any work done causes
additional merge burdens later.  And there is no sense in having
proliferating branches because the project maintainer refuses to get
"badgered" into telling people what the policy concerning the branches
is supposed to be.  Creating desperation branches is no solution,
since the merge decision still depends on an active statement of
policy.

I don't get it.  Most of the developers on this list have invested
large amounts of time and energy into making Emacs as great as it is.
Considering them enemies does not make sense, and it makes even less
sense to stop _every_ developer in his track as a sort of collective
punitive measure.

We need to know what kind of work can commence on HEAD and the release
branch, because some of that work requires a concerted effort (like
the multitty merge) of several people.

-- 
David Kastrup

Re: Reordering etc/NEWS

[JD Smith]

I can offer the perspective of a minor (very minor) contributor to
Emacs.  When I was a student, I found some (to me) real deficiencies
in the way colored annotation for CVS and the VC back end worked.  I
learned a bit of lisp, applied some basic color scaling theory, and
produced a patch which added great new functionality.  I got in touch
with the VC maintainers, who were enthusiastic, and, after some
tweaking, they added my code into Emacs.  Total success!

Or so it would seem.  That was Summer, 2001.  Six years later, and the
fruits of my early toil still aren't available in any released version
of Emacs.  So, while I continue to maintain a personally relevant
programming mode, and contribute bug fixes where they impact that
mode, I have not taken on any other "feature improvements" to Emacs.
To me, the value equation just doesn't compute.

>From my perspective, Emacs is an ancient, deeply rooted culture, with
its own customs and beliefs, established long ago.  I am an outsider
by almost any definition of the term.  That I do not feel justified in
challenging these customs does not change the fact that the long and
inscrutable release cycle has dampened my interest in contributing.

-- 
JD Smith

Re: Reordering etc/NEWS

[Eli Zaretskii]

> From: JD Smith <jdsmith@as.arizona.edu>
> Date: Wed, 09 May 2007 10:54:26 -0700
> 
> >From my perspective, Emacs is an ancient, deeply rooted culture, with
> its own customs and beliefs, established long ago.

I'm not sure what ancient culture and customs you refer to here, since
you've left them unnamed and unexplained.

If you are talking about long release cycles, then I'm all for making
them shorter, but please, even under the most optimal setup, don't
expect them to match those of other packages, even large ones, like
GDB.  Emacs is an extremely large package, whose humongous code cannot
be mastered by a single individual, or even a small group of core
developers.  Even if we confine ourselves only to the C code, Emacs
developers need to be experts in many diverse areas, such as Lisp
language, character sets and encodings, display, GUI toolkits (5 for
Unix plus 4 more for non-Unix platforms), signals and subprocesses,
and some intricate details of executable image structure (for unexec).
Lisp code is spread over more than 1000 files and covers even more
subject-matter ground.  I'm not familiar with any other GNU package
that could match Emacs in complexity and expertise requirements in so
many diverse fields.

So releasing such a large package will always need longer pretest than
most other software.  Especially since Emacs is maintained by
volunteers that come and go.

Re: Reordering etc/NEWS

[JD Smith]

On Wed, 09 May 2007 22:42:34 +0300, Eli Zaretskii wrote:

> I'm not sure what ancient culture and customs you refer to here,
> since you've left them unnamed and unexplained.

Only because I don't know in detail what all the customs are, only
that they exist and are entrenched (similar to how you might perceive
a foreign culture from the outside).

> Even if we confine ourselves only to the C code, Emacs developers
> need to be experts in many diverse areas, such as Lisp language,
> character sets and encodings, display, GUI toolkits (5 for Unix plus
> 4 more for non-Unix platforms), signals and subprocesses, and some
> intricate details of executable image structure (for unexec). Lisp
> code is spread over more than 1000 files and covers even more
> subject-matter ground.  I'm not familiar with any other GNU package
> that could match Emacs in complexity and expertise requirements in
> so many diverse fields.

Absolutely.  On the other hand, I'm certainly not an expert in most of
those things, yet I was able to productively improve features that
needed some attention.  This might indicate, then, that part of the
problem is an insistence on a monolithic release, vs. separating out
core and non-core functionality, with different release cycles.

Anyway, I didn't intend to offer opinion on how to run things, but
simply a single "case study" of the impact of the current setup on a
peripheral developer.

Re: Reordering etc/NEWS

[Stefan Monnier]

> tweaking, they added my code into Emacs.  Total success!
> Or so it would seem.  That was Summer, 2001.  Six years later, and the
> fruits of my early toil still aren't available in any released version
> of Emacs.  So, while I continue to maintain a personally relevant

I can feel your pain.  And I do believe it can be improved.
As we've seen with the unicode branch, automatic merging of changes from one
branch to another (using Arch plus some script plus Miles) does not have to
be painful, so we can cheaply keep several branches on which work is
being done.

I believe that the EMACS_22_BASE branch (after the release) should be
considered as "open for simple changes" rather than "open for bug-fixes
only", so that Emacs-22.2 and subsequent minor releases can include external
contributions, especially in the form of new packages.

If you look at the Emacs-19 set of releases, you'll see that in the past
there were much more frequent "new features".  In contrast, I believe that
the Emacs-21 set of releases where very few new features were included
between 21.1 and 21.4 was a mistake (in retrospect).  Even if Emacs-23 can
be done "quickly", we should still let Emacs-22 progress during this time.


        Stefan

Re: Reordering etc/NEWS

[Nick Roberts]

 > > tweaking, they added my code into Emacs.  Total success!
 > > Or so it would seem.  That was Summer, 2001.  Six years later, and the
 > > fruits of my early toil still aren't available in any released version
 > > of Emacs.  So, while I continue to maintain a personally relevant
 > 
 > I can feel your pain.  And I do believe it can be improved.

I don't see how it can.  It just appears to be a matter of belief rather than
of procedure.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Reordering etc/NEWS

[Richard Stallman]

I wish we had had an Emacs 22 release 3 years ago.  Those three years
of delay are quite unfortunate.  However, let's not make too much fuss
over the past months during which we have been coming closer to a
release.

Re: Reordering etc/NEWS

[Karl Fogel]

storm@cua.dk (Kim F. Storm) writes:
> The problem with your principles is not only the (forever delayed)
> release as such, but just as much the implied "feature freeze" which
> is really blocking a lot of new development on the project.
>
> The current feature freeze has now lasted for more than 3 years,
> during which Emacs _development_ has practically been at a
> stand-still, so it is no wonder your team of _loyal_ developers is
> getting frustrated and starts to question your principles, and
> may start looking for other (more productive) projects to work on.

What Kim said.

I don't get excited about making improvements to Emacs these days,
because I know I won't be able to check them in.  So I make fewer of
them.

Again, I don't see any reason, in Emacs or any project, why there
should be no place to check in bleeding-edge development changes.
There is no technical reason why a release (or N simultaneous
releases, for that matter) should impede new development work.  The
current state of affairs means that we are using our version control
system poorly, or that we're making incorrect assumptions about the
fungibility of volunteer developers' time (e.g., the false assumption
that if someone is unable to work on new code, they'll just take that
time and devote it to release work instead, which is obviously not
true).

This isn't meant as badgering, or as a personal attack.  But I see a
number of developers wishing we could have the same non-obstructive
release process as other software projects... yet so far I've only
seen two people (RMS and, sort of, Stefan Monnier) defend our current
system, and the defenses have not really addressed the issues raised
above.  Maybe I've missed a few posts, but it seems pretty clear that
a majority of developers would like to work in a different way.

One possible response to this is: Emacs is not a democracy! :-)

Okay, fine, but even in a dictatorship our release system can still be
broken.  I think it is, and I've described why above, concretely.  The
project doesn't have to be a democracy, but it does need to function.

Why are we blocking new changes?  Why not (say) have an open trunk,
and use a release branch to isolate the release from churn, like other
projects do?

-Karl

Re: Reordering etc/NEWS

[David Kastrup]

Karl Fogel <kfogel@red-bean.com> writes:

> Why are we blocking new changes?  Why not (say) have an open trunk,
> and use a release branch to isolate the release from churn, like
> other projects do?

The one posting you have missed of importance is the one where Richard
asked for volunteers that would consider taking over maintenance of
Emacs once the release is out of the door.  I have no idea what list
of candidates, if any, has resulted from that.  I also have no idea
what candidates might have been struck from the list as the result of
their way of voicing their concerns about the current process.  I
certainly hope the list is not empty.

Richard has just announced that he plans on releasing Emacs 22.1 from
the EMACS_BASE_22 branch.  It is not clear to me what should right now
happen on the trunk, though: should the branch merges of multitty and
emacs-unicode-2 commence now, or later?

Maybe Richard wants to leave the decision to whoever is going to end
up as the maintainer of Emacs 23.  And leave that decision until after
22.1 is released.

I have seen that he is quite busy with travel and talk in Europe in
the next few weeks.  When I have a schedule like that, I know that I
don't get pretty much any of the work done I plan to do alongside.  In
the light of that, I would consider it beneficial if Richard took a
path before departure where we are not stalled waiting for him.  This
could either mean deciding what kind of merges may happen to what
branch, or appointing someone to make these kind of decisions at least
for some time.  Whether or not he wants to let the release of 22.1
rest with somebody else is a different question.  There is probably
not much sense in that, since most candidates would probably just take
EMACS_BASE_22 and just release it as-is.  So he could, instead of
passing the buck, equally well do this himself.

I certainly hope that we can soon get to a state where work on Emacs
23 can commence, and also that we get to see a release soon.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Karl Fogel]

David Kastrup <dak@gnu.org> writes:
> The one posting you have missed of importance is the one where Richard
> asked for volunteers that would consider taking over maintenance of
> Emacs once the release is out of the door.  I have no idea what list
> of candidates, if any, has resulted from that.  I also have no idea
> what candidates might have been struck from the list as the result of
> their way of voicing their concerns about the current process.  I
> certainly hope the list is not empty.

Thanks; sorry I missed that one, and I can see how it might make a
difference (although it's worth questioning the need to have a single
maintainer at all -- many projects don't, and do just fine).

> Richard has just announced that he plans on releasing Emacs 22.1 from
> the EMACS_BASE_22 branch.  It is not clear to me what should right now
> happen on the trunk, though: should the branch merges of multitty and
> emacs-unicode-2 commence now, or later?

I think merges of complex development branches can be handled
incrementally by using bidirectional merging:

   1) Repeatedly merge trunk into the branch, so the branch isn't
      generally much out-of-date (w.r.t. recent trunk changes).

   2) Get some developers to agree to run the branch for a while, to
      test for obvious showstoppers.

   3) One day, when the new work on the branch is done, merge it into
      trunk.  It'll already contain everything trunk contains, so the
      only new material will be the branch work, and that will be
      well-tested.

IOW, trunk always gets new changes, except when they might destabilize
trunk to the point of unusability, in which case a branch is used
temporarily to stabilize them -- after which they go to trunk.

So regarding your original question: what state of testedness are the
multitty and emacs-unicode-2 branches in, and how far out of date
w.r.t. trunk are they?

-Karl

Re: Reordering etc/NEWS

[David Kastrup]

Karl Fogel <kfogel@red-bean.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Richard has just announced that he plans on releasing Emacs 22.1
>> from the EMACS_BASE_22 branch.  It is not clear to me what should
>> right now happen on the trunk, though: should the branch merges of
>> multitty and emacs-unicode-2 commence now, or later?
>
> I think merges of complex development branches can be handled
> incrementally by using bidirectional merging:
>
>    1) Repeatedly merge trunk into the branch, so the branch isn't
>       generally much out-of-date (w.r.t. recent trunk changes).
>
>    2) Get some developers to agree to run the branch for a while, to
>       test for obvious showstoppers.
>
>    3) One day, when the new work on the branch is done, merge it into
>       trunk.  It'll already contain everything trunk contains, so the
>       only new material will be the branch work, and that will be
>       well-tested.
>
> IOW, trunk always gets new changes, except when they might
> destabilize trunk to the point of unusability, in which case a
> branch is used temporarily to stabilize them -- after which they go
> to trunk.
>
> So regarding your original question: what state of testedness are
> the multitty and emacs-unicode-2 branches in, and how far out of
> date w.r.t. trunk are they?

They are basically synched to within a few weeks at most, and have
been used in production use partly for years and kept synched over all
that time.

That is the situation as I understand it.  The main concern is that we
have _two_ branches to merge, so there might be conflicts.  According
to the maintainers of the branches, those should be rather confined.
If one wanted to push one's luck, one could say that a first Emacs
23.1 prerelease should be possible a month after the serious work on
the branch merges commences.

Those branches have been slated for Emacs 23.1 _exactly_ because they
are in good state.  Other branches, like Emacs-bidi, don't appear
viable for a fast release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Karl Fogel]

David Kastrup <dak@gnu.org> writes:
> That is the situation as I understand it.  The main concern is that we
> have _two_ branches to merge, so there might be conflicts.  According
> to the maintainers of the branches, those should be rather confined.
> If one wanted to push one's luck, one could say that a first Emacs
> 23.1 prerelease should be possible a month after the serious work on
> the branch merges commences.

The question of whether the two branches will cause conflicts when
both merged into trunk does not need to be a mystery: we can try it
and see what happens :-).  I don't mean try it on trunk, I mean try it
out in a sandbox -- either in a working copy of one of the branches,
or in a third branch created just for this purpose.

Of course, there could be unexpected interactions that don't manifest
themselves as conflicts.  But if the two branches and trunk are
combined in a third branch that some people then run, such
interactions can be uncovered before they go into trunk.

Apologies if all this is clear to you already; I thought it might help
to say it explicitly, for those who hadn't thought much about the
problem yet.

-Karl

Re: Reordering etc/NEWS

[Jason Rumney]

David Kastrup wrote:
> If one wanted to push one's luck, one could say that a first Emacs
> 23.1 prerelease should be possible a month after the serious work on
> the branch merges commences.
>   

That is extremely optimistic. Has anyone even tried the multitty branch 
on Mac and Windows yet? I know there is still significant work required 
for emacs-unicode-2 on Windows, though it at least basically works.

Re: Reordering etc/NEWS

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> If one wanted to push one's luck, one could say that a first Emacs
>> 23.1 prerelease should be possible a month after the serious work on
>> the branch merges commences.
>>   
>
> That is extremely optimistic.

That's what "push one's luck" means.

> Has anyone even tried the multitty branch on Mac and Windows yet? I
> know there is still significant work required for emacs-unicode-2 on
> Windows, though it at least basically works.

The more reason to get started soon.

-- 
David Kastrup

Re: Reordering etc/NEWS

[joakim]

David Kastrup <dak@gnu.org> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> David Kastrup wrote:
>>> If one wanted to push one's luck, one could say that a first Emacs
>>> 23.1 prerelease should be possible a month after the serious work on
>>> the branch merges commences.
>>>   
>>
>> That is extremely optimistic.
>
> That's what "push one's luck" means.
>
>> Has anyone even tried the multitty branch on Mac and Windows yet? I
>> know there is still significant work required for emacs-unicode-2 on
>> Windows, though it at least basically works.
>
> The more reason to get started soon.

I use those branches and would be willing to test a merged version on
gnu+linux and w32. I could possibly dig out more machines with
different os:es as well if it would be any help.

>
> -- 
> David Kastrup

-- 
Joakim Verona

Re: Reordering etc/NEWS

[Jason Rumney]

joakim@verona.se wrote:
> I use those branches and would be willing to test a merged version on
> gnu+linux and w32. I could possibly dig out more machines with
> different os:es as well if it would be any help.
>   
If the multitty branch works on w32 already, then that gives me a lot 
more confidence.

My main concern was that it had never been tried to my knowledge, and 
due to the nature of the changes, there probably is work to do on w32 
just to get Emacs to compile if all the work so far has focused on  tty 
and X usage. The problem is that this work has gone on outside the 
normal emacs development community, so information of this sort is hard 
to come by. Another concern would be whether we have papers for everyone 
who has contributed to this branch.

Re: Reordering etc/NEWS

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Another concern would be whether we have papers for everyone who has
> contributed to this branch.

Wasn't it basically just Károly?  I would have considered it a
precondition to working on a branch in Emacs CVS, but of course
multitty is not yet in Emacs CVS.

-- 
David Kastrup

Re: Reordering etc/NEWS

[joakim]

Jason Rumney <jasonr@gnu.org> writes:

> joakim@verona.se wrote:
>> I use those branches and would be willing to test a merged version on
>> gnu+linux and w32. I could possibly dig out more machines with
>> different os:es as well if it would be any help.
>>   
> If the multitty branch works on w32 already, then that gives me a lot
> more confidence.

I dont know. I have only tested mtty on gnu+linux. mtty doesnt have
any value on w32 as far as I can imagine, so I usually just use
Lennart Borgmans w32 emacs package.

I can try to compile on w32.

> My main concern was that it had never been tried to my knowledge, and
> due to the nature of the changes, there probably is work to do on w32
> just to get Emacs to compile if all the work so far has focused on
> tty and X usage. The problem is that this work has gone on outside the
> normal emacs development community, so information of this sort is
> hard to come by. Another concern would be whether we have papers for
> everyone who has contributed to this branch.

-- 
Joakim Verona

Re: Reordering etc/NEWS

[David Kastrup]

joakim@verona.se writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> joakim@verona.se wrote:
>>> I use those branches and would be willing to test a merged version on
>>> gnu+linux and w32. I could possibly dig out more machines with
>>> different os:es as well if it would be any help.
>>>   
>> If the multitty branch works on w32 already, then that gives me a lot
>> more confidence.
>
> I dont know. I have only tested mtty on gnu+linux. mtty doesnt have
> any value on w32 as far as I can imagine, so I usually just use
> Lennart Borgmans w32 emacs package.

Why wouldn't it have value?  It allows one to keep an existing Emacs
session around into which one can connect remotely via ssh+emacsclient
in order to do work.  At least once emacsclient has been extended with
a -nw (--no-window-system) option in order to open a frame on the
emacsclient tty.

It should also allow keeping an Emacs server session around (not just
iconified, but actually frameless) that one can plug into using
emacsclient again, and have it open a fresh frame.

> I can try to compile on w32.

-- 
David Kastrup

Re: Reordering etc/NEWS

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> joakim@verona.se writes:
>
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>> joakim@verona.se wrote:
>>>> I use those branches and would be willing to test a merged version on
>>>> gnu+linux and w32. I could possibly dig out more machines with
>>>> different os:es as well if it would be any help.
>>>>   
>>> If the multitty branch works on w32 already, then that gives me a lot
>>> more confidence.
>>
>> I dont know. I have only tested mtty on gnu+linux. mtty doesnt have
>> any value on w32 as far as I can imagine, so I usually just use
>> Lennart Borgmans w32 emacs package.
>
> Why wouldn't it have value?  It allows one to keep an existing Emacs
> session around into which one can connect remotely via ssh+emacsclient
> in order to do work.  At least once emacsclient has been extended with
> a -nw (--no-window-system) option in order to open a frame on the
> emacsclient tty.

One additional possibility: with a sufficient level of craziness, you
might at one point of time link X libraries into Windows executables.
Then it would be possible to connect into an Emacs session running on
a Windows system from a system with an X server (either Windows with
an additional X server, or a posixy system), and have an X frame open
on that system.

> It should also allow keeping an Emacs server session around (not just
> iconified, but actually frameless) that one can plug into using
> emacsclient again, and have it open a fresh frame.

[on Windows].

-- 
David Kastrup

Re: Reordering etc/NEWS

[Karoly Lorentey]

David Kastrup wrote:
> David Kastrup <dak@gnu.org> writes:
>> joakim@verona.se writes:
>>> I dont know. I have only tested mtty on gnu+linux. mtty doesnt have
>>> any value on w32 as far as I can imagine, so I usually just use
>>> Lennart Borgmans w32 emacs package.
>> Why wouldn't it have value?  It allows one to keep an existing Emacs
>> session around into which one can connect remotely via ssh+emacsclient
>> in order to do work.  At least once emacsclient has been extended with
>> a -nw (--no-window-system) option in order to open a frame on the
>> emacsclient tty.

Ah, that is good news.  If the the Windows port has UN*X-like tty
support, then multi-tty can easily support the use case you describe.
This will still not involve significantly more porting work than simply
fixing the compilation.

> One additional possibility: with a sufficient level of craziness, you
> might at one point of time link X libraries into Windows executables.
> Then it would be possible to connect into an Emacs session running on
> a Windows system from a system with an X server (either Windows with
> an additional X server, or a posixy system), and have an X frame open
> on that system.

This would be a very desirable feature, but it needs more work; even the
multi-tty branch doesn't support having multiple kinds of graphical
terminals compiled in at once.

>> It should also allow keeping an Emacs server session around (not just
>> iconified, but actually frameless) that one can plug into using
>> emacsclient again, and have it open a fresh frame.

I intentionally left implementing frameless Emacs sessions after the
merge, to let us discuss this proposed feature extensively on
emacs-devel.  I think we need to make non-trivial design decisions.
(Where do messages go when there are no frames?  How to recover when
someone accidentally calls server-stop?)

Currently people usually run multi-tty Emacs in a detached screen
session that they never connect to.  There are simple scripts to manage
this.  Screen provides the analogue of a console where you go to check
*Messages* or restart the server when there is trouble.

-- 
Karoly

Re: Reordering etc/NEWS

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>> David Kastrup <dak@gnu.org> writes:
>>> joakim@verona.se writes:
>>>> I dont know. I have only tested mtty on gnu+linux. mtty doesnt have
>>>> any value on w32 as far as I can imagine, so I usually just use
>>>> Lennart Borgmans w32 emacs package.
>>> Why wouldn't it have value?  It allows one to keep an existing Emacs
>>> session around into which one can connect remotely via ssh+emacsclient
>>> in order to do work.  At least once emacsclient has been extended with
>>> a -nw (--no-window-system) option in order to open a frame on the
>>> emacsclient tty.
>
> Ah, that is good news.  If the the Windows port has UN*X-like tty
> support, then multi-tty can easily support the use case you describe.
> This will still not involve significantly more porting work than simply
> fixing the compilation.
>
>> One additional possibility: with a sufficient level of craziness, you
>> might at one point of time link X libraries into Windows executables.
>> Then it would be possible to connect into an Emacs session running on
>> a Windows system from a system with an X server (either Windows with
>> an additional X server, or a posixy system), and have an X frame open
>> on that system.
>
> This would be a very desirable feature, but it needs more work; even the
> multi-tty branch doesn't support having multiple kinds of graphical
> terminals compiled in at once.

Well, the _proper_ multiplatform way of things would be to extend
emacsclient with a display engine.  Then only system-independent data
would need to cross between emacs and emacsclient, and it would not be
a problem to open a Carbon emacsclient connecting to a Windows
emacsserver.

Complete independency is probably illusionary.  gnuclient opens its
own frame in a tty (I don't think emacsclient has this sort of
operation).  I would guess that it passes the terminal geometry and
TERM variables through the socket and basically lets Emacs talk to the
tty through its socket, shutting down when Emacs tells it.

Anybody familiar with gnuclient around?  How much of the
termcap/terminfo stuff is handled at the gnuclient side?

Anyway, the approach "pass everything necessary to let the work be
done at the application side" _is_ that of X11: pass the contact data
for an application agnostic display engine (called an X server) and
let the application do the rest.

> I intentionally left implementing frameless Emacs sessions after the
> merge, to let us discuss this proposed feature extensively on
> emacs-devel.  I think we need to make non-trivial design decisions.
> (Where do messages go when there are no frames?

In the *Message* buffer, obviously.

> How to recover when someone accidentally calls server-stop?)

Similar to someone "accidentally" calling kill-emacs.

> Currently people usually run multi-tty Emacs in a detached screen
> session that they never connect to.  There are simple scripts to
> manage this.  Screen provides the analogue of a console where you go
> to check *Messages* or restart the server when there is trouble.

When there is trouble with a server, one sends it a signal manually.
I don't see that there are too many things around which require code
rather than decisions.  It is not our task to prevent people shooting
themselves in the foot if they really want to.  We should not make it
trivially easy to trigger an accident by default, but that's about it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Multi-tty design (Re: Reordering etc/NEWS)

[Károly Lo"rentey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Kastrup wrote:
> Well, the _proper_ multiplatform way of things would be to extend
> emacsclient with a display engine.  Then only system-independent data
> would need to cross between emacs and emacsclient, and it would not be
> a problem to open a Carbon emacsclient connecting to a Windows
> emacsserver.

Yeah, that would be great.  However, implementing a "properly"
device-independent client-server model was never the purpose of the
multi-tty branch.

> Complete independency is probably illusionary.  gnuclient opens its
> own frame in a tty (I don't think emacsclient has this sort of
> operation).  I would guess that it passes the terminal geometry and
> TERM variables through the socket and basically lets Emacs talk to the
> tty through its socket, shutting down when Emacs tells it.

Currently Emacs simply opens the controlling tty of emacsclient
directly.  Environment variables are frame-local and are passed from
emacsclient to Emacs before the first frame is created.  Signals such as
SIGWINCH, SIGTSTP, SIGTTOU and SIGCONT are handled and forwarded to
Emacs in a sensible way.  Emacs does most of the tty-related work,
emacsclient simply stands out of the way.

Previously, there was a stage when emacsclient created a screen-like
proxy pseudo-tty and had Emacs open that.  The added complexity really
did not win us anything important (apart from having "su otheruser
emacsclient" work).

Using the emacsclient socket to transmit tty data is an intriguing idea,
but it would mean duplicating the hairy tcsetattr/ioctl/curses/whatever
magic of Emacs inside emacsclient without a clear and immediate benefit.
 The current way of having Emacs handle these parts is the least
intrusive solution, so that's what I had to implement.  Once basic
multi-tty functionality is on the trunk, we can extend it in any exotic
way we want.

>> I intentionally left implementing frameless Emacs sessions after the
>> merge, to let us discuss this proposed feature extensively on
>> emacs-devel.  I think we need to make non-trivial design decisions.
>> (Where do messages go when there are no frames?
> 
> In the *Message* buffer, obviously.

>> How to recover when someone accidentally calls server-stop?)
> 
> Similar to someone "accidentally" calling kill-emacs.

So if the server stops, Emacs exits.  OK.

> When there is trouble with a server, one sends it a signal manually.
> I don't see that there are too many things around which require code
> rather than decisions.

I can't understand this last sentence.

My point is that allowing frameless Emacs instances is not hard to
implement, but it is a non-essential feature and I judged it is better
deferred after the merge.

(Technically, a frameless Emacs would still have one frame with a dummy
display device.  Emacs relies on always having a current frame too
strongly.)

> It is not our task to prevent people shooting
> themselves in the foot if they really want to.  We should not make it
> trivially easy to trigger an accident by default, but that's about it.

That's fine.

- --
Karoly
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGRa6N6eoyqA+yej8RAp8bAJ4gtSD4Al+5OmObkoYbogc4AYrHSACfY20x
aXqE2VWRE/E28+8QqXQOoiE=
=6wrs
-----END PGP SIGNATURE-----

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

"Károly Lőrentey" <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>> Well, the _proper_ multiplatform way of things would be to extend
>> emacsclient with a display engine.  Then only system-independent data
>> would need to cross between emacs and emacsclient, and it would not be
>> a problem to open a Carbon emacsclient connecting to a Windows
>> emacsserver.
>
> Yeah, that would be great.  However, implementing a "properly"
> device-independent client-server model was never the purpose of the
> multi-tty branch.
>
>> Complete independency is probably illusionary.  gnuclient opens its
>> own frame in a tty (I don't think emacsclient has this sort of
>> operation).  I would guess that it passes the terminal geometry and
>> TERM variables through the socket and basically lets Emacs talk to the
>> tty through its socket, shutting down when Emacs tells it.
>
> Currently Emacs simply opens the controlling tty of emacsclient
> directly.

How would this work over a modem link?

> Environment variables are frame-local and are passed from
> emacsclient to Emacs before the first frame is created.

All of them?  Things like PATH, too?

> Signals such as SIGWINCH, SIGTSTP, SIGTTOU and SIGCONT are handled
> and forwarded to Emacs in a sensible way.  Emacs does most of the
> tty-related work, emacsclient simply stands out of the way.

Which is pretty much the situation with X11, too.

> Previously, there was a stage when emacsclient created a screen-like
> proxy pseudo-tty and had Emacs open that.  The added complexity
> really did not win us anything important (apart from having "su
> otheruser emacsclient" work).

Ok.  I think we should discuss details once multitty is available via
Savannah.

>>> How to recover when someone accidentally calls server-stop?)
>> 
>> Similar to someone "accidentally" calling kill-emacs.
>
> So if the server stops, Emacs exits.  OK.

If there is no way to contact Emacs anymore, that would seem like a
sensible default once Emacs is idling.

>> When there is trouble with a server, one sends it a signal
>> manually.  I don't see that there are too many things around which
>> require code rather than decisions.
>
> I can't understand this last sentence.

I mean that it appears that most problems can probably be tackled
mostly by documenting the bahavior rather than writing complex code.

> My point is that allowing frameless Emacs instances is not hard to
> implement, but it is a non-essential feature and I judged it is
> better deferred after the merge.

Sure.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

David Kastrup wrote:
> "Károly Lőrentey" <karoly@lorentey.hu> writes:
>> Currently Emacs simply opens the controlling tty of emacsclient
>> directly.
> 
> How would this work over a modem link?

I haven't seen a raw modem link or serial tty in years, but if
/dev/ttyS* is not openable by an independent process of the user, then
emacsclient will fail.  If necessary, we could still make it work by
passing the inherited descriptor to the emacs process using
I_SENDFD/sendmsg/whatever.  I understand that's a messy area of UNIX.

The lazy solution would be to simply add a paragraph to etc/PROBLEMS
suggesting that in these cases the user work inside screen and invoke
emacsclient from there.

Of course, ptys such as those created by SSH, xterm or screen work fine.
 I believe having a working solution for those should be our primary
concern today.

>> Environment variables are frame-local and are passed from
>> emacsclient to Emacs before the first frame is created.
> 
> All of them?  Things like PATH, too?

Yes.  The use case I tried to optimize for is that of a user invoking
emacsclient as a drop-in replacement for emacs.  Processes started from
the emacsclient session should inherit the environment of the client
process.  If the user extends PATH before invoking emacsclient, this
should (if at all possible) be visible from the emacsclient session.

The process-environment variable still overrides all frame-local
environments, so existing code setting variables by binding
process-environment will still work.

In fact, the only incompatible change in the multi-tty branch that I
know of is that `process-environment' is nil by default.  To enumerate
all environment variables, one needs to call a new function; simply
looking at process-environment does not work.

>> Signals such as SIGWINCH, SIGTSTP, SIGTTOU and SIGCONT are handled
>> and forwarded to Emacs in a sensible way.  Emacs does most of the
>> tty-related work, emacsclient simply stands out of the way.
> 
> Which is pretty much the situation with X11, too.

Exactly.

-- 
Karoly

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>> "Károly Lőrentey" <karoly@lorentey.hu> writes:
>
>>> Environment variables are frame-local and are passed from
>>> emacsclient to Emacs before the first frame is created.
>> 
>> All of them?  Things like PATH, too?
>
> Yes.  The use case I tried to optimize for is that of a user
> invoking emacsclient as a drop-in replacement for emacs.  Processes
> started from the emacsclient session should inherit the environment
> of the client process.

This does not sound like the right thing to do when emacsclient is
running on a different machine.  The PATH on this different machine
would be useless for calling processes on the machine that Emacs is
on.

But the time to shake out problems like that is after multi-tty is
available as a branch in Emacs CVS.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Károly Lőrentey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Kastrup wrote:
> Karoly Lorentey <karoly@lorentey.hu> writes:
>> Yes.  The use case I tried to optimize for is that of a user
>> invoking emacsclient as a drop-in replacement for emacs.  Processes
>> started from the emacsclient session should inherit the environment
>> of the client process.
> 
> This does not sound like the right thing to do when emacsclient is
> running on a different machine.  The PATH on this different machine
> would be useless for calling processes on the machine that Emacs is
> on.

How can Emacsclient run on a different machine than Emacs itself?  How
would that be useful?  Would that even be secure?

> But the time to shake out problems like that is after multi-tty is
> available as a branch in Emacs CVS.

Indeed.

- --
Karoly
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGRvHF6eoyqA+yej8RAohdAKC5pwAEKFklW83+aKYl117Xcx+IIwCdFLSp
ucS5YQhqX91s73ddyYBuTas=
=PoSy
-----END PGP SIGNATURE-----

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Károly Lőrentey <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>> Karoly Lorentey <karoly@lorentey.hu> writes:
>>> Yes.  The use case I tried to optimize for is that of a user
>>> invoking emacsclient as a drop-in replacement for emacs.  Processes
>>> started from the emacsclient session should inherit the environment
>>> of the client process.
>> 
>> This does not sound like the right thing to do when emacsclient is
>> running on a different machine.  The PATH on this different machine
>> would be useless for calling processes on the machine that Emacs is
>> on.
>
> How can Emacsclient run on a different machine than Emacs itself?
> How would that be useful?  Would that even be secure?

Hm, I was somewhat confused here since I was thinking about remote
operation of Emacs.  But one does this by first getting a terminal or
whatever else open on the current machine.  So this particular point
might indeed be nonsensical.

Let's get the branch into Savannah and I'll be able to work on my
confusion more thoroughly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Let's get the branch into Savannah and I'll be able to work on my
> confusion more thoroughly.

emacsclient -t does not work for me at all.  Emacs gets started from
the Gnome panel for me (so it likely has some weird or none-functional
controlling tty), and I try emacsclient -t in either an xterm or a
screen session inside of the xterm.

emacsclient -t /etc/fstab
just does nothing at all and quits.  In the screen session, the result
sometimes (but not always) is
*ERROR*: Cannot open termcap database file
before it quits.

Any ideas?  What would constitute a good bug report, and where should
it be sent preferably?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Let's get the branch into Savannah and I'll be able to work on my
>> confusion more thoroughly.
>
> emacsclient -t does not work for me at all.  Emacs gets started from
> the Gnome panel for me (so it likely has some weird or none-functional
> controlling tty), and I try emacsclient -t in either an xterm or a
> screen session inside of the xterm.
>
> emacsclient -t /etc/fstab
> just does nothing at all and quits.  In the screen session, the result
> sometimes (but not always) is
> *ERROR*: Cannot open termcap database file
> before it quits.

I cannot reproduce that here.  I tried running Emacs from KDE, and
emacsclient works as expected.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Let's get the branch into Savannah and I'll be able to work on my
>>> confusion more thoroughly.
>>
>> emacsclient -t does not work for me at all.  Emacs gets started from
>> the Gnome panel for me (so it likely has some weird or none-functional
>> controlling tty), and I try emacsclient -t in either an xterm or a
>> screen session inside of the xterm.
>>
>> emacsclient -t /etc/fstab
>> just does nothing at all and quits.  In the screen session, the result
>> sometimes (but not always) is
>> *ERROR*: Cannot open termcap database file
>> before it quits.
>
> I cannot reproduce that here.  I tried running Emacs from KDE, and
> emacsclient works as expected.

I have compiled with --with-gtk.  What toolkit are you using?
emacsclient --version indicates that I am using the right emacsclient.

Anyway, if I do a (setenv "PATH" something) in my main Emacs frame,
and then do an emacsclient in order to open another frame, then
(getenv "PATH") on the new frame returns the stuff from the main
frame.  So the frame-specific PATH stuff does not seem to work.  Part
of it may be the obvious blunder addressed by the appended patch.  But
I think the search orders of frame local variables and
process-environment are messed up.  Maybe process-environment should
instead be a terminal-local variable.  Maybe it is already.  No idea.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 764 bytes --]

*** env.el	13 May 2007 17:23:38 +0200	1.38.4.1
--- env.el	13 May 2007 19:08:47 +0200	
***************
*** 212,218 ****
    (let ((value (getenv-internal (if (multibyte-string-p variable)
  				    (encode-coding-string
  				     variable locale-coding-system)
! 				  variable))))
      (if (and enable-multibyte-characters value)
  	(setq value (decode-coding-string value locale-coding-system)))
      (when (interactive-p)
--- 212,219 ----
    (let ((value (getenv-internal (if (multibyte-string-p variable)
  				    (encode-coding-string
  				     variable locale-coding-system)
! 				  variable)
! 				frame)))
      (if (and enable-multibyte-characters value)
  	(setq value (decode-coding-string value locale-coding-system)))
      (when (interactive-p)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> I have compiled with --with-gtk.  What toolkit are you using?

I'm using the Athena toolkit.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I have compiled with --with-gtk.  What toolkit are you using?
>
> I'm using the Athena toolkit.

I can try seeing whether this makes a difference, though it would seem
weird for emacsclient -t.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Andreas Schwab <schwab@suse.de> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >> David Kastrup <dak@gnu.org> writes:
  > >>
  > >>> Let's get the branch into Savannah and I'll be able to work on my
  > >>> confusion more thoroughly.
  > >>
  > >> emacsclient -t does not work for me at all.  Emacs gets started from
  > >> the Gnome panel for me (so it likely has some weird or none-functional
  > >> controlling tty), and I try emacsclient -t in either an xterm or a
  > >> screen session inside of the xterm.
  > >>
  > >> emacsclient -t /etc/fstab
  > >> just does nothing at all and quits.  In the screen session, the result
  > >> sometimes (but not always) is
  > >> *ERROR*: Cannot open termcap database file
  > >> before it quits.
  > >
  > > I cannot reproduce that here.  I tried running Emacs from KDE, and
  > > emacsclient works as expected.
  > 
  > I have compiled with --with-gtk.  What toolkit are you using?
  > emacsclient --version indicates that I am using the right emacsclient.
  > 
  > Anyway, if I do a (setenv "PATH" something) in my main Emacs frame,
  > and then do an emacsclient in order to open another frame, then
  > (getenv "PATH") on the new frame returns the stuff from the main
  > frame.  So the frame-specific PATH stuff does not seem to work.  Part
  > of it may be the obvious blunder addressed by the appended patch.  But
  > I think the search orders of frame local variables and
  > process-environment are messed up.  Maybe process-environment should
  > instead be a terminal-local variable.  Maybe it is already.  No idea.

Can you please send a proper bug report starting from emacs -Q that
shows what exactly are you doing? Please include what system are you
using, what toolkit are you using, etc etc. 

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Can you please send a proper bug report starting from emacs -Q that
> shows what exactly are you doing? Please include what system are you
> using, what toolkit are you using, etc etc.

Looks like the effects on Athena and Gtk+ are similar.  However, at
least from emacs -Q (and using M-x server-start) I can get a tty
session to start with emacsclient.  I can't with my full session, so
I'll need to experiment around with the details.

Either way, even when using emacs -Q, a setenv of PATH to a different
value in the Emacs started from the GNOME taskbar will be visible in a
subsequently initiated emacsclient session, whether on the tty or
under X.

I'm not likely get through with checking what in my .emacs might be
interfering with emacsclient sessions starting up on the tty today.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>> Can you please send a proper bug report starting from emacs -Q that
>> shows what exactly are you doing? Please include what system are you
>> using, what toolkit are you using, etc etc.
>
> Looks like the effects on Athena and Gtk+ are similar.  However, at
> least from emacs -Q (and using M-x server-start) I can get a tty
> session to start with emacsclient.  I can't with my full session, so
> I'll need to experiment around with the details.
>
> Either way, even when using emacs -Q, a setenv of PATH to a different
> value in the Emacs started from the GNOME taskbar will be visible in a
> subsequently initiated emacsclient session, whether on the tty or
> under X.
>
> I'm not likely get through with checking what in my .emacs might be
> interfering with emacsclient sessions starting up on the tty today.

Ok, some more info: _if_ I start Emacs from the same tty as I later
start emacsclient -t, I can get a tty session.

If I use Alt-F2 to start Emacs directly from the window manager (which
in its turn gets started from gnome-session started from gdm's login
screen), emacsclient -t will not talk with it, _sometimes_ saying
*ERROR*: Cannot open termcap database file
but that is not consistent.  It does this perhaps once or twice in 10
tries.  It exits with exit state 0, though, in either case.

So it would seem that the Emacs started from the window manager is
missing something in order to make friends with the tty that
emacsclient -t is called from.

Any idea how to debug this?  Current Emacs settings are

GNU Emacs 23.0.51.1 (i686-pc-linux-gnu, GTK+ Version 2.10.11,
multi-tty) of 2007-05-13 on lola

and I have (possibly relevant) environment settings
SHELL=/bin/bash
GTK_RC_FILES=/etc/gtk/gtkrc:/home/dak/.gtkrc-1.2-gnome2
USERNAME=dak
SESSION_MANAGER=local/lola:/tmp/.ICE-unix/5904
DESKTOP_SESSION=default
GDM_XSERVER_LOCATION=local
PWD=/home/dak
LANG=en_US.UTF-8
GDM_LANG=en_US.UTF-8
GDMSESSION=default
SHLVL=1
LANGUAGE=en_US.UTF-8
GNOME_DESKTOP_SESSION_ID=Default
LOGNAME=dak
DISPLAY=:0.0
XAUTHORITY=/home/dak/.Xauthority
_=/usr/bin/env

in the GDM session Emacs, and
DESKTOP_STARTUP_ID=
SHELL=/bin/bash
TERM=screen
WINDOWID=41943133
USER=dak
TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\
	:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
	:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
	:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
	:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
	:li#24:co#80:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
	:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
	:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
	:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
	:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
	:se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\
	:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\
	:vb=\Eg:G0:as=\E(0:ae=\E(B:\
	:ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
	:po=\E[5i:pf=\E[4i:Z0=\E[?3h:Z1=\E[?3l:k0=\E[10~:\
	:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:\
	:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:\
	:F2=\E[24~:F3=\EO2P:F4=\EO2Q:F5=\EO2R:F6=\EO2S:\
	:F7=\E[15;2~:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:kb=\x7f:\
	:K2=\EOE:kB=\E[Z:*4=\E[3;2~:*7=\E[1;2F:#2=\E[1;2H:\
	:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:%i=\E[1;2C:\
	:kh=\E[1~:@1=\E[1~:kH=\E[4~:@7=\E[4~:kN=\E[6~:kP=\E[5~:\
	:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:km:
USERNAME=dak
SESSION_MANAGER=local/lola:/tmp/.ICE-unix/5904
DESKTOP_SESSION=default
STY=17353.pts-0.lola
GDM_XSERVER_LOCATION=local
LANG=en_US.UTF-8
GDM_LANG=en_US.UTF-8
GDMSESSION=default
SHLVL=2
LANGUAGE=en_US.UTF-8
GNOME_DESKTOP_SESSION_ID=Default
LOGNAME=dak
WINDOW=1
DISPLAY=:0.0
XAUTHORITY=/home/dak/.Xauthority
COLORTERM=gnome-terminal
_=/usr/bin/env


So one of the differences appears to be that the tty session has
TERMCAP information.

Add to this that I don't seem to have emacsclient passing the PATH
variable to the sessions it initiates, and it seems like the missing
individual environment from the text tty is causing my problems to
have emacsclient -t work.

It is curious that emacsclient will only sometimes complain but always
exit immediately.

Any ideas how to debug?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> So one of the differences appears to be that the tty session has
> TERMCAP information.

I get the following:

C-u M-: (environment) RET

("PATH=/usr/local/texlive/2005/bin/i386-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games"
"TERMINFO_DIRS" "TERMCAP" "NCURSES_NO_SETBUF" "NCURSES_ASSUMED_COLORS"
"HOME=/home/dak" "COLUMNS" "LC_ALL" "LANG=en_US.UTF-8"
"MAILHOST=fencepost.gnu.org"
"TEXINPUTS=.:/usr/local/emacs-21/share/emacs/site-lisp/preview/latex:"
"GNOME_DESKTOP_SESSION_ID=Default"
"GNOME_KEYRING_SOCKET=/tmp/keyring-ZprRPl/socket"
"SESSION_MANAGER=local/lola:/tmp/.ICE-unix/5904"
"GTK_RC_FILES=/etc/gtk/gtkrc:/home/dak/.gtkrc-1.2-gnome2"
"DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-c5o8W5Kz0G,guid=e768e7262a51bc0ce774130046386332"
"SSH_AGENT_PID=6226" "SSH_AUTH_SOCK=/tmp/ssh-uzAAcD5904/agent.5904"
"EDITOR=/usr/local/emacs-21/bin/emacsclient -n --alternate-editor vi"
"PWD=/home/dak" "TEXDOCVIEW_html=( firefox %s ) &"
"GS_OPTIONS=-sPAPERSIZE=a4 " "GDMSESSION=default" "SHELL=/bin/bash"
"TEXDOCVIEW_pdf=( xpdf %s ) &" "XAUTHORITY=/home/dak/.Xauthority"
"DISPLAY=:0.0" "GDM_LANG=en_US.UTF-8" "USERNAME=dak" "LOGNAME=dak"
"GDM_XSERVER_LOCATION=local"
"VISUAL=/usr/local/emacs-21/bin/emacsclient -n --alternate-editor vi"
"NEWSSERVER=news.t-online.de" "DESKTOP_SESSION=default"
"BROWSER=firefox" "USER=dak" "LANGUAGE=en_US.UTF-8" "CVS_RSH=ssh")

And in a Window initiated from emacsclient (no -t) very much the same
except for:
 "OLDPWD=/home/tmp/emacs" "_=/usr/local/emacs-21/bin/emacsclient"
 "COLORTERM=gnome-terminal" "WINDOW=1" "SHLVL=2" "PWD=/home/tmp"
 "STY=17353.pts-0.lola" "WINDOWID=41943133")

So the funny thing is that some environment variables appear to make
it through emacsclient, but the termcap related stuff doesn't.  And
the ones that make it are seemingly those which don't exist in the
other session (and it is very strange that some seem to exist as just
the environment variable names without "=" and a value).

Messy.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Giorgos Keramidas]

On 2007-05-13 23:11, David Kastrup <dak@gnu.org> wrote:
>David Kastrup <dak@gnu.org> writes:
>> So one of the differences appears to be that the tty session has
>> TERMCAP information.
>
> I get the following:
>
> C-u M-: (environment) RET
> [...]
>
> And in a Window initiated from emacsclient (no -t) very much the same
> except for:
>  "OLDPWD=/home/tmp/emacs" "_=/usr/local/emacs-21/bin/emacsclient"
>  "COLORTERM=gnome-terminal" "WINDOW=1" "SHLVL=2" "PWD=/home/tmp"
>  "STY=17353.pts-0.lola" "WINDOWID=41943133")
>
> So the funny thing is that some environment variables appear to make
> it through emacsclient, but the termcap related stuff doesn't.  And
> the ones that make it are seemingly those which don't exist in the
> other session (and it is very strange that some seem to exist as just
> the environment variable names without "=" and a value).

The emacsclient session of Emacs appears to be initiated in a screen(1)
window (by the presense of the "STY" environment variable).

I think screen unconditionally sets TERMCAP, and this was what used to
bite me some times, which eventually led me to add to my .bashrc file:

  case $TERM in
  screen*|vt220*)
      unset TERMCAP
      ;;
  esac

Can you try running emacsclient outside of screen?  Does it behave in
the same way then too?

- Giorgos

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > So one of the differences appears to be that the tty session has
  > TERMCAP information.

Most likely irrelevant, you are probably using terminfo if you are on
a GNU/Linux system. 

  > Add to this that I don't seem to have emacsclient passing the PATH
  > variable to the sessions it initiates, and it seems like the missing
  > individual environment from the text tty is causing my problems to
  > have emacsclient -t work.
  > 
  > It is curious that emacsclient will only sometimes complain but always
  > exit immediately.
  > 
  > Any ideas how to debug?

Try deleting everything in your .emacs that deals with frames, changes
frame parameters, etc. I'd guess that the make-frame-on-tty call in
server.el fails for some reason. 

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > So one of the differences appears to be that the tty session has
>   > TERMCAP information.
>
> Most likely irrelevant, you are probably using terminfo if you are on
> a GNU/Linux system. 
>
>   > Add to this that I don't seem to have emacsclient passing the PATH
>   > variable to the sessions it initiates, and it seems like the missing
>   > individual environment from the text tty is causing my problems to
>   > have emacsclient -t work.
>   > 
>   > It is curious that emacsclient will only sometimes complain but always
>   > exit immediately.
>   > 
>   > Any ideas how to debug?
>
> Try deleting everything in your .emacs that deals with frames, changes
> frame parameters, etc. I'd guess that the make-frame-on-tty call in
> server.el fails for some reason. 

emacs -Q, when started from the window manager via Alt-F2, exhibits
the same behavior.  So .emacs has nothing to do with it.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Can you please send a proper bug report starting from emacs -Q that
  > > shows what exactly are you doing? Please include what system are you
  > > using, what toolkit are you using, etc etc.
  > 
  > Looks like the effects on Athena and Gtk+ are similar.  However, at
  > least from emacs -Q (and using M-x server-start) I can get a tty
  > session to start with emacsclient.  I can't with my full session, so
  > I'll need to experiment around with the details.
  >
  > Either way, even when using emacs -Q, a setenv of PATH to a different
  > value in the Emacs started from the GNOME taskbar will be visible in a
  > subsequently initiated emacsclient session, whether on the tty or
  > under X.

Can you please explain what exactly are you trying to accomplish and
how are you trying to accomplish it?  

The main reason the environment variables are sent from emacsclient to
the server is to initialize the terminal correctly: you can have a
terminal frame in an xterm and at the same time one in a vt100
terminal and they both work as expected. Károly might correct me if I
am wrong, but I don't think PATH has been considered too much...

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

David Kastrup wrote:
> Either way, even when using emacs -Q, a setenv of PATH to a different
> value in the Emacs started from the GNOME taskbar will be visible in a
> subsequently initiated emacsclient session, whether on the tty or
> under X.

This may be a genuine regression, but I can't reproduce it here.  What
should happen instead is this:

	$ SNAFU=23 emacs -Q &
		M-x server-start
		(getenv "SNAFU")
		    ==> "23"
		(length (frame-parameter nil 'environment))
		    ==> 55

	$ emacsclient -t
		(getenv "SNAFU")
		    ==> nil
		(length (frame-parameter nil 'environment))
		    ==> 54


(PATH is not handled in any way specially.)  If emacsclient's variables
don't show up in the frame-local environment, then that explains why
emacsclient -t doesn't work when Emacs is started from your GNOME
session: TERM is unset.

This is such a basic feature that my first instinct is that something
might have gone wrong while the CVS branch was created.  Please verify
that you have started with a _clean_ checkout (no leftover *.elc, *.o)
and that the following four key files have the checksums shown below:

$ md5sum src/callproc.c lisp/env.el lisp/server.el lib-src/emacsclient.c
e6b3fc34d6e684433e96e648a8c00e21  src/callproc.c
53b084e43b550b6548fbfce0948bbcc2  lisp/env.el
c4e7d9d27cb90c029fe3de60333e8450  lisp/server.el
6b19c0639ba08cd5f3f47ac8a3afbd3c  lib-src/emacsclient.c

Also, please create a *server* buffer before starting the server and
send me its contents after the emacsclient session.

I will check out multi-tty from CVS and do a diff this evening; I didn't
have the chance to make the switch to Savannah yet.

> I'm not likely get through with checking what in my .emacs might be
> interfering with emacsclient sessions starting up on the tty today.

Your .emacs doesn't seem to make things worse, so that isn't necessary.

-- 
Karoly

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

> This is such a basic feature that my first instinct is that something
> might have gone wrong while the CVS branch was created.  Please verify
> that you have started with a _clean_ checkout (no leftover *.elc, *.o)
> and that the following four key files have the checksums shown below:
>
> $ md5sum src/callproc.c lisp/env.el lisp/server.el lib-src/emacsclient.c
> e6b3fc34d6e684433e96e648a8c00e21  src/callproc.c
> 53b084e43b550b6548fbfce0948bbcc2  lisp/env.el
> c4e7d9d27cb90c029fe3de60333e8450  lisp/server.el
> 6b19c0639ba08cd5f3f47ac8a3afbd3c  lib-src/emacsclient.c
>
> Also, please create a *server* buffer before starting the server and
> send me its contents after the emacsclient session.

Well, the checkout has the following:
e6b3fc34d6e684433e96e648a8c00e21  src/callproc.c
62bfaf0bcee37a112e4e2ca1effd2359  lisp/env.el
c4e7d9d27cb90c029fe3de60333e8450  lisp/server.el
6b19c0639ba08cd5f3f47ac8a3afbd3c  lib-src/emacsclient.c

(the difference in env.el will be the change I posted to the list).

I checked out fresh on a new system, configured, did make and make
install.  The resulting Emacs is not happy:

dak@lisa:/rep/emacs-build$ /usr/local/emacs-21/bin/emacs -Q
Wrong type argument: framep, 0
dak@lisa:/rep/emacs-build$ /usr/local/emacs-21/bin/emacs -nw -Q
emacs: Cannot open termcap database file

I can't get it to start even.  Again, this would seem to point to some
problem with the environment.

Strangely, I can start it using
emacs -Q -display :0.0
and saying
M-: (environment) RET
outputs something looking quite complete and sensible.

The version info would be

In GNU Emacs 23.0.51.1 (i686-pc-linux-gnu, GTK+ Version 2.10.11, multi-tty)
 of 2007-05-14 on lisa
Windowing system distributor `The X.Org Foundation', version 11.0.70200000
configured using `configure  '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars' 'CFLAGS=-g -O2 -fno-crossjumping''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<help-echo> <help-echo> <escape> : ( e n v i r o n 
e <backspace> m e n t ) <return> M-x e m a c s - r 
e <tab> <backspace> <backspace> b u <tab> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> r e p o r t - e m a c s - b 
u <tab> <return>

Recent messages:
Loading encoded-kb...done
For information about the GNU Project and its goals, type C-h C-p.
("DISPLAY=:0.0" "_=/usr/local/emacs-21/bin/emacs" "XAUTHORITY=/home/dak/.Xauthority" "COLORTERM=gnome-terminal" "LESSCLOSE=/usr/bin/lesspipe %s %s" "LESSOPEN=| /usr/bin/lesspipe %s" "DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-6pMvOtY9Ea,guid=896004724061f5360062af0046440a76" "LOGNAME=dak" "GNOME_DESKTOP_SESSION_ID=Default" "HOME=/home/dak" "SHLVL=1" "HISTCONTROL=ignoredups" ...)
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done


-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> dak@lisa:/rep/emacs-build$ /usr/local/emacs-21/bin/emacs -nw -Q
> emacs: Cannot open termcap database file

Apparently your emacs is misconfigured.  You should have TERMINFO
defined.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> dak@lisa:/rep/emacs-build$ /usr/local/emacs-21/bin/emacs -nw -Q
>> emacs: Cannot open termcap database file
>
> Apparently your emacs is misconfigured.  You should have TERMINFO
> defined.

As I said: it does not start without -nw either when the DISPLAY
variable is set appropriately, but it does start with -display :0.0.

It apparently has a problem accessing the environment.  This is a
fresh build from a fresh multi-tty checkout.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> dak@lisa:/rep/emacs-build$ /usr/local/emacs-21/bin/emacs -nw -Q
>>> emacs: Cannot open termcap database file
>>
>> Apparently your emacs is misconfigured.  You should have TERMINFO
>> defined.
>
> As I said: it does not start without -nw either when the DISPLAY
> variable is set appropriately, but it does start with -display :0.0.

No, you need to fix the configuration problem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Andreas Schwab <schwab@suse.de> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> dak@lisa:/rep/emacs-build$ /usr/local/emacs-21/bin/emacs -nw -Q
>>>> emacs: Cannot open termcap database file
>>>
>>> Apparently your emacs is misconfigured.  You should have TERMINFO
>>> defined.
>>
>> As I said: it does not start without -nw either when the DISPLAY
>> variable is set appropriately, but it does start with -display :0.0.
>
> No, you need to fix the configuration problem.

Thanks for your input.  But all other applications (including Emacs
22.x) run in this situation using either tty or DISPLAY.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Thanks for your input.  But all other applications (including Emacs
> 22.x) run in this situation using either tty or DISPLAY.

Worksforme.  You have to debug that yourself, I'm afraid.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Thanks for your input.  But all other applications (including Emacs
>> 22.x) run in this situation using either tty or DISPLAY.
>
> Worksforme.

Current checkout of multi-tty from Savannah CVS?

> You have to debug that yourself, I'm afraid.

Well, that was why I was asking for suggestion about how to debug this...

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Well, that was why I was asking for suggestion about how to debug this...

Grep for TERMINFO.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Andreas Schwab <schwab@suse.de> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >> Thanks for your input.  But all other applications (including Emacs
  > >> 22.x) run in this situation using either tty or DISPLAY.
  > >
  > > Worksforme.
  > 
  > Current checkout of multi-tty from Savannah CVS?

Worksforme too, current checkout of multi-tty from Savannah CVS, then
./configure --prefix=..... ; make bootstrap
strace of src/emacs -Q -nw shows that it's using terminfo not
termcap. What system are you on? 

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > Andreas Schwab <schwab@suse.de> writes:
>   > 
>   > > David Kastrup <dak@gnu.org> writes:
>   > >
>   > >> Thanks for your input.  But all other applications (including Emacs
>   > >> 22.x) run in this situation using either tty or DISPLAY.
>   > >
>   > > Worksforme.
>   > 
>   > Current checkout of multi-tty from Savannah CVS?
>
> Worksforme too, current checkout of multi-tty from Savannah CVS, then
> ./configure --prefix=..... ; make bootstrap
> strace of src/emacs -Q -nw shows that it's using terminfo not
> termcap. What system are you on? 

Ubuntu Feisty.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >   > Andreas Schwab <schwab@suse.de> writes:
  > >   > 
  > >   > > David Kastrup <dak@gnu.org> writes:
  > >   > >
  > >   > >> Thanks for your input.  But all other applications (including Emacs
  > >   > >> 22.x) run in this situation using either tty or DISPLAY.
  > >   > >
  > >   > > Worksforme.
  > >   > 
  > >   > Current checkout of multi-tty from Savannah CVS?
  > >
  > > Worksforme too, current checkout of multi-tty from Savannah CVS, then
  > > ./configure --prefix=..... ; make bootstrap
  > > strace of src/emacs -Q -nw shows that it's using terminfo not
  > > termcap. What system are you on? 
  > 
  > Ubuntu Feisty.

I tried this on a Ubuntu Feisty machine, but that machine does not
have the X11 headers installed, so I could only compile a terminal
based emacs. 

But this emacs would say "invalid argument framep 1" at startup. I set
debug-on-error to t and run C-x 5 2. The backtrace showed that the
error is in `getenv' and it is cause by an env.el change that YOU
installed on the multi-tty branch without a ChangeLog.

PLEASE REVERT THE CHANGE! It is never a good idea to install changes
without testing them, and you obviously didn't.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > David Kastrup <dak@gnu.org> writes:
>   > >
>   > >   > Andreas Schwab <schwab@suse.de> writes:
>   > >   > 
>   > >   > > David Kastrup <dak@gnu.org> writes:
>   > >   > >
>   > >   > >> Thanks for your input.  But all other applications
>   > >   > >> (including Emacs 22.x) run in this situation using
>   > >   > >> either tty or DISPLAY.
>   > >   > >
>   > >   > > Worksforme.
>   > >   > 
>   > >   > Current checkout of multi-tty from Savannah CVS?
>   > >
>   > > Worksforme too, current checkout of multi-tty from Savannah
>   > > CVS, then ./configure --prefix=..... ; make bootstrap strace
>   > > of src/emacs -Q -nw shows that it's using terminfo not
>   > > termcap. What system are you on?
>   > 
>   > Ubuntu Feisty.
>
> I tried this on a Ubuntu Feisty machine, but that machine does not
> have the X11 headers installed, so I could only compile a terminal
> based emacs.
>
> But this emacs would say "invalid argument framep 1" at startup. I
> set debug-on-error to t and run C-x 5 2. The backtrace showed that
> the error is in `getenv' and it is cause by an env.el change that
> YOU installed on the multi-tty branch without a ChangeLog.

If you tell me where to place the ChangeLog...  There is a CVS log
entry.

> PLEASE REVERT THE CHANGE! It is never a good idea to install changes
> without testing them, and you obviously didn't.

I did in a running session.  Anyway, if you bother to look at the
change, it does nothing except make the getenv actually do what its
DOC string claims to do.

So reverting the change is not the right solution.  Personally, I
think the arguments of getenv and setenv are completely messed up.

The usual behavior for optional FRAME arguments is:

If FRAME is non-nil, return the value that would be normal if FRAME
were the current active frame.  If FRAME is nil, return the value for
the current active frame.

If we want to get at some special FRAME-less variant of the
environment list, one could use a special argument of "t" or something
like that.

But the whole concept of frame-local environment variables seems like
asking for trouble to me.  For example, say I have a *shell* buffer.
I call emacsclient from somewhere to open either a frame or a tty and
say M-x shell RET in that window.  The environment variables of that
shell will remain the old ones.  Now I say exit RET M-x shell RET
again.  Depending on the frame I say this, the behavior will be
different.  Or not.

Much worse: for sentinel processes (which have no dedicated terminal),
the value of PATH that gets used will be more or less randomly
decided.

Then Emacs already has the concept of a "terminal"
(info "(elisp) Multiple Displays").  There exist things like
terminal-local variables.  But we also have:

       A single X server can handle more than one screen.  A display
    name `HOST:SERVER.SCREEN' has three parts; the last part specifies
    the screen number for a given server.  When you use two screens
    belonging to one server, Emacs knows by the similarity in their
    names that they share a single keyboard, and it treats them as a
    single terminal.

So when frames get opened on the same X screen, from an Emacs session
and later from an emacsclient session, Emacs treats them as _one_
_terminal_.

It does not make sense to have disparate sets of environment variables
for them: if I subsequently use M-x setenv RET in one frame, I would
be surprised if that setting does not propagate to the other frame.

So what I would propose is that we don't touch the environment
variables at all.  At startup of either emacsclient or emacs itself,
we read out all relevant environment variables describing the current
terminal (and no other) and place them into terminal-local variables,
and that's it.  We don't look afterwards at them for dealing with the
terminal: if the user messes with them inside of Emacs, they only
affect processes started within Emacs.

That way we don't get to worry about just what set of frames might or
might not be affected by setting environment variables.

But the current treatment of process-environment and frame-local
environment variables is just fragile and asking for trouble.  Since
we can't actually use Emacs simultaneously from two ttys, it makes no
sense to give it two identities with regard to the environment.
Dealing with two ttys does not really require this amount of
complication.

So while I agree with Dan that my change should probably be reverted
(making getenv's FRAME argument be ignored completely, in contrast to
its current DOC string), it appears to me like we'd be better off if
pretty much all of the env.el changes (and callers) were reverted as
well, and we instead replaced the calls of (getenv "TERMCAP") and
similar with references to terminal-local variables filled in at the
start of Emacs and/or emacsclient.

What do you think?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > 
  > >   > > David Kastrup <dak@gnu.org> writes:
  > >   > >
  > >   > >   > Andreas Schwab <schwab@suse.de> writes:
  > >   > >   > 
  > >   > >   > > David Kastrup <dak@gnu.org> writes:
  > >   > >   > >
  > >   > >   > >> Thanks for your input.  But all other applications
  > >   > >   > >> (including Emacs 22.x) run in this situation using
  > >   > >   > >> either tty or DISPLAY.
  > >   > >   > >
  > >   > >   > > Worksforme.
  > >   > >   > 
  > >   > >   > Current checkout of multi-tty from Savannah CVS?
  > >   > >
  > >   > > Worksforme too, current checkout of multi-tty from Savannah
  > >   > > CVS, then ./configure --prefix=..... ; make bootstrap strace
  > >   > > of src/emacs -Q -nw shows that it's using terminfo not
  > >   > > termcap. What system are you on?
  > >   > 
  > >   > Ubuntu Feisty.
  > >
  > > I tried this on a Ubuntu Feisty machine, but that machine does not
  > > have the X11 headers installed, so I could only compile a terminal
  > > based emacs.
  > >
  > > But this emacs would say "invalid argument framep 1" at startup. I
  > > set debug-on-error to t and run C-x 5 2. The backtrace showed that
  > > the error is in `getenv' and it is cause by an env.el change that
  > > YOU installed on the multi-tty branch without a ChangeLog.
  > 
  > If you tell me where to place the ChangeLog...  There is a CVS log
  > entry.
  > 
  > > PLEASE REVERT THE CHANGE! It is never a good idea to install changes
  > > without testing them, and you obviously didn't.
  > 
  > I did in a running session.  Anyway, if you bother to look at the
  > change, it does nothing except make the getenv actually do what its
  > DOC string claims to do.
  > 
  > So reverting the change is not the right solution.  Personally, I
  > think the arguments of getenv and setenv are completely messed up.

It is at this point. You changed the code from working into
non-working, and it's already stopping other people from testing
it. There was already a but report about this.

You can improve it later if you want it, but now it does not work, and
that reflects badly on the all the effort that was put into multi-tty.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:

>   > So reverting the change is not the right solution.  Personally,
>   > I think the arguments of getenv and setenv are completely messed
>   > up.

[You deleted the whole discussion and proposal for making a more
stable solution]

> It is at this point. You changed the code from working into
> non-working,

Wrong.  I changed code from _not_ working as advertised to _working_
as advertised.  Which means that a bug in a _caller_ now gets exposed.
You think that the right solution for the problem is hiding the bug in
the caller again, making the function do something different from what
the documentation claims it does.

> and it's already stopping other people from testing it. There was
> already a but report about this.
>
> You can improve it later if you want it, but now it does not work,
> and that reflects badly on the all the effort that was put into
> multi-tty.

I don't think that papering over bugs is what is required now.  If the
design does not hold up to the functions actually doing what the
documentation claims they do, it is broken.

Randomly making functions do something different from their
documentation until the stuff happens not to break immediately in
obvious ways is _not_ the right solution.

The right solution is to find the caller that passes a non-nil value
for FRAME into getenv with the wrong expectations, and _fix_ the
_caller_ rather than _break_ getenv's intended behavior and _ignore_
its FRAME parameter in order to hide the bug.

Either that, or decide that the whole idea of having getenv/setenv
with a FRAME parameter is broken.

I'd lean towards the latter.  But in either case, we need to be
consistent about it and follow through in both documentation and
implementation.

If the design is unsound, we need to rip it out completely, not just
sabotage it at the points where the problems show.

I'll try to see whether I can find the problematic caller.  But I
certainly hope that this "paper over it and hope nobody notices it"
stance does not pervade multi-tty, and that the _bug_ which I fixed
was not intentional but an oversight.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > 
  > >   > So reverting the change is not the right solution.  Personally,
  > >   > I think the arguments of getenv and setenv are completely messed
  > >   > up.
  > 
  > [You deleted the whole discussion and proposal for making a more
  > stable solution]

Yes, intentionally as it is irrelevant here. Before your change people
were able to test the multi-tty functionality, after it they are not. 
Nobody claimed the code was bug free, but it did do what was
advertised to do.

This shows a total lack of respect for all the hard work Karoly's put
in for a few years.

  > > It is at this point. You changed the code from working into
  > > non-working,
  > 
  > Wrong.  I changed code from _not_ working as advertised to _working_
  > as advertised.  Which means that a bug in a _caller_ now gets exposed.
  > You think that the right solution for the problem is hiding the bug in
  > the caller again, making the function do something different from what
  > the documentation claims it does.

You left the tree in an broken state, you didn't even debug the
problem that you caused. THAT is wrong.

  > I'll try to see whether I can find the problematic caller.  But I
  > certainly hope that this "paper over it and hope nobody notices it"
  > stance does not pervade multi-tty, and that the _bug_ which I fixed
  > was not intentional but an oversight.

This is totally uncalled for. 
I have already given you a trivial way to find the caller.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Jason Rumney]

Dan Nicolaescu wrote:
> Yes, intentionally as it is irrelevant here. Before your change people
> were able to test the multi-tty functionality, after it they are not. 
> Nobody claimed the code was bug free, but it did do what was
> advertised to do.
>
> This shows a total lack of respect for all the hard work Karoly's put
> in for a few years.
>   

Helping to fix bugs does not show a lack of respect.

One has to expect some short term disruption when using code from CVS. 
Perhaps you have forgotten that over the last 3 years, as Emacs has been 
perilously close to release for that time, and thus reasonably stable.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

Jason Rumney <jasonr@gnu.org> writes:

  > Dan Nicolaescu wrote:
  > > Yes, intentionally as it is irrelevant here. Before your change people
  > > were able to test the multi-tty functionality, after it they are
  > > not. Nobody claimed the code was bug free, but it did do what was
  > > advertised to do.
  > >
  > > This shows a total lack of respect for all the hard work Karoly's put
  > > in for a few years.
  > >   
  > 
  > Helping to fix bugs does not show a lack of respect.

I agree, that might have been the intention, but that is not what I
see happening here. This change strictly made the behavior
worse. Given that for most people this is the first time they have a
chance to play with multi-tty, this does not reflect well on that
code.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>   > Dan Nicolaescu wrote:
>   > > Yes, intentionally as it is irrelevant here. Before your change people
>   > > were able to test the multi-tty functionality, after it they are
>   > > not. Nobody claimed the code was bug free, but it did do what was
>   > > advertised to do.
>   > >
>   > > This shows a total lack of respect for all the hard work Karoly's put
>   > > in for a few years.
>   > >   
>   > 
>   > Helping to fix bugs does not show a lack of respect.
>
> I agree, that might have been the intention, but that is not what I
>see happening here. This change strictly made the behavior
>worse. Given that for most people this is the first time they have a
>chance to play with multi-tty, this does not reflect well on that
>code.

Reality check: it did not already work here as advertised, partly
because the getenv function ignores its FRAME argument in stark
contrast to the documentation.  This is the first time multi-tty gets
accessible to _developers_, and you clamor for papering over obvious
bugs already by letting functions behave contrary to their design and
documentation.

Papering over bugs, if at all, should be reserved for the _end_ of a
release cycle.  And you want to _start_ with it.

But it would not paper over the bug that got me _started_ looking into
getenv in the first place, namely that emacsclient can't work unless
emacs was started from a tty with the same termcap/terminfo situation.
What do you thing the "multi" in "multi-tty" is supposed to stand for?

That way we'll never get to working code.

Again, I repeat my offer: if that's the consensus among multitty
developers, I'll be glad to revert the change and stop touching the
branch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Richard Stallman]

    Helping to fix bugs does not show a lack of respect.

This isn't a matter of "respect", just awareness of certain consequences
that would really get in some other people's way.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > David Kastrup <dak@gnu.org> writes:
>   > 
>   > >   > So reverting the change is not the right solution.  Personally,
>   > >   > I think the arguments of getenv and setenv are completely messed
>   > >   > up.
>   > 
>   > [You deleted the whole discussion and proposal for making a more
>   > stable solution]
>
> Yes, intentionally as it is irrelevant here. Before your change
> people were able to test the multi-tty functionality, after it they
> are not.  Nobody claimed the code was bug free, but it did do what
> was advertised to do.

Reality check.  It didn't.  It only worked when one started the main
Emacs from a tty with termcap/terminfo settings identical to those
where one later started emacsclient.

That was the problem I hit first and reported.  And part of the reason
is that getenv does not, as opposed to advertised, fetch a terminal-
or frame-specific environment variable.

So I changed it to do that in order to match its DOC string, and it
turns out that the code for _multitty_ (what this branch is supposed
to be about in the first place) does not yet fetch the right kind of
variables.

So you propose to tackle the problem by destroying multi-tty
capability, making everything rely on a single environment for all
terminals.

If there is consensus among the multitty developers for that, I'll be
happy to revert the change and indeed not touch the multitty code
anymore at all.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >   > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > 
  > >   > > David Kastrup <dak@gnu.org> writes:
  > >   > 
  > >   > >   > So reverting the change is not the right solution.  Personally,
  > >   > >   > I think the arguments of getenv and setenv are completely messed
  > >   > >   > up.
  > >   > 
  > >   > [You deleted the whole discussion and proposal for making a more
  > >   > stable solution]
  > >
  > > Yes, intentionally as it is irrelevant here. Before your change
  > > people were able to test the multi-tty functionality, after it they
  > > are not.  Nobody claimed the code was bug free, but it did do what
  > > was advertised to do.
  > 
  > Reality check.  It didn't.  It only worked when one started the main
  > Emacs from a tty with termcap/terminfo settings identical to those
  > where one later started emacsclient.

Can you please provide a proper bug report of what you are trying to
do and how?

  > That was the problem I hit first and reported.  And part of the reason
  > is that getenv does not, as opposed to advertised, fetch a terminal-
  > or frame-specific environment variable.
  > 
  > So I changed it to do that in order to match its DOC string, and it
  > turns out that the code for _multitty_ (what this branch is supposed
  > to be about in the first place) does not yet fetch the right kind of
  > variables.

Do you feel that it is reasonable to make changes to the CVS that you
don't create ChangeLogs for, don't even post something on the list
letting people know that you've made changes, and then complain that 
things don't work and can't even discover that your own changes caused
the breakage?

  > So you propose to tackle the problem by destroying multi-tty
  > capability, making everything rely on a single environment for all
  > terminals.

I have proposed no such things. I only asked for a change to be
reverted because it made things strictly worse than before.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>   > > people were able to test the multi-tty functionality, after it
>   > > they are not.

Reality check.  I tested it.  It was not up to par.  You seem to say
that one should only be allowed to test it, not change it.

>   > > Nobody claimed the code was bug free, but it did do what was
>   > > advertised to do.
>   > 
>   > Reality check.  It didn't.  It only worked when one started the
>   > main Emacs from a tty with termcap/terminfo settings identical
>   > to those where one later started emacsclient.
>
> Can you please provide a proper bug report of what you are trying to
> do and how?

Oh for heavens sake, don't you read this list?

Start something like
TERM="" TERMCAP="" COLORTERM="" COLUMNS="" ROWS="" emacs -Q
(the point being to remove terminal-related variables)
and then, from a tty, start

emacsclient -t

This does not work.

>   > That was the problem I hit first and reported.  And part of the
>   > reason is that getenv does not, as opposed to advertised, fetch
>   > a terminal- or frame-specific environment variable.
>   > 
>   > So I changed it to do that in order to match its DOC string, and
>   > it turns out that the code for _multitty_ (what this branch is
>   > supposed to be about in the first place) does not yet fetch the
>   > right kind of variables.
>
> Do you feel that it is reasonable to make changes to the CVS that
> you don't create ChangeLogs for,

There _is_ no ChangeLog file for multi-tty yet, and I _did_ create a
CVS log entry.

> don't even post something on the list letting people know that
> you've made changes,

I _did_ post the patch to the list.

> and then complain that things don't work and can't even discover
> that your own changes caused the breakage?

There was breakage _before_.  And I asked several times whether the
people who could not follow my report had used multi-tty HEAD from
Emacs CVS.

>   > So you propose to tackle the problem by destroying multi-tty
>   > capability, making everything rely on a single environment for
>   > all terminals.
>
> I have proposed no such things. I only asked for a change to be
> reverted because it made things strictly worse than before.

Fine, this is for now the end of my involvement with the multi-tty
branch.  I am reverting the change and deleting my checked-out copy.
There is no sense bothering with code that people don't want to see
any work done on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Thien-Thi Nguyen]

() David Kastrup <dak@gnu.org>
() Tue, 15 May 2007 00:27:45 +0200

   There _is_ no ChangeLog file for multi-tty yet, and I _did_ create a
   CVS log entry.

i believe you can simply use the regular ChangeLog.  when the branch is
merged, the ChangeLog entries need to be merged, as well.

thi

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () David Kastrup <dak@gnu.org>
> () Tue, 15 May 2007 00:27:45 +0200
>
>    There _is_ no ChangeLog file for multi-tty yet, and I _did_ create a
>    CVS log entry.
>
> i believe you can simply use the regular ChangeLog.  when the branch is
> merged, the ChangeLog entries need to be merged, as well.

I have already reverted back my checked-out copy to the trunk.  If
anybody wants to fix the ChangeLog in multi-tty to reflect the last
change and revert of mine, here are the relevant entries I would have
put into lisp/ChangeLog:

2007-05-14  David Kastrup  <dak@gnu.org>

	* env.el (getenv): Fix reverted by demand of Dan Nicolaescu
	because it exposes further problems.

2007-05-13  David Kastrup  <dak@gnu.org>

	* env.el (getenv): Pass frame to getenv-internal.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design

[Nick Roberts]

 > I have already reverted back my checked-out copy to the trunk.  If
 > anybody wants to fix the ChangeLog in multi-tty to reflect the last
 > change and revert of mine, here are the relevant entries I would have
 > put into lisp/ChangeLog:
 > 
 > 2007-05-14  David Kastrup  <dak@gnu.org>
 > 
 > 	* env.el (getenv): Fix reverted by demand of Dan Nicolaescu
 > 	because it exposes further problems.
 > 
 > 2007-05-13  David Kastrup  <dak@gnu.org>
 > 
 > 	* env.el (getenv): Pass frame to getenv-internal.

I can't comment on the technical merit of your fix, for all I know it may
indeed be right.  I just don't think your bullish approach is effective
and that you need to wait for others to agree with your ideas before
rushing ahead with them.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Multi-tty design

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > I have already reverted back my checked-out copy to the trunk.  If
>  > anybody wants to fix the ChangeLog in multi-tty to reflect the last
>  > change and revert of mine, here are the relevant entries I would have
>  > put into lisp/ChangeLog:
>  > 
>  > 2007-05-14  David Kastrup  <dak@gnu.org>
>  > 
>  > 	* env.el (getenv): Fix reverted by demand of Dan Nicolaescu
>  > 	because it exposes further problems.
>  > 
>  > 2007-05-13  David Kastrup  <dak@gnu.org>
>  > 
>  > 	* env.el (getenv): Pass frame to getenv-internal.
>
> I can't comment on the technical merit of your fix, for all I know
> it may indeed be right.

It is right on the surface: I already explained in detail my opinion
about the whole idea: my preferred solution would be to revert most
changes to env.el since the whole idea is not sound.  But if one is
convinced that it is the right idea, one needs to start by letting the
functions actually do what they claim to do.

But if we don't bother about actually _implementing_ the announced
design, evaluating it is not possible.  That's cheating.

> I just don't think your bullish approach is effective and that you
> need to wait for others to agree with your ideas before rushing
> ahead with them.

They are free to approach this in whatever pace they want to.  It's
not like I don't have more rewarding stuff piling up, anyway.

A "bullish" approach would have been replacing the code by code of my
own design, rather than replacing it by the announced and intended,
but not properly implemented design.  I have my doubts that it _can_
be properly implemented, but I was at least willing to give it a shot.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Thien-Thi Nguyen <ttn@gnuvola.org> writes:
  > 
  > > () David Kastrup <dak@gnu.org>
  > > () Tue, 15 May 2007 00:27:45 +0200
  > >
  > >    There _is_ no ChangeLog file for multi-tty yet, and I _did_ create a
  > >    CVS log entry.
  > >
  > > i believe you can simply use the regular ChangeLog.  when the branch is
  > > merged, the ChangeLog entries need to be merged, as well.
  > 
  > I have already reverted back my checked-out copy to the trunk.  If

Thank you. Now the branch is functional again.
I'd be glad to help finding any bugs that have a clear description
that can be reproduced. 

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Jason Rumney]

As there are likely to be more disruptive changes on the multi-tty 
branch as developers work on making it work on other platforms, would it 
be a good idea to tag the initial checkin of the branch as 
"multi-tty-stable" or similar? Once the initial disruption is over, we 
can update the tag regularly to give people who want to test the branch 
in their daily use something that is at least reasonably stable to track.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

David Kastrup wrote:
> I have already reverted back my checked-out copy to the trunk.  If
> anybody wants to fix the ChangeLog in multi-tty to reflect the last
> change and revert of mine, here are the relevant entries I would have
> put into lisp/ChangeLog:

I did so, and completed your fix.  If you are able and willing, please see if
the branch works on your system now.

Elsewhere in this thread, I've just posted a description of the current
environment implementation and a short rationale for it.  Now would be a good
time to discuss alternatives.

Please remember that I may not reply immediately to emails.

-- 
Karoly

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Jason Rumney]

> i believe you can simply use the regular ChangeLog.  when the branch is
> merged, the ChangeLog entries need to be merged, as well.
>   
The emacs-unicode-2 branch uses a separate ChangeLog, precisely because 
CVS does not handle merging ChangeLogs well.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Miles Bader]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>    There _is_ no ChangeLog file for multi-tty yet, and I _did_ create a
>    CVS log entry.
>
> i believe you can simply use the regular ChangeLog.  when the branch is
> merged, the ChangeLog entries need to be merged, as well.

No actually that's a bad idea; while a branch is separate, it makes
things _much_ easier if separate ChangeLog files are used.

Following the usual conventions would suggest using ChangeLog files
named "ChangeLog.multi-tty" (in the same directories where the normal
ChangeLog files are).

[The historical changelog entries should also eventually be placed into
the ChangeLog.multi-tty files, but for now it seems a good idea if
people would start using them for new entries.]

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Multi-tty design (Re: Reordering etc/NEWS)

[joakim]

> Fine, this is for now the end of my involvement with the multi-tty
> branch.  I am reverting the change and deleting my checked-out copy.
> There is no sense bothering with code that people don't want to see
> any work done on.

I've mostly seen correspondence between you and Dan Nicolaescu in this
thread, so its not clear that people in general dont want to see work
done on the mtty branch.

> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Joakim Verona

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

joakim@verona.se writes:

>> Fine, this is for now the end of my involvement with the multi-tty
>> branch.  I am reverting the change and deleting my checked-out
>> copy.  There is no sense bothering with code that people don't want
>> to see any work done on.
>
> I've mostly seen correspondence between you and Dan Nicolaescu in
> this thread, so its not clear that people in general dont want to
> see work done on the mtty branch.

Then they can earn their own share of abuse for it.  No need for me to
hog all the blame.  I'm coding for fun.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > >   > > Nobody claimed the code was bug free, but it did do what was
  > >   > > advertised to do.
  > >   > 
  > >   > Reality check.  It didn't.  It only worked when one started the
  > >   > main Emacs from a tty with termcap/terminfo settings identical
  > >   > to those where one later started emacsclient.
  > >
  > > Can you please provide a proper bug report of what you are trying to
  > > do and how?
  > 
  > Oh for heavens sake, don't you read this list?

Please point me to the message (excepting this one) where you have
sent a reproduceable description of your issue.

I did this: 
  > Start something like
  > TERM="" TERMCAP="" COLORTERM="" COLUMNS="" ROWS="" emacs -Q
  > (the point being to remove terminal-related variables)
  > and then, from a tty, start

And then did M-x server-start RET

  > emacsclient -t
  > 
  > This does not work.

emacsclient -t started fine for me and it is fully functional, colors
appear as expected.

  > >   > That was the problem I hit first and reported.  And part of the
  > >   > reason is that getenv does not, as opposed to advertised, fetch
  > >   > a terminal- or frame-specific environment variable.
  > >   > 
  > >   > So I changed it to do that in order to match its DOC string, and
  > >   > it turns out that the code for _multitty_ (what this branch is
  > >   > supposed to be about in the first place) does not yet fetch the
  > >   > right kind of variables.
  > >
  > > Do you feel that it is reasonable to make changes to the CVS that
  > > you don't create ChangeLogs for,
  > 
  > There _is_ no ChangeLog file for multi-tty yet, and I _did_ create a
  > CVS log entry.
  > 
  > > don't even post something on the list letting people know that
  > > you've made changes,
  > 
  > I _did_ post the patch to the list.

That is not the same as saying you committed the patch. 

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Lennart Borgman (gmail)]

Dan Nicolaescu wrote:

> emacsclient -t started fine for me and it is fully functional, colors
> appear as expected.

It looked to me like you were very close to start working on the problem 
David noticed.

Now you have got into a difficult situation. It would at least impress 
me if you two were able to revert that situation. It is not impossible, 
but possibly rather difficult to turn this into something good for both 
of you (and the rest of us). After all we are all human beeings, trying 
to do the best we can.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Dan Nicolaescu wrote:
>
>> emacsclient -t started fine for me and it is fully functional, colors
>> appear as expected.
>
> It looked to me like you were very close to start working on the
> problem David noticed.

What makes you think so?

> Now you have got into a difficult situation. It would at least
> impress me if you two were able to revert that situation.

I reverted it.  But I don't find it impressive to leave obvious bugs
in the code in order to hide other bugs.

> It is not impossible, but possibly rather difficult to turn this
> into something good for both of you (and the rest of us). After all
> we are all human beeings, trying to do the best we can.

This was about _refraining_ from doing the best one can.  I pointed
out a problem where the code was not working as designed.  I also dug
up all Lisp callers that might be responsible for that and listed
them.

There was not a single word of interest into either looking into the
code I touched or the code I pinpointed.  There was not a single
comment upon my proposal for fixing the _design_ (which leads to
inconsistent, and overly complex behavior because it tries to
differentiate an environment variable set based on _another_ concept
of "terminal-local" that does not consider, say, two frames on the
same tty or X display as being on the same terminal).  Indeed, Dan
explicitly said that he was deleting any comment on the design since
he was not interested in it.

All he was interested in was in reverting to the previous broken
state.

Nobody else was interested in following up on the problems, so that is
it.  I am not interested in getting no feedback but abuse for
bothering about a problem area.  I don't have the resources to fix all
of it myself, and if nobody else can be bothered to do anything but
complain, there is no point in even starting.

So I guess it is completely up to Károly to get this working or not.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Dan Nicolaescu wrote:
>>
>>> emacsclient -t started fine for me and it is fully functional, colors
>>> appear as expected.
>> It looked to me like you were very close to start working on the
>> problem David noticed.
> 
> What makes you think so?

I do not at all know that code or the difficulties you tried to point 
out, but it looked to me like you were trying to get a grasp on the 
problem to solve it. Now I see Karoly has done what I beleive you wanted.


>> Now you have got into a difficult situation. It would at least
>> impress me if you two were able to revert that situation.
> 
> I reverted it.  But I don't find it impressive to leave obvious bugs
> in the code in order to hide other bugs.

I hope that both you and Dan can feel ok again and perhaps try to 
understand why you misunderstood each other.

With that I do not want to blame anyone of you. When things get both 
complicated and stressing misunderstanding is a very likely outcome. One 
of the reasons is that communication is on different levels 
simultaneously, both the logical and emotional level.

The challenge is perhaps to see what is happening to oneself and then on 
what level to correct the communication. And maybe also that one may 
switch level when one gets stressed. Some people becomes more logical 
when stressed, other becomes more emotional. And for all of us I believe 
it is a bit harder to switch level when one is stressed.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Thien-Thi Nguyen]

() Dan Nicolaescu <dann@ics.uci.edu>
() Mon, 14 May 2007 15:13:11 -0700

     > So you propose to tackle the problem by destroying multi-tty
     > capability, making everything rely on a single environment for all
     > terminals.

   I have proposed no such things. I only asked for a change to be
   reverted because it made things strictly worse than before.

it sounds like what happened was an incomplete, unlogged bugfix.
the right thing to do is to complete the bugfix and log it (all parts).

if completing the bugfix requires others' expertise, the next best
thing is to clearly log what was done to help others finish the job.
(the sooner the better.)

e.g., this is what happened w/ my change to gnus.  i fixed a
long-standing buglet, but only partially (other use-cases broke).
it was Katsumi Yamaoka who completed the process.

thi

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 742 bytes --]

Dan Nicolaescu wrote:
> David Kastrup <dak@gnu.org> writes:
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > > David Kastrup <dak@gnu.org> writes:
[snip]

This is not productive.  Can we please stop bickering and do some useful
work instead?

David has spotted a real bug.  According to current design, the third
parameter to getenv should specify a terminal (i.e., it should be a
numerical terminal id or a sample frame on that terminal).  Both the doc
string _and_ the implementation is wrong, but the callers are right.  I
probably committed an out-of-sync env.el somehow.

I'll fix the bug myself, and look at the Arch history to see if I can
find a reason why it happened.  This is an unusual bug.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

Karoly Lorentey wrote:
> David has spotted a real bug.  According to current design, the third
> parameter to getenv should specify a terminal (i.e., it should be a
> numerical terminal id or a sample frame on that terminal).  Both the doc
> string _and_ the implementation is wrong, but the callers are right.  I
> probably committed an out-of-sync env.el somehow.

No, my memory has failed me.  I had a patch implementing the above design, but
what we currently have in the tree is something more complex: environment
variables are neither frame-, nor terminal-local, but rather client-local.

The client-local environment list is shared between frames that were created in
the same Emacsclient session.  The environment list is stored in a single
frame's environment parameter; the other frames' environment is set to this
frame.  (See `frame-with-environment'.)  Frames not originating from an
emacsclient session get the environment of the Emacs process itself, by the same
mechanism. (Note that when the user exits emacsclient, all frames belonging to
that client are automatically deleted.)

`process-environment' is nil by default.  If it is non-nil, its contents
override all client-local environment lists.

Since there is no "global" environment, getenv reports the selected frame's
environment by default, possibly overridden by process-environment.  If a third
parameter is given, it ignores `process-environment' (this must be fixed) and
simply returns the specific local environment that the user asked for.

Setenv, on the other hand, changes process-environment by default, overriding
the environment on all frames at once.

This approach does work quite well in practice, but it is ugly to implement. I
am open to suggestions to replace it with something better.  (At the very least,
getenv should not ignore `process-environment' when given a specific frame.)

Please consider the following:

	- At least some environment variables _must_ behave locally; if not
	  client-locally, then at least terminal-locally.  DISPLAY is perhaps
	  the most obvious example.  X clients such as xdvi started from Emacs
	  must appear on the display the user currently works on.
	  This is an important feature for multi-tty users and I would like
	  to keep it supported.  Similar variables include SSH_AUTH_SOCK,
	  GPG_AGENT_INFO, AGENT_SOCKET, LANG, LC_*, and basically anything that
	  may be different from login session to login session.

	- For the user, there is a strong sense of connection between
	  an emacsclient instance and its set of frames.  If emacsclient
	  exits, then its frames are deleted and vice versa.  C-x C-c kills
	  emacsclient, not the entire Emacs process.  All this feels
	  very natural and fits a range of common use-cases, particularly
	  the ones involving quick editing jobs from the command prompt.
	  (These are the ones for which Emacs was so infamously not well
	  suited before.)

	  This means that having a different set of variables from frame to
	  frame does not normally seem inconsistent or unpredictable to the
	  user.

	- Furthermore, to me it seems more consistent to have all
	  environment variables be local than just a select few of them.

	- Client-local environments mean that two separate emacsclient instances 	  on
the same terminal can have different environments:

		$ FOO=23 emacsclient
			(getenv "FOO") ==> 23
		C-z
		$ FOO=42 emacsclient            # Other frame is still alive,
			(getenv "FOO") ==> 42   # with a value of 23.

          This is a corner case that deepens the illusion of emacsclient being
	  a real standalone editor.  It is not an important feature, although it
	  did often come useful for me, particularly with long emacsclient
	  sessions for different tasks, but sharing a single X display.

	  Terminal-local environments would less complete, but still good enough
	  to be usable without many problems.

	- The behaviour of M-x shell and similar packages is mostly irrelevant
	  here.  I used to have a hack in my .emacs to have
	  M-x shell create a new instance on each terminal automatically, nicely
	  hiding environment-related inconsistencies.  There is no reason not to
	  have something like that supported as an option.

If you find client-local environments unacceptably ugly, I can update and submit
my patch for simple terminal-local environments.  The local environment then
becomes a simple terminal parameter, initialized when the terminal is created.
This is a much simpler solution that retains much of the feature set of the
current design.

For now, the branch uses the implementation described above. The bug David
Kastrup found is now fixed correctly in Arch, and should be synced to CVS soonish.

-- 
Karoly

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Stefan Monnier]

> 	- At least some environment variables _must_ behave locally; if not
> 	  client-locally, then at least terminal-locally.  DISPLAY is perhaps
> 	  the most obvious example.  X clients such as xdvi started from Emacs
> 	  must appear on the display the user currently works on.

Actually, the DISPLAY environment should behave that way even without the
use of emacsclient (when you use make-frame-on-display).

> 	  This is an important feature for multi-tty users and I would like
> 	  to keep it supported.  Similar variables include SSH_AUTH_SOCK,
> 	  GPG_AGENT_INFO, AGENT_SOCKET, LANG, LC_*, and basically anything
> 	  that may be different from login session to login session.

I don't think the vars you list are particularly important.  Which version
of those vars to use (the one from the emacsclient process or from the main
Emacs process) may depend from case to case.  So either choice is
probably OK.

I tend to think of emacsclient as "connect to the main Emacs process", so
I tend to expect it to work in the environment of the main Emacs process.
You seem to think of it as "pretend you're a normal Emacs process, just
quick-started", so you expect a slightly different behavior.

> 	- For the user, there is a strong sense of connection between
> 	  an emacsclient instance and its set of frames.  If emacsclient
> 	  exits, then its frames are deleted and vice versa.  C-x C-c kills
> 	  emacsclient, not the entire Emacs process.  All this feels
> 	  very natural and fits a range of common use-cases, particularly
> 	  the ones involving quick editing jobs from the command prompt.
> 	  (These are the ones for which Emacs was so infamously not well
> 	  suited before.)

Yes, it's probably OK to use frames as an approximation of "terminal" or
"display" or "client".

> 	- Furthermore, to me it seems more consistent to have all
> 	  environment variables be local than just a select few of them.

I don't find it important, but it doesn't seem to be bad either.  So I'd
leave it as a choice that can be determined by the implementation.


        Stefan

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 	- At least some environment variables _must_ behave locally;
>> 	if not client-locally, then at least terminal-locally.
>> 	DISPLAY is perhaps the most obvious example.  X clients such
>> 	as xdvi started from Emacs must appear on the display the user
>> 	currently works on.
>
> Actually, the DISPLAY environment should behave that way even
> without the use of emacsclient (when you use make-frame-on-display).

Agreed.  But terminal-locality is all that is required (and in my
opinion appropriate) here.  And it is _not_ a matter of "exporting"
the start _environment_, but rather of exporting the start _settings_.

I would argue that an Emacs started with
DISPLAY=:0.0 emacs -display :1.0
should export an environment variable DISPLAY=:1.0 to its subprocesses
unless explicitly overridden.  This is somewhat complicated by the
situation given with
DISPLAY=:0.0 emacs -nw
In this case, I would still want to export :0.0 to subprocesses, and
in the case
DISPLAY=:0.0 emacs -nw -display :1.0
I would suggest a non-graphical instance of Emacs exporting a DISPLAY
variable of :1.0.

>> 	  This is an important feature for multi-tty users and I would
>> 	  like to keep it supported.  Similar variables include
>> 	  SSH_AUTH_SOCK, GPG_AGENT_INFO, AGENT_SOCKET, LANG, LC_*, and
>> 	  basically anything that may be different from login session
>> 	  to login session.
>
> I don't think the vars you list are particularly important.  Which
> version of those vars to use (the one from the emacsclient process
> or from the main Emacs process) may depend from case to case.  So
> either choice is probably OK.

Where Emacs' behavior depends on such variables, it might make sense
to let them influence Emacs' behavior in terminal-local entities, and
have a default export mechanism based on those terminal-local recorded
settings.  It would seem desirable to have parallel terminal sessions
from an iso-8859-1 terminal and a utf-8 terminal into Emacs possible
without getting garbled screens.  In particular the ability to edit
right-to-left languages in a terminal capable of RTL languages, while
keeping a non RTL-capable environment for other tasks, might be one
step in the course of getting Emacs usable in RTL environments.

> I tend to think of emacsclient as "connect to the main Emacs
> process", so I tend to expect it to work in the environment of the
> main Emacs process.  You seem to think of it as "pretend you're a
> normal Emacs process, just quick-started", so you expect a slightly
> different behavior.

And I don't think that Emacs can actually be even close to satisfying
the second paradigm, so there is little sense in doing a half-baked
version of it and failing.

>> 	- For the user, there is a strong sense of connection between
>> 	an emacsclient instance and its set of frames.  If emacsclient
>> 	exits, then its frames are deleted and vice versa.  C-x C-c
>> 	kills emacsclient, not the entire Emacs process.  All this
>> 	feels very natural and fits a range of common use-cases,
>> 	particularly the ones involving quick editing jobs from the
>> 	command prompt.  (These are the ones for which Emacs was so
>> 	infamously not well suited before.)
>
> Yes, it's probably OK to use frames as an approximation of
> "terminal" or "display" or "client".

I disagree.  If I have two frames side by side displaying the same
buffer, it will be extremely confusing if using setenv in one frame
will not have an effect on the other frame when calling commands with
M-!.

Any setenv on the same _terminal_ should certainly affect the
operation on the other end.  And I claim that for not display-related
environment variables like "PATH", the same should hold _across_
terminals.  terminal-specific variables like "DISPLAY" and possibly a
subset of LC* variables should, in contrast, usually be managed
terminal-locally.

>> 	- Furthermore, to me it seems more consistent to have all
>> 	environment variables be local than just a select few of them.
>
> I don't find it important, but it doesn't seem to be bad either.

Disagree.  It makes shell buffers behave totally unpredictable across
terminals (or even worse, frames): the sequence
exit RET M-x shell RET
usually gets rid of environment variables set within the shell
session.  It would not be nice to have to guess what behavior will
result.

AUCTeX, for example, contains code like the following:

(defun preview-set-texinputs (&optional remove)
  "Add `preview-TeX-style-dir' into `TEXINPUTS' variables.
With prefix argument REMOVE, remove it again."
  (interactive "P")
  (let ((case-fold-search nil)
	(preview-TeX-style-dir (preview-TeX-style-cooked))
	pattern)
    (if remove
	(progn
	  (setq pattern (concat "\\`\\(TEXINPUTS[^=]*\\)=\\(.*\\)"
				(regexp-quote preview-TeX-style-dir)))
	  (dolist (env (copy-sequence process-environment))
	    (if (string-match pattern env)
		(setenv (match-string 1 env)
			(and (or (< (match-beginning 2) (match-end 2))
				 (< (match-end 0) (length env)))
			     (concat (match-string 2 env)
				     (substring env (match-end 0))))))))
      (setq pattern (regexp-quote preview-TeX-style-dir))
      (dolist (env (cons "TEXINPUTS=" (copy-sequence process-environment)))
	(if (string-match "\\`\\(TEXINPUTS[^=]*\\)=" env)
	    (unless (string-match pattern env)
	      (setenv (match-string 1 env)
		      (concat preview-TeX-style-dir
			      (substring env (match-end 0))))))))))

(defcustom preview-TeX-style-dir nil
  "This variable contains the location of uninstalled TeX styles.
If this is nil, the preview styles are considered to be part of
the installed TeX system.

Otherwise, it can either just specify an absolute directory, or
it can be a complete TEXINPUTS specification.  If it is the
latter, it has to be followed by the character with which
kpathsea separates path components, either `:' on Unix-like
systems, or `;' on Windows-like systems.  And it should be
preceded with .: or .; accordingly in order to have . first in
the search path.

The `TEXINPUT' environment type variables will get this prepended
at load time calling \\[preview-set-texinputs] to reflect this.
You can permanently install the style files using
\\[preview-install-styles].

Don't set this variable other than with customize so that its
changes get properly reflected in the environment."
  :group 'preview-latex
  :set (lambda (var value)
	 (and (boundp var)
	      (symbol-value var)
	      (preview-set-texinputs t))
	 (set var value)
	 (and (symbol-value var)
	      (preview-set-texinputs)))
  :type '(choice (const :tag "Installed" nil)
		 (string :tag "Style directory or TEXINPUTS path")))


It is a straightforward manipulation of process-environment intended
to work for the entire session, on variables that have nothing to do
with the DISPLAY.

We don't want to have _any_ such code just break.  It is _not_ code
that is written sloppily or making unfounded assumptions.  It needs to
access all environment variables obeying a given pattern and
manipulate them.  It does this by looping through process-environment
(more exactly, a copy of it so that the exact implementation of setenv
can't interfere with the loop).  This is completely straightforward,
not related to multi-tty-ness at all, and we don't want such usage to
break.

> So I'd leave it as a choice that can be determined by the
> implementation.

Guffah.  Uh, the implementation will, _of_ _course_, determine _every_
choice.  That's why we are discussing it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 4210 bytes --]

David Kastrup wrote:
> I would argue that an Emacs started with
> DISPLAY=:0.0 emacs -display :1.0
> should export an environment variable DISPLAY=:1.0 to its subprocesses
> unless explicitly overridden.  This is somewhat complicated by the
> situation given with
> DISPLAY=:0.0 emacs -nw
> In this case, I would still want to export :0.0 to subprocesses, and
> in the case
> DISPLAY=:0.0 emacs -nw -display :1.0
> I would suggest a non-graphical instance of Emacs exporting a DISPLAY
> variable of :1.0.

I do not feel this is a particularly important issue, but sure.  Do
people use -display often?  I usually simply change DISPLAY directly.

> Where Emacs' behavior depends on such variables, it might make sense
> to let them influence Emacs' behavior in terminal-local entities, and
> have a default export mechanism based on those terminal-local recorded
> settings.  It would seem desirable to have parallel terminal sessions
> from an iso-8859-1 terminal and a utf-8 terminal into Emacs possible
> without getting garbled screens.

Yes, Emacs behaviour is different on different terminals according  to
TERM, LANG, LC_*, and others.  But this isn't really a matter of having
{terminal,client,frame}-local environment variables.  The environment of
emacsclient can remain available in `server-clients', and server.el can
do the right thing even if we choose not to allow subprocesses to
inherit local environments at all.

So having a both UTF-8 and Latin-1 tty sessions will remain possible
with or without local environment variables.

>> I tend to think of emacsclient as "connect to the main Emacs
>> process", so I tend to expect it to work in the environment of the
>> main Emacs process.  You seem to think of it as "pretend you're a
>> normal Emacs process, just quick-started", so you expect a slightly
>> different behavior.
> 
> And I don't think that Emacs can actually be even close to satisfying
> the second paradigm, so there is little sense in doing a half-baked
> version of it and failing.

Well, there is no need to guess about that; I personally use emacsclient
exactly as I would use a full-blown editor.  In its current state, the
branch provides a good enough approximation to this paradigm that I
never notice I am not working in a local instance.

> I disagree.  If I have two frames side by side displaying the same
> buffer, it will be extremely confusing if using setenv in one frame
> will not have an effect on the other frame when calling commands with
> M-!.

Please try out the branch in practice.  Setenv without a frame parameter
has a global effect; it overrides all local environments, including the
ones created by future connections.

You are objecting to having different behaviour in different frames.
Aren't frame-local Elisp variables equally confusing to you?

>>> 	- Furthermore, to me it seems more consistent to have all
>>> 	environment variables be local than just a select few of them.
>> I don't find it important, but it doesn't seem to be bad either.
> 
> Disagree.  It makes shell buffers behave totally unpredictable across
> terminals (or even worse, frames): the sequence
> exit RET M-x shell RET
> usually gets rid of environment variables set within the shell
> session.  It would not be nice to have to guess what behavior will
> result.
> 
> AUCTeX, for example, contains code like the following:

AFAICT, apart from having to replace the process-environment reference
with '(environment)', the quoted code will work just fine on the
multi-tty branch.

> We don't want to have _any_ such code just break.

Really?  No incompatible change is ever allowed?  Not even in a new
major version?  I would like to have a second opinion on that from other
developers.

But if that's really the case, we can still make `process-environment'
have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have
all existing third-party Elisp code continue to work without changes.
Note that this would restrict the available designs considerably: all
environment variables would have to be terminal-local, with no
cherry-picking of DISPLAY.

-- 
Karoly



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

"Károly Lőrentey" <karoly@lorentey.hu> writes:

> David Kastrup wrote:

[...]

> You are objecting to having different behaviour in different frames.
> Aren't frame-local Elisp variables equally confusing to you?

Not as long as they are used for frame-specific purposes.  I would
consider it extremely confusing and annoying if suddenly every
variable became frame-locally.  And that is what you do with the
environment.

>> Disagree.  It makes shell buffers behave totally unpredictable across
>> terminals (or even worse, frames): the sequence
>> exit RET M-x shell RET
>> usually gets rid of environment variables set within the shell
>> session.  It would not be nice to have to guess what behavior will
>> result.
>> 
>> AUCTeX, for example, contains code like the following:
>
> AFAICT, apart from having to replace the process-environment
> reference with '(environment)', the quoted code will work just fine
> on the multi-tty branch.

"Apart from having to replace" means a regression.

>> We don't want to have _any_ such code just break.
>
> Really?  No incompatible change is ever allowed?  Not even in a new
> major version?  I would like to have a second opinion on that from
> other developers.

In my opinion, a new feature in connection with ttys should, if at
all, break only code that is also connected with ttys.  That is
expectable breakage.  The current implementation breaks pretty much
everything that works with environments.

> But if that's really the case, we can still make
> `process-environment' have a terminal-local binding (with, I assume,
> DEFVAR_KBOARD), and have all existing third-party Elisp code
> continue to work without changes.  Note that this would restrict the
> available designs considerably: all environment variables would have
> to be terminal-local, with no cherry-picking of DISPLAY.

See separate mail for some alternate designs and their respective
drawbacks.  I don't agree with that assessment.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Ken Raeburn]

On May 17, 2007, at 13:00, David Kastrup wrote:
> "Károly Lőrentey" <karoly@lorentey.hu> writes:
>> David Kastrup wrote:
>
>
>>> AUCTeX, for example, contains code like the following:
>>
>> AFAICT, apart from having to replace the process-environment
>> reference with '(environment)', the quoted code will work just fine
>> on the multi-tty branch.

If the code is maintained outside of the Emacs distribution, and  
doesn't drop Emacs 21/22 support immediately, aren't we looking at:

   (if (fboundp 'environment) (environment) process-environment)

or something like that?  Or a situation where multiple package  
developers conditionally defines "environment" if it's not already  
defined?

If we already had a major release or two with an "environment"  
function, and flag process-environment references as obsolete,  
telling people to just use "environment" might be more reasonable.

> "Apart from having to replace" means a regression.

It means a documented incompatible change, which is not necessarily  
the same thing.

>
>>> We don't want to have _any_ such code just break.
>>
>> Really?  No incompatible change is ever allowed?  Not even in a new
>> major version?  I would like to have a second opinion on that from
>> other developers.
>
> In my opinion, a new feature in connection with ttys should, if at
> all, break only code that is also connected with ttys.  That is
> expectable breakage.  The current implementation breaks pretty much
> everything that works with environments.

The more I read about it, the more it seems that the multi-tty code  
is changing the concept of an Emacs editing session, so I wouldn't  
expect the changes to be confined to tty handling.

I haven't decided yet what I think the multi-tty code should do  
regarding environments, but for years I was using gnudoit to invoke  
make-frame-on-display with $DISPLAY and a handful of frame settings  
derived from environment variables, combined with hacks to update the  
environment when switching frames, so I definitely think some  
environment variables should be easy to switch based on where you're  
currently coming from.  (I'm intentionally avoiding "client" and  
"frame" here.)  And if it's not all environment variables, then it  
should be an easily-changed list.

Now, though, I use the Mac version a lot, so remote access went  
away... until now; multi-tty seems like a good step in the right  
direction.  I'm still hoping for X11 as well as Carbon in the same  
process though. :-)  (Yes, I could use X11 on the Mac display, but  
the Carbon UI feels better integrated into the system.)

Ken

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Ken Raeburn <raeburn@raeburn.org> writes:

> The more I read about it, the more it seems that the multi-tty code
> is changing the concept of an Emacs editing session, so I wouldn't
> expect the changes to be confined to tty handling.

I think we should aim for _not_ changing the concept of an editing
session lightly.  This is the _last_ thing we should resort to, when
simpler solutions don't cut it.  And part of the reason is that we
can't really pull the personality of a single Emacs apart
consistently: Elisp does not really offer that degree of separation.

And "behaves almost as if...,spare us the details" is not something I
want to write down in a manual.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Károly Lőrentey]

[-- Attachment #1.1: Type: text/plain, Size: 2082 bytes --]

Ken Raeburn wrote:
> If the code is maintained outside of the Emacs distribution, and doesn't
> drop Emacs 21/22 support immediately, aren't we looking at:
> 
>   (if (fboundp 'environment) (environment) process-environment)
> 
> or something like that?  Or a situation where multiple package
> developers conditionally defines "environment" if it's not already defined?

Sadly, the situation was a little more complex than that.

> The more I read about it, the more it seems that the multi-tty code is
> changing the concept of an Emacs editing session, so I wouldn't expect
> the changes to be confined to tty handling.

A good example of this is that the multi-tty branch supports
simultaneous X and tty frames.  This feature is fundamentally
incompatible with any Lisp package that initializes window-system
dependent variables at load-time.  There are quite a few of those.
However, single-terminal users don't need to adapt code, so we can say
we are backwards compatible.

> I haven't decided yet what I think the multi-tty code should do
> regarding environments, but for years I was using gnudoit to invoke
> make-frame-on-display with $DISPLAY and a handful of frame settings
> derived from environment variables, combined with hacks to update the
> environment when switching frames, so I definitely think some
> environment variables should be easy to switch based on where you're
> currently coming from.  (I'm intentionally avoiding "client" and "frame"
> here.)  And if it's not all environment variables, then it should be an
> easily-changed list.

Excellent, so I'm not the only one with crazy concepts of local
environment variables. :-)

> Now, though, I use the Mac version a lot, so remote access went away...
> until now; multi-tty seems like a good step in the right direction.  I'm
> still hoping for X11 as well as Carbon in the same process though. :-) 

There were much too many toolkit #ifdefs for my taste.  But it has been
years since I looked at this, maybe it'd be feasible to do this now.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Stefan Monnier]

>> I would argue that an Emacs started with
>> DISPLAY=:0.0 emacs -display :1.0
>> should export an environment variable DISPLAY=:1.0 to its subprocesses
>> unless explicitly overridden.  This is somewhat complicated by the
>> situation given with
>> DISPLAY=:0.0 emacs -nw
>> In this case, I would still want to export :0.0 to subprocesses, and
>> in the case
>> DISPLAY=:0.0 emacs -nw -display :1.0
>> I would suggest a non-graphical instance of Emacs exporting a DISPLAY
>> variable of :1.0.

> I do not feel this is a particularly important issue, but sure.  Do
> people use -display often?  I usually simply change DISPLAY directly.

I use make-frame-on-display, and in this case it's a lot more important.

> But if that's really the case, we can still make `process-environment'
> have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have
> all existing third-party Elisp code continue to work without changes.

I'm not sure I understand: wouldn't this choice break the mentioned AUCTeX
code, then?
Also, while I'm here, why do you use frame-local bindings rather than
terminal-local bindings (maybe via a new terminal-local variable
`local-process-environment')?


        Stefan

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 1381 bytes --]

Stefan Monnier wrote:
>> I do not feel this is a particularly important issue, but sure.  Do
>> people use -display often?  I usually simply change DISPLAY directly.
> 
> I use make-frame-on-display, and in this case it's a lot more important.

Thankfully, it is easy to add support for it.

>> But if that's really the case, we can still make `process-environment'
>> have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have
>> all existing third-party Elisp code continue to work without changes.
> 
> I'm not sure I understand: wouldn't this choice break the mentioned AUCTeX
> code, then?

No, not at all.  The special environment may be set up for a single
client/terminal/whatever only, but I doubt the code switches frames
before it starts whatever subprocess it wants to start in the temporary
environment.

> Also, while I'm here, why do you use frame-local bindings rather than
> terminal-local bindings (maybe via a new terminal-local variable
> `local-process-environment')?

It is to enable separate environments in cases such as this:

xterm #1:
	$ export FOO=23
	$ emacsclient  // new X frame

xterm #2:
	$ export FOO=42
	$ emacsclient  // another one, on the same display

I find this nice, but others loathe it, so it probably isn't worth the
added complexity.  The issue is moot now anyway. :-)

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

> Stefan Monnier wrote:
>>> I do not feel this is a particularly important issue, but sure.  Do
>>> people use -display often?  I usually simply change DISPLAY directly.
>> 
>> I use make-frame-on-display, and in this case it's a lot more important.
>
> Thankfully, it is easy to add support for it.
>
>>> But if that's really the case, we can still make `process-environment'
>>> have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have
>>> all existing third-party Elisp code continue to work without changes.
>> 
>> I'm not sure I understand: wouldn't this choice break the mentioned AUCTeX
>> code, then?
>
> No, not at all.  The special environment may be set up for a single
> client/terminal/whatever only, but I doubt the code switches frames
> before it starts whatever subprocess it wants to start in the temporary
> environment.

Uh what?  This is code being run when Emacs is started up, namely when
custom-set-variables is called.  It would only work unchanged with
terminal-local process-environment if the non-terminal local tail of
process-environment was shared.  And that is a solution which has some
appeal because of its cleverness, but which is clearly too clever and
fragile to make for something one wants to document and use.

>> Also, while I'm here, why do you use frame-local bindings rather than
>> terminal-local bindings (maybe via a new terminal-local variable
>> `local-process-environment')?
>
> It is to enable separate environments in cases such as this:
>
> xterm #1:
> 	$ export FOO=23
> 	$ emacsclient  // new X frame
>
> xterm #2:
> 	$ export FOO=42
> 	$ emacsclient  // another one, on the same display
>
> I find this nice, but others loathe it, so it probably isn't worth the
> added complexity.  The issue is moot now anyway. :-)

I don't find it nice.  I don't see how the issue is moot unless I have
been quite convincing...

Note that two emacsclient processes (and possibly an emacs -nw)
started in the same tty will all share their settings (which I
consider reasonable), while starting, say, two emacsclient processes
in two different "screen" ttys will each give them their own settings.

I really feel we should restrict that to terminal-related variables by
default.  That's simple to understand and has no strong drawbacks that
I can see.

The one thing which I don't have a clear idea how to solve
consistently is what frames/windows/emacsclient sessions C-x # is
going to close and what buffers to discard.  But maybe that can be
solved with a single variable that associates a "session" with frames
and buffers.

Another possibility would be to diss C-x # completely.  However,
killing an associated buffer at least for the simplest use case

emacsclient filename
edit the file
C-x # or similar

seems desirable.  But I think that this issue is separate, and should
be.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 3677 bytes --]

David Kastrup wrote:
>>>> But if that's really the case, we can still make `process-environment'
>>>> have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have
>>>> all existing third-party Elisp code continue to work without changes.
>>> I'm not sure I understand: wouldn't this choice break the mentioned AUCTeX
>>> code, then?
>> No, not at all.  The special environment may be set up for a single
>> client/terminal/whatever only, but I doubt the code switches frames
>> before it starts whatever subprocess it wants to start in the temporary
>> environment.
> 
> Uh what?  This is code being run when Emacs is started up, namely when
> custom-set-variables is called.  

I'm sorry; I thought we are talking about a piece of code that let-binds
process-environment.   Clearly I was wrong.

If the code uses setenv to permanently set variables, then it would work
fine on multi-terminal sessions in my proposed terminal-local design.
For single-terminal users, the code will remain working no matter what
it does.

> It would only work unchanged with
> terminal-local process-environment if the non-terminal local tail of
> process-environment was shared.  

The actual underlying requirement is that `setenv' should affect all
existing and future terminals.  Tail-merging is an implementation choice.

> And that is a solution which has some
> appeal because of its cleverness, but which is clearly too clever and
> fragile to make for something one wants to document and use.

I disagree.  It is actually a very simple and predictable system that's
easy to explain.

>> I find this nice, but others loathe it, so it probably isn't worth the
>> added complexity.  The issue is moot now anyway. :-)
> 
> I don't find it nice.  I don't see how the issue is moot unless I have
> been quite convincing...

I have withdrawn the current implementation, and no longer want to push
for it.  I'm not interesting in arguing about its features any more.

> Note that two emacsclient processes (and possibly an emacs -nw)
> started in the same tty will all share their settings (which I
> consider reasonable), while starting, say, two emacsclient processes
> in two different "screen" ttys will each give them their own settings.

So what?  That's not a bug per se.

> I really feel we should restrict that to terminal-related variables by
> default.  That's simple to understand and has no strong drawbacks that
> I can see.

I say we must support both.  Clearly, people are divided on the issue.
Once we have greater experience with these features, we can standardize
on the right thing.  I doubt we will be able to convince each other now.

> The one thing which I don't have a clear idea how to solve
> consistently is what frames/windows/emacsclient sessions C-x # is
> going to close and what buffers to discard.  But maybe that can be
> solved with a single variable that associates a "session" with frames
> and buffers.

Frames are associated with their clients by their 'client parameter.
Buffers for files opened from the command line of emacsclient are
recorded in `server-clients'.  The behaviour of C-# should match
whatever is on the trunk.

> Another possibility would be to diss C-x # completely.  

I'm all for that, but I guess existing emacsclient users may complain,
and there is really no reason to remove it.

> However,
> killing an associated buffer at least for the simplest use case
> 
> emacsclient filename
> edit the file
> C-x # or similar
> 
> seems desirable.  But I think that this issue is separate, and should
> be.

OK, I agree.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>>>>> But if that's really the case, we can still make `process-environment'
>>>>> have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have
>>>>> all existing third-party Elisp code continue to work without changes.
>>>> I'm not sure I understand: wouldn't this choice break the mentioned AUCTeX
>>>> code, then?
>>> No, not at all.  The special environment may be set up for a single
>>> client/terminal/whatever only, but I doubt the code switches frames
>>> before it starts whatever subprocess it wants to start in the temporary
>>> environment.
>> 
>> Uh what?  This is code being run when Emacs is started up, namely when
>> custom-set-variables is called.  
>
> I'm sorry; I thought we are talking about a piece of code that let-binds
> process-environment.   Clearly I was wrong.

I was talking elsewhere of that.  The AUCTeX code was an example for
something that goes through the process-environment once and does
changes based on what it finds there.  This was basically an example
for code that would not work predictably with terminal-local values of
TEXINPUT*.  So it was making a case for having a global environment by
default.

> If the code uses setenv to permanently set variables, then it would
> work fine on multi-terminal sessions in my proposed terminal-local
> design.
>
> For single-terminal users, the code will remain working no matter
> what it does.
>
>> It would only work unchanged with terminal-local
>> process-environment if the non-terminal local tail of
>> process-environment was shared.
>
> The actual underlying requirement is that `setenv' should affect all
> existing and future terminals.  Tail-merging is an implementation
> choice.
>
>> And that is a solution which has some appeal because of its
>> cleverness, but which is clearly too clever and fragile to make for
>> something one wants to document and use.
>
> I disagree.  It is actually a very simple and predictable system
> that's easy to explain.

How come that I am arguing against my idea and you are arguing for it?

Ok, my main objection was that it is hard to conceive how to set up a
new terminal, namely where the shared tail starts.

If the shared tail, however, has its own symbol (as I actually did
propose, naming it global-process-environment), this is not hard to
do.

One would still have to do the following:
a) have a list of terminal-local variable names.  When the environment
is first read in, those are picked out from global-process-environment
and put into the terminal-local list instead.  This might have to
include unset variables in some form.  Probably as "DISPLAY=" since
for shells and applications, an empty variable and a deleted variable
are identical.  Just using "DISPLAY" alone might possibly be
misinterpreted by current readers of process-environment.

b) have setenv work also on unset variables, and make sure that it
does not clobber the global-process-environment situation.  This might
be non-trivial if one requests deletion of the first environment
variable from global-process-environment: this deletion would not work
on the shared tails.  So we might want to start
global-process-environment with a dummy entry that never gets removed.

Personally, I would consider this sort of implementation ugly.

However, it has two advantages: process-environment will tell the
whole story of the environment on a given terminal.  Old code will
very likely work.

And both the variants with terminal-local complete environments and
terminal-local partial environments can be implemented with just a few
lines of code.

So people will have a way to test both behaviors.  If at the end of
the testing one clear choice emerges, one might consider implementing
it in a less hackish manner that will leave the other choice out in
the cold.

>> Note that two emacsclient processes (and possibly an emacs -nw)
>> started in the same tty will all share their settings (which I
>> consider reasonable), while starting, say, two emacsclient
>> processes in two different "screen" ttys will each give them their
>> own settings.
>
> So what?  That's not a bug per se.

I was just explaining some consequences of the pure terminal-local (as
opposed to client-local) approach.  I don't consider it a bug, and so
much the better if you don't, either.

>> I really feel we should restrict that to terminal-related variables
>> by default.  That's simple to understand and has no strong
>> drawbacks that I can see.
>
> I say we must support both.  Clearly, people are divided on the
> issue.  Once we have greater experience with these features, we can
> standardize on the right thing.  I doubt we will be able to convince
> each other now.

Well, my "shared tail hack" offers a path to get experience with both
approaches.  Both approaches from you and me would require existing
code to be adapted (and possibly in different ways for each approach),
and the hack will probably spare us from most of that while the jury
is still out.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 292 bytes --]

David Kastrup wrote:
>> I disagree.  It is actually a very simple and predictable system
>> that's easy to explain.
> 
> How come that I am arguing against my idea and you are arguing for it?

Because I think your idea was good?

You can implement it if you want.

-- 
Karoly



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Miles Bader]

"Károly Lo\"rentey" <karoly@lorentey.hu> writes:
> AFAICT, apart from having to replace the process-environment reference
> with '(environment)', the quoted code will work just fine on the
> multi-tty branch.

BTW, independent of whether requiring a function to be used instead of
the variable is a good idea, I'm not sure the name (environment) is very
good -- the word "environment" is a pretty general one.

Why not call the function the same thing as the variable,
"process-environment"?  That makes the meaning of the function, and the
connection with the old variable, more obvious.

-Miles

-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Stefan Monnier]

>> Actually, the DISPLAY environment should behave that way even
>> without the use of emacsclient (when you use make-frame-on-display).
> Agreed.  But terminal-locality is all that is required (and in my
> opinion appropriate) here.  And it is _not_ a matter of "exporting"
> the start _environment_, but rather of exporting the start _settings_.
> I would argue that an Emacs started with
> DISPLAY=:0.0 emacs -display :1.0
> should export an environment variable DISPLAY=:1.0 to its subprocesses
> unless explicitly overridden.

Agreed, but only to the subprocesses started from frames displayed on
the :1.0 display.  I.e. alway export the DISPLAY on which the selected frame
is displayed.

> This is somewhat complicated by the
> situation given with
> DISPLAY=:0.0 emacs -nw
> In this case, I would still want to export :0.0 to subprocesses, and

In case the frame is not shown on a DISPLAY but on a tty, we should probably
just leave DISPLAY untouched.

> DISPLAY=:0.0 emacs -nw -display :1.0

I have no idea what "-display :1.0" means when passed along with "-nw", so
the behavior probably doesn't matter.

>> Yes, it's probably OK to use frames as an approximation of
>> "terminal" or "display" or "client".

> I disagree.

Actually you don't.  I was saying the above with the assumption that some
kind of inheritence was used so that all frames from the same
terminal/client/display shared the same value.  Which is the implementation
he described.  I don't know why he chose to use frame parameters rather than
terminal-local variables, but if there's a sound reason for it, I don't
think it's a terribly bad choice.

> We don't want to have _any_ such code just break.  It is _not_ code
> that is written sloppily or making unfounded assumptions.  It needs to
> access all environment variables obeying a given pattern and
> manipulate them.  It does this by looping through process-environment
> (more exactly, a copy of it so that the exact implementation of setenv
> can't interfere with the loop).  This is completely straightforward,
> not related to multi-tty-ness at all, and we don't want such usage to
> break.

>From what Karoly says, the above is not fundamentally broken by his code,
except for the need to use the `environment' function.

>> So I'd leave it as a choice that can be determined by the
>> implementation.
> Guffah.  Uh, the implementation will, _of_ _course_, determine _every_
> choice.  That's why we are discussing it.

In my neck of the woods (language theory), when something is "determined by
the implementation", it means that it's specifically left as undetermined by
the spec (e.g. order of evaluation of arguments in C or Scheme).  So it's
not "of course".


        Stefan

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 2037 bytes --]

Stefan Monnier wrote:
>> 	- At least some environment variables _must_ behave locally; if not
>> 	  client-locally, then at least terminal-locally.  DISPLAY is perhaps
>> 	  the most obvious example.  X clients such as xdvi started from Emacs
>> 	  must appear on the display the user currently works on.
> 
> Actually, the DISPLAY environment should behave that way even without the
> use of emacsclient (when you use make-frame-on-display).

Hm, this is a good point.

>> 	  This is an important feature for multi-tty users and I would like
>> 	  to keep it supported.  Similar variables include SSH_AUTH_SOCK,
>> 	  GPG_AGENT_INFO, AGENT_SOCKET, LANG, LC_*, and basically anything
>> 	  that may be different from login session to login session.
> 
> I don't think the vars you list are particularly important.  Which version
> of those vars to use (the one from the emacsclient process or from the main
> Emacs process) may depend from case to case.  So either choice is
> probably OK.

Well, I do agree that having a local DISPLAY is the essential feature here.

> I tend to think of emacsclient as "connect to the main Emacs process", so
> I tend to expect it to work in the environment of the main Emacs process.
> You seem to think of it as "pretend you're a normal Emacs process, just
> quick-started", so you expect a slightly different behavior.

The new emacsclient behaviour does make it easy to forget that you are
connecting to a separate Emacs process that runs in the background,
particularly when the main Emacs is not visible.  But I feel both
viewpoints can be catered for; "emacsclient --current-frame" reverts to
Emacs 22 behaviour, and should not touch the environment.

>> 	- Furthermore, to me it seems more consistent to have all
>> 	  environment variables be local than just a select few of them.
> 
> I don't find it important, but it doesn't seem to be bad either.  So I'd
> leave it as a choice that can be determined by the implementation.

OK.

-- 
Károly



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Richard Stallman]

    The client-local environment list is shared between frames that were created in
    the same Emacsclient session.  The environment list is stored in a single
    frame's environment parameter; the other frames' environment is set to this
    frame.

That seems to privilege the first frame of a given client in a way
that seems arbitrary.  And what happens if that frame gets deleted?
Do you pick another one to be the canonical representative of that
client?  It seems a bit kludgy.

That doesn't necessarily mean I object.  This could be the best
method.  However, I would not describe this as a "client-local"
variable.  The variable bindings are still frame-local, even though
the environment is per-client.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 1332 bytes --]

Richard Stallman wrote:
>     The client-local environment list is shared between frames that were created in
>     the same Emacsclient session.  The environment list is stored in a single
>     frame's environment parameter; the other frames' environment is set to this
>     frame.
> 
> That seems to privilege the first frame of a given client in a way
> that seems arbitrary.  And what happens if that frame gets deleted?
> Do you pick another one to be the canonical representative of that
> client? It seems a bit kludgy.

Yes, delete-frame has special code to deal with this.  I agree it's a
kludge.

> That doesn't necessarily mean I object.  This could be the best
> method.  However, I would not describe this as a "client-local"
> variable.  The variable bindings are still frame-local, even though
> the environment is per-client.

I must clarify that there are no frame-local Emacs lisp bindings for the
environment, just frame parameters.  But otherwise you're right.

A cleaner solution would be to make server.el's client parameters (the
variable `server-clients') available to callproc.c, and use them directly.

People don't like the concept of client-local environments in general,
so I think it would be best to choose some other way to handle
environments instead.

-- 
Károly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

> No, my memory has failed me.  I had a patch implementing the above
> design, but what we currently have in the tree is something more
> complex: environment variables are neither frame-, nor
> terminal-local, but rather client-local.

I have seen on the archives of the multi-tty list and its README that
the implementation has went through several different ideas.  So quite
a bit of work has been invested already, and there is obviously not
going to be much enthusiasm for scrapping it.

However, at the current point of time the documentation seems to be
restricted to what is actually present in the code: it remains an open
task to write user level documentation (the Emacs manual) and
programmer level documentation (the Elisp manual).

This is actually a good thing because it provides sort of a litmus
test for interface usability and design quality: if one feels
uncomfortable casting existing behavior into a clear description and
instead is tempted to write something like "don't bother about it, it
will magically do the right thing", then something is amiss.

So we can first agree on what kind of interface we would not feel
ashamed putting into the manuals, and then adapt the code to it.

> The client-local environment list is shared between frames that were
> created in the same Emacsclient session.  The environment list is
> stored in a single frame's environment parameter; the other frames'
> environment is set to this frame.  (See `frame-with-environment'.)
> Frames not originating from an emacsclient session get the
> environment of the Emacs process itself, by the same
> mechanism. (Note that when the user exits emacsclient, all frames
> belonging to that client are automatically deleted.)

I think that "client-local" is a complication we really don't want to
introduce.  It is clear that frames on different servers or ttys will
have to have different personalities regarding the terminal, and in
particular regarding the exported value of DISPLAY to processes.  The
situation is less clear about values like TERM: however, exporting
them (or their equivalent) seems reasonable when we are talking about
MSDOS where a started subprocess will run in the tty of the actual
Emacs and talk to it bypassing Emacs' redirection stdout/stderr.

There is some sort of minor precedent to exporting a terminal-adapted
environment.  Namely we have

(defun comint-exec-1 (name buffer command switches)
  (let ((process-environment
	 (nconc
	  ;; If using termcap, we specify `emacs' as the terminal type
	  ;; because that lets us specify a width.
	  ;; If using terminfo, we specify `dumb' because that is
	  ;; a defined terminal type.  `emacs' is not a defined terminal type
	  ;; and there is no way for us to define it here.
	  ;; Some programs that use terminfo get very confused
	  ;; if TERM is not a valid terminal type.
	  ;; ;; There is similar code in compile.el.
	  (if (and (boundp 'system-uses-terminfo) system-uses-terminfo)
	      (list "TERM=dumb" "TERMCAP="
		    (format "COLUMNS=%d" (window-width)))
	    (list "TERM=emacs"
		  (format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width))))
	  (unless (getenv "EMACS")
	    (list "EMACS=t"))
	  (list (format "INSIDE_EMACS=%s,comint" emacs-version))
	  process-environment))

However, this holds for just a particular environment provided by
Emacs itself.

In a similar vein, we have
(defun term-exec-1 (name buffer command switches)
  ;; We need to do an extra (fork-less) exec to run stty.
  ;; (This would not be needed if we had suitable Emacs primitives.)
  ;; The 'if ...; then shift; fi' hack is because Bourne shell
  ;; loses one arg when called with -c, and newer shells (bash,  ksh) don't.
  ;; Thus we add an extra dummy argument "..", and then remove it.
  (let ((process-environment
	 (nconc
	  (list
	   (format "TERM=%s" term-term-name)
	   (format "TERMINFO=%s" data-directory)
	   (format term-termcap-format "TERMCAP="
		   term-term-name term-height term-width)
	   ;; We are going to get rid of the binding for EMACS,
	   ;; probably in Emacs 23, because it breaks
	   ;; `./configure' of some packages that expect it to
	   ;; say where to find EMACS.
	   (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
	   (format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
	   (format "LINES=%d" term-height)
	   (format "COLUMNS=%d" term-width))
	  process-environment))

The situation for emacsclient is somewhat different because we want to
have _everything_ affected that gets called via either call-process or
start-process.

Here is how to approach this with a "minimally invasive hack" (namely
something which works with most existing code, but which one would not
really want to ever write into a manual): make process-environment a
terminal-local variable.  It will be an nconc of terminal local
environment variables and `global-process-environment', the
environment Emacs got started with.  setenv uses setcar to manipulate
existing environment variables, and appends (instead of prepends) them
to process-environment when they don't yet exist.  That way,
environment changes will be global unless a terminal-local environment
variable already exists.

Ok, this is just not feasible: it is too much of an ugly hack (lists
with shared tails are not nice to understand, and when the heads are
stored in terminal-local variables, we gain an additional level of
ugliness).

So we have to see how we are actually going to work with this and take
a look at existing code.  It turns out that quite a few functions
let-bind process-environment to something nconc-ed together starting
with current value of process-environment.  There are also several
times where first process-environment is let-bound to a copy-sequence
of its previous binding, then setenv is being applied in order to
manipulate this copy, and finally a process gets started while the
let-binding is still in effect.

Also, currently the _default_ way to search through the current
environment without knowing what to look for in advance, is to use
process-environment.

If we take a look at how setenv/getenv/process-environment are
actually used, some patterns emerge:

While getenv and looking through process-environment are more or less
used interchangeably, we have (in non-multitty Emacs) very few
occurences where process-environment actually gets written to:

find /rep/emacs -type f -name \*.el -print0 | xargs -0 -e grep -nH -e "(setq process-environment"
/rep/emacs/lisp/env.el:152:		   (setq process-environment (delq (car scan)
/rep/emacs/lisp/env.el:159:	      (setq process-environment
/rep/emacs/lisp/startup.el:398:		 (setq process-environment

And that is it.  In all other cases, it is usually let-bound to a copy
of itself, or something nconc-ed or concatenated to in front of
itself.  This can occur in combination with setenv.  When a
let-binding is employed together with copy-sequence and setenv, the
expectation is that the effect will be completely temporarily.

So those are the semantics we want to keep if we possibly can.  We
also would want to have terminal-local environment variables (like
"DISPLAY") appear in process-environment.  For some reason it would
seem that manipulation of process-environment happens almost
exclusively through setenv.

So one solution will be: have process-environment _reflect_ the
current environment but not determine it.  There is a problem with
that: letting current-environment to a copy of itself is supposed to
make setenv register changes, but only temporarily.

So here are a few options:

a) make process-environment a terminal-local R/W variable.  Notice
that this does _not_ imply that anything but the first element of the
list can't be actually shared among the lists.  As long as
manipulation of process-environment happens with setenv, we are off
ok.  Changes of existing values can be done with setcar, so that
terminal-local environment variables (at the start of the list) will
stay terminal-local and vice versa.

Disadvantage: if somebody manipulates process-environment with setq
and a copy, the variable set for this terminal will _then_ become
completely detached from that of other terminals.  Which is actually
what Károly would prefer...

b) make process-environment a global variable that can be manipulated
like the user wants.  However, whenever call-process or similar are
invoked, the actual environment passed into the called process has a
set of terminal-local environment settings prepended.  This means that
M-x setenv RET DISPLAY RET will be reflected in the
process-environment of all terminals, but actually called processes
will have a different setting.  To mitigate the unintuitiveness of
this approach, setenv could also, where appropriate, record the
setting into the terminal-local settings which default to be the
active value at the terminal, but could be shadowed for this purpose
so that setting them becomes possible.  However, this would mean that
setenv used on a let-bound process-environment would, after all, leave
a lasting effect on the environment.

So one should really have to use a special setenv variant to set the
terminal-specific overriding environment: the normal setenv should not
go there.

For that reason, we want to keep the extent of the terminal-specific
environment to a bare minimum.

If people have to learn to use special commands or command variants
for setting _those_ (and only those) environment variables intimately
connected with the tty, I suppose we can make the issue understood.

It will be a nuisance and might break those programs that manipulate
the environment variables accessing the tty, but only those.

We can provide a warning if people use setenv on such variables
interactively.

> 	- For the user, there is a strong sense of connection between
> 	an emacsclient instance and its set of frames.  If emacsclient
> 	exits, then its frames are deleted and vice versa.
>
> 	C-x C-c kills emacsclient, not the entire Emacs process.  All
> 	this feels very natural and fits a range of common use-cases,
> 	particularly the ones involving quick editing jobs from the
> 	command prompt.  (These are the ones for which Emacs was so
> 	infamously not well suited before.)
>
> 	  This means that having a different set of variables from frame to
> 	  frame does not normally seem inconsistent or unpredictable to the
> 	  user.

I am opposed to claiming to create an illusion that we can't actually
provide.  kill-emacs should work as before.  However, one might
consider providing a different command kill-terminal-group or similar
which would instead be bound to C-x C-c.

> 	- Furthermore, to me it seems more consistent to have all
> 	environment variables be local than just a select few of them.

But it will pretty much break every Lisp program involved with the
environment.  That price is too high.  And it will also cause a lot of
inconsistencies that can't really be explained well to the user, like
"compile" behaving differently in windows that are side-by-side.


> 	- Client-local environments mean that two separate emacsclient instances 	  on
> the same terminal can have different environments:
>
> 		$ FOO=23 emacsclient
> 			(getenv "FOO") ==> 23
> 		C-z
> 		$ FOO=42 emacsclient            # Other frame is still alive,
> 			(getenv "FOO") ==> 42   # with a value of 23.
>
>           This is a corner case that deepens the illusion of emacsclient being
> 	  a real standalone editor.

But since we can maintain that illusion at a shallow level at best and
since it will get in the way of trying to actually access variables,
it is not a good idea to aim for it.

> 	  It is not an important feature, although it did often come
> 	  useful for me, particularly with long emacsclient sessions
> 	  for different tasks, but sharing a single X display.

I don't see how.

> 	  Terminal-local environments would less complete, but still
> 	  good enough to be usable without many problems.

That's what I would aim for, and only for those variables that are
indeed terminal-dependent.

> 	- The behaviour of M-x shell and similar packages is mostly
> 	irrelevant here.

Disagree.  "Similar packages" pretty much include _all_ packages that
would have reason to access the environment, so _certainly_ those
packages are relevant to the issue.

> If you find client-local environments unacceptably ugly, I can
> update and submit my patch for simple terminal-local environments.
> The local environment then becomes a simple terminal parameter,
> initialized when the terminal is created.  This is a much simpler
> solution that retains much of the feature set of the current design.

I think we should aim for the simplest solution that we can reasonably
explain.  My favorite solution, as explained above, still has the
disadvantage that setenv in a single-terminal environment will still
behave differently from before for a strictly limited set of
variables.  I don't see how we could avoid this while maintaining
reasonable upwards compatibility.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Stefan Monnier]

> particular regarding the exported value of DISPLAY to processes.  The
> situation is less clear about values like TERM: however, exporting
> them (or their equivalent) seems reasonable when we are talking about
> MSDOS where a started subprocess will run in the tty of the actual
> Emacs and talk to it bypassing Emacs' redirection stdout/stderr.

Actually, for a short time the CVS code scrapped the $TERM environment
variable, since the terminal is not accessible to Emacs's
subprocesses anyway.  The fundmental idea was agreed upoon, was the patch
was reverted because I didn't test it enough: the TERM var was scrapped too
early.  E.g. it was scrapped before it got a chance to be used to load the
term/$TERM.el file, and also before reading the user's .emacs file where
some users use $TERM for one reason or another.
In any case the conclusion was that the $TERM var should be scrapped
much later.  Probably by separating the "environment inherited" (where TERM
would be kept for the whole duration of the Emacs session) from the
"environment passed down to subprocesses".

I didn't know that the MS-DOS port does make Emacs's terminal available
directly to its subprocesses, but that can be easily accomodated.

This brings us back to multi-tty's handling of environments.  I think
breaking backward compatibility to some extent is unavoidable because there
needs to be several different notions of environments, such as the two
mentioned above.  I think it's a good opportunity to think hard about what
setenv/getenv/process-environment should really do and how to
extend/replace them.  Your message was a good start in that direction, but
I think we should first try to imagine "what should things be like,
regardless of backward compatibility" and only afterwards try to see how to
best map it to the old interface.


        Stefan

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I didn't know that the MS-DOS port does make Emacs's terminal
> available directly to its subprocesses, but that can be easily
> accomodated.

I don't know about the port actually, and it is not a matter of making
the terminal available as much as the subprocess just taking it, I
think.  The screen memory is there, and the BIOS routine accessing it
are there.  How is Emacs going to keep a subprocess from using those?

> This brings us back to multi-tty's handling of environments.  I
> think breaking backward compatibility to some extent is unavoidable
> because there needs to be several different notions of environments,
> such as the two mentioned above.

To some extent, yes.  I am fine with breaking previous
terminal-related code as much as required.  I am less fine with
breaking anything environment-related.

> I think it's a good opportunity to think hard about what
> setenv/getenv/process-environment should really do and how to
> extend/replace them.  Your message was a good start in that
> direction, but I think we should first try to imagine "what should
> things be like, regardless of backward compatibility" and only
> afterwards try to see how to best map it to the old interface.

For everything that is not terminal-related, nothing but a single
environment makes sense, I think: basically all code manipulating
environments assumes this, and there is quite a bit of code that might
not even get run in a terminal.

Anyway, when we split environments in _any_ way, it means that
processes will have to keep an idea of what terminal they belong to so
that this terminal can be reselected in their process sentinels and
filter functions: it is important that the process sentinel can rely
on having the same environment variables for further processes started
from there.

Maybe this already is implemented, and maybe even in trunk: no idea.

Also the environment situation seems to be ugly with regard to code
being run from timers: maybe one should refrain from starting
terminal-dependent processes from timers.  Not being allowed to start
any processes seems like overkill, but we can't rely on the
terminal-related parts of it to stay around, can we?

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Stefan Monnier]

>> I didn't know that the MS-DOS port does make Emacs's terminal
>> available directly to its subprocesses, but that can be easily
>> accomodated.

> I don't know about the port actually, and it is not a matter of making
> the terminal available as much as the subprocess just taking it, I
> think.

You're nitpicking at my choice of word.  It deosn't matter whether Emacs
*makes* the terminal available" or whether the terminal just *is* available
by virtue of the "OS".  The point is just that this is a special case that
can be easily accomodated (by not scrapping the TERM var in that case).

> For everything that is not terminal-related, nothing but a single
> environment makes sense, I think.

Might be.  But both the TERM and the DISPLAY variables at least need to be
adjusted in subprocesses compared to what they were in Emacs's
own environment.  This is true regardless of multi-tty.

And furthermore, for the TERM var, we both want to change it in subprocesses
and keep it for reference.  So (still ignoring mutli-tty), it would make
sense to so something such as introduce a new var (could be read-only) say
`initial-environment'.  `process-environment' could start as empty and the
environment passed to subprocesses would be the combination of
`process-environment' and `initial-environment', where `process-environment'
entries would take precedence over entries from `initial-environment'.

This would break your AUCTeX code in a similar way to the current multi-tty
code, but again, it's easy  to fix: just loop over `initial-environment'
instead of `process-environment'.

For multi-tty, additionally to that, we could add a new terminal-local var
(could also be read-only, for all I know) called `terminal-environment'
which contains the environment inherited from a particular client.  Then we
could add a `terminal-environment-filter' variable which determines which
environment variables are taken from `initial-environment' and which from
`terminal-environment' when building the environment of a new subprocess.

If you want this variable to be client-local instead of terminal-local, then
just make it a global alist associating clients to their environments.


        Stefan

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> For everything that is not terminal-related, nothing but a single
>> environment makes sense, I think.
>
> Might be.  But both the TERM and the DISPLAY variables at least need
> to be adjusted in subprocesses compared to what they were in Emacs's
> own environment.  This is true regardless of multi-tty.

Agreed.  The TERM adjustment in some of Emacs' code currently is done
using
(let ((process-environment (copy-sequence process-environment)))
  (setenv "TERM" ...

The point more or less being that this change is not really to the
current tty, but to the exported tty.

> And furthermore, for the TERM var, we both want to change it in
> subprocesses and keep it for reference.  So (still ignoring
> mutli-tty), it would make sense to so something such as introduce a
> new var (could be read-only) say `initial-environment'.
> `process-environment' could start as empty and the environment
> passed to subprocesses would be the combination of
> `process-environment' and `initial-environment', where
> `process-environment' entries would take precedence over entries
> from `initial-environment'.

My proposal was more or less the same, but with `process-environment'
and `initial-environment' being named `terminal-environment' and
`process-environment', respectively.

> This would break your AUCTeX code in a similar way to the current
> multi-tty code, but again, it's easy to fix: just loop over
> `initial-environment' instead of `process-environment'.

Which is easier if `initial-environment' is called
`process-environment'...

> For multi-tty, additionally to that, we could add a new
> terminal-local var (could also be read-only, for all I know) called
> `terminal-environment' which contains the environment inherited from
> a particular client.  Then we could add a
> `terminal-environment-filter' variable which determines which
> environment variables are taken from `initial-environment' and which
> from `terminal-environment' when building the environment of a new
> subprocess.

Well, the new idea here is that you want to keep the whole environment
from the client around in some manner even though we might choose not
to use it.

If we ultimately decide to only bother with named terminal-relevant
variables, we can save ourselves the bandwidth to store everything.

But until we have converged to an opinion about that, wasting the
bandwidth and storage in the version to be merged into the trunk does
not seem to be a concern, so this proposal seems like a good idea at
the moment.

> If you want this variable to be client-local instead of
> terminal-local, then just make it a global alist associating clients
> to their environments.

The problem is the following: if we get another client into an
existing terminal, do we update terminal-environment or not?

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Stefan Monnier]

>>> For everything that is not terminal-related, nothing but a single
>>> environment makes sense, I think.
>> 
>> Might be.  But both the TERM and the DISPLAY variables at least need
>> to be adjusted in subprocesses compared to what they were in Emacs's
>> own environment.  This is true regardless of multi-tty.

> Agreed.  The TERM adjustment in some of Emacs' code currently is done
> using
> (let ((process-environment (copy-sequence process-environment)))
>   (setenv "TERM" ...

This code is fine.  The problem comes fro code which does *not* touch TERM,
and hence the subprocess thinks it's running in an `xterm' (for example)
whereas it's really running on an absolutely dumb "terminal", so it may
choose to use color escapes and things like that where they're
not appropriate.

> The point more or less being that this change is not really to the
> current tty, but to the exported tty.

This is also valid for subprocess run without a tty.

>> And furthermore, for the TERM var, we both want to change it in
>> subprocesses and keep it for reference.  So (still ignoring
>> mutli-tty), it would make sense to so something such as introduce a
>> new var (could be read-only) say `initial-environment'.
>> `process-environment' could start as empty and the environment
>> passed to subprocesses would be the combination of
>> `process-environment' and `initial-environment', where
>> `process-environment' entries would take precedence over entries
>> from `initial-environment'.

> My proposal was more or less the same, but with `process-environment'
> and `initial-environment' being named `terminal-environment' and
> `process-environment', respectively.

Right.

>> This would break your AUCTeX code in a similar way to the current
>> multi-tty code, but again, it's easy to fix: just loop over
>> `initial-environment' instead of `process-environment'.

> Which is easier if `initial-environment' is called
> `process-environment'...

Well, the opposite is true for existing code that adds stuff to
`process-environment'.  I believe such code is a lot more widespread.

>> If you want this variable to be client-local instead of
>> terminal-local, then just make it a global alist associating clients
>> to their environments.

> The problem is the following: if we get another client into an
> existing terminal, do we update terminal-environment or not?

If you think this is a problem, then you want terminal-environment to be
client-local rather than terminal-local.  You may then want to call it
client-environment-alist.  It's not like it's difficult to implement: it's
all managed in server.el, except the "lookup through `foo-filter'" which
might be done in the C code when building the environment of
a new subprocess.


        Stefan

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> For everything that is not terminal-related, nothing but a single
>>>> environment makes sense, I think.
>>> 
>>> Might be.  But both the TERM and the DISPLAY variables at least need
>>> to be adjusted in subprocesses compared to what they were in Emacs's
>>> own environment.  This is true regardless of multi-tty.
>
>> Agreed.  The TERM adjustment in some of Emacs' code currently is done
>> using
>> (let ((process-environment (copy-sequence process-environment)))
>>   (setenv "TERM" ...
>
> This code is fine.

>> Which is easier if `initial-environment' is called
>> `process-environment'...
>
> Well, the opposite is true for existing code that adds stuff to
> `process-environment'.  I believe such code is a lot more
> widespread.

If the way this addition is done is by virtue of "setenv", we can
cater for it.  And this only concerns variables which are treated
terminal-specifically.

> If you think this is a problem, then you want terminal-environment
> to be client-local rather than terminal-local.  You may then want to
> call it client-environment-alist.  It's not like it's difficult to
> implement: it's all managed in server.el, except the "lookup through
> `foo-filter'" which might be done in the C code when building the
> environment of a new subprocess.

As written in a separate posting: I'd prefer not to have different
notions of terminal-local and client-local.  But it may be possible to
make both the same by letting terminal-locality include the client as
a differentiating factor as well.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Stefan Monnier]

>>> Which is easier if `initial-environment' is called
>>> `process-environment'...
>> Well, the opposite is true for existing code that adds stuff to
>> `process-environment'.  I believe such code is a lot more
>> widespread.
> If the way this addition is done is by virtue of "setenv", we can
> cater for it.

I was thinking of (let ((process-environment (cons FOO process-environment)))

> As written in a separate posting: I'd prefer not to have different
> notions of terminal-local and client-local.

Yes, the argument made sense.  I think we had better try to stick to only
one such notion.  Since we already have the notion of terminal, we should
just stick with it.  We will probably want to define that we can have two
different "pty1" terminals (corresponding to two different emacclient
sessions).  I think it'd be more difficult to do the same with machine:0.0
displays, but if we want and can do that, I don't see why I'd oppose it.


        Stefan

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Which is easier if `initial-environment' is called
>>>> `process-environment'...
>>> Well, the opposite is true for existing code that adds stuff to
>>> `process-environment'.  I believe such code is a lot more
>>> widespread.
>> If the way this addition is done is by virtue of "setenv", we can
>> cater for it.
>
> I was thinking of (let ((process-environment (cons FOO
> process-environment)))

Do we actually have code like this around?  It would appear somewhat
strange in pre-multitty since it more or less assumes that
process-environment can contain multiple mentions of environment
variables with only the first taking effect.  At my current computer,
I have multitty checked out.

I suppose I should try setting up some other system that keeps
multiple branches around concurrently.

>> As written in a separate posting: I'd prefer not to have different
>> notions of terminal-local and client-local.
>
> Yes, the argument made sense.  I think we had better try to stick to
> only one such notion.  Since we already have the notion of terminal,
> we should just stick with it.  We will probably want to define that
> we can have two different "pty1" terminals (corresponding to two
> different emacclient sessions).  I think it'd be more difficult to
> do the same with machine:0.0 displays, but if we want and can do
> that, I don't see why I'd oppose it.

We'll need some good strategy for making xterm-mouse-mode and
tmouse-mode be able to show useful behavior.  Never mind backwards
compatibility for those: we need _some_ way where they do what can be
considered "works as expected" without too many contortions.

I am not sure whether it would help or not merging multitty into the
trunk for this.  I don't want people to waste time on hacking things
to work with interfaces of multitty that will certainly change, but at
some point of time we will need to gather extensive experience, and
that means that we should stay open to the possibility of design
changes even when the stuff is in trunk.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
>> I was thinking of (let ((process-environment (cons FOO
>> process-environment)))
>
> Do we actually have code like this around?t.

Yes.

> It would appear somewhat strange in pre-multitty since it more or
> less assumes that process-environment can contain multiple mentions of
> environment variables with only the first taking effect

This usage style is explicitly supported by the C code which exports
process-enviroment -- it only exports the first occurance of any given
environment variable.

Indeed, given this support, it's a much more elegant and efficient idiom
for elisp than copy+setenv....

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> David Kastrup <dak@gnu.org> writes:
>>> I was thinking of (let ((process-environment (cons FOO
>>> process-environment)))
>>
>> Do we actually have code like this around?t.
>
> Yes.
>
>> It would appear somewhat strange in pre-multitty since it more or
>> less assumes that process-environment can contain multiple mentions of
>> environment variables with only the first taking effect
>
> This usage style is explicitly supported by the C code which exports
> process-enviroment -- it only exports the first occurance of any given
> environment variable.
>
> Indeed, given this support, it's a much more elegant and efficient idiom
> for elisp than copy+setenv....

Hm, maybe the shared tails idea will indeed be the most expedient idea
for playing with several concepts.  It appears to do the trick for
most use cases.

The only thing that does not really look nice is deleting the first
element of the shared tail global-process-environment: one would have
to do the deletion the hard way, by doing something like

(setq tail (member "WHATEVER" process-environment))
(setcar tail (cadr tail))
(setcdr tail (cddr tail))

Which does not work when WHATEVER is the last environment variable...
Maybe one should start global-process-environment with a dummy entry.
Ugly.

Is there any way to check whether process-environment is
terminal-local (the global binding), or let-bound?  Maybe a solution
can be manufactured around that.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Richard Stallman]

    The only thing that does not really look nice is deleting the first
    element of the shared tail global-process-environment: one would have
    to do the deletion the hard way, by doing something like

    Maybe one should start global-process-environment with a dummy entry.

I think a dummy link whose car is nil would be an elegant solution.

    Is there any way to check whether process-environment is
    terminal-local (the global binding), or let-bound?  Maybe a solution
    can be manufactured around that.

That would be extremely un-Lispy.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The only thing that does not really look nice is deleting the first
>     element of the shared tail global-process-environment: one would have
>     to do the deletion the hard way, by doing something like
>
>     Maybe one should start global-process-environment with a dummy entry.
>
> I think a dummy link whose car is nil would be an elegant solution.

An empty string, perhaps.  I severely doubt that most loops through
process-environment will be prepared to encounter a non-string
argument (doing string-match on all encountered elements would be sort
of a natural operation).  An empty string, in contrast, would probably
not do much harm, I suppose.

>     Is there any way to check whether process-environment is
>     terminal-local (the global binding), or let-bound?  Maybe a
>     solution can be manufactured around that.
>
> That would be extremely un-Lispy.

Well, yes.  I am sifting through mediocre and bad solutions here.  I'd
prefer straightforward elegant and mostly backward-compatible
solutions, but those are not easy to come by.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Richard Stallman]

    An empty string, perhaps.  I severely doubt that most loops through
    process-environment will be prepared to encounter a non-string
    argument (doing string-match on all encountered elements would be sort
    of a natural operation).  An empty string, in contrast, would probably
    not do much harm, I suppose.

If there are many such loops, and changing them would be hard, this
might be an important factor.  Otherwise, we should do the cleanest
thing, and use nil, and change those loops.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     An empty string, perhaps.  I severely doubt that most loops through
>     process-environment will be prepared to encounter a non-string
>     argument (doing string-match on all encountered elements would be sort
>     of a natural operation).  An empty string, in contrast, would probably
>     not do much harm, I suppose.
>
> If there are many such loops, and changing them would be hard, this
> might be an important factor.

The problem is that such loops are the _obvious_ thing for
manipulating process-environment.  So we need not only bother about
code inside of Emacs, but also in external packages.

For example, AUCTeX contains

(defun preview-set-texinputs (&optional remove)
  "Add `preview-TeX-style-dir' into `TEXINPUTS' variables.
With prefix argument REMOVE, remove it again."
  (interactive "P")
  (let ((case-fold-search nil)
	(preview-TeX-style-dir (preview-TeX-style-cooked))
	pattern)
    (if remove
	(progn
	  (setq pattern (concat "\\`\\(TEXINPUTS[^=]*\\)=\\(.*\\)"
				(regexp-quote preview-TeX-style-dir)))
	  (dolist (env (copy-sequence process-environment))
	    (if (string-match pattern env)
		(setenv (match-string 1 env)
			(and (or (< (match-beginning 2) (match-end 2))
				 (< (match-end 0) (length env)))
			     (concat (match-string 2 env)
				     (substring env (match-end 0))))))))
      (setq pattern (regexp-quote preview-TeX-style-dir))
      (dolist (env (cons "TEXINPUTS=" (copy-sequence process-environment)))
	(if (string-match "\\`\\(TEXINPUTS[^=]*\\)=" env)
	    (unless (string-match pattern env)
	      (setenv (match-string 1 env)
		      (concat preview-TeX-style-dir
			      (substring env (match-end 0))))))))))

This will throw an error if process-environment contains non-strings.
I would not consider this untypical or unnatural.

> Otherwise, we should do the cleanest thing, and use nil, and change
> those loops.

If code has to specifically cater for nil, pretty much the whole point
of the shared tail construct (namely not having to change existing
code) is gone.  We could then equally well just have two separate
variables for the shared and separate parts of the environment.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Richard Stallman]

    The problem is that such loops are the _obvious_ thing for
    manipulating process-environment.  So we need not only bother about
    code inside of Emacs, but also in external packages.

It surprises me that you want to look for more than one envvar at a
time.  If all the programs that do this will react well to using the null
string, I guess we can use the null string.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The problem is that such loops are the _obvious_ thing for
>     manipulating process-environment.  So we need not only bother about
>     code inside of Emacs, but also in external packages.
>
> It surprises me that you want to look for more than one envvar at a
> time.

In this particular case, there are environment variables of the form
TEXINPUTS
TEXINPUTS.latex
TEXINPUTS.pdftex
TEXINPUTS.whatever

that are use by the various TeX executables, first the variable with
the program in its name, then the general variable as a fallback.  So
I need to change all of the variables with a certain pattern.

> If all the programs that do this will react well to using the null
> string, I guess we can use the null string.

"All" is probably an oversimplification.  However, programs should be
prepared to some degree to deal with non-trivial strings here (it is
possible to export shell functions, for example), so the absence of
the equals sign is probably something that will trip up quite fewer
programs than a non-string element would.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 18 May 2007 09:36:48 +0200
> Cc: Andreas Schwab <schwab@suse.de>, Dan Nicolaescu <dann@ics.uci.edu>,
> 	Karoly Lorentey <karoly@lorentey.hu>, joakim@verona.se, emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > > I think that "client-local" is a complication we really don't want to
> > > introduce.  It is clear that frames on different servers or ttys will
> > > have to have different personalities regarding the terminal, and in
> > > particular regarding the exported value of DISPLAY to processes.  The
> > > situation is less clear about values like TERM: however, exporting
> > > them (or their equivalent) seems reasonable when we are talking about
> > > MSDOS where a started subprocess will run in the tty of the actual
> > > Emacs and talk to it bypassing Emacs' redirection stdout/stderr.
> > 
> > I didn't know that the MS-DOS port does make Emacs's terminal
> > available directly to its subprocesses, but that can be easily
> > accomodated.
> 
> I don't know about the port actually, and it is not a matter of making
> the terminal available as much as the subprocess just taking it, I
> think.  The screen memory is there, and the BIOS routine accessing it
> are there.  How is Emacs going to keep a subprocess from using those?

I didn't track this thread, so apologies if I will talk nonsense.

In a nutshell, I don't see how any of this is a concern in the MSDOS
port.

First, the MSDOS port does not support (and cannot support) multiple
displays, it only supports a single display: the local text terminal.
So the multi-tty features will at most be a no-op on MSDOS.

Second, $TERM is not used on MSDOS: there's no notion of different
terminal drivers for different types of terminal; all DOS-compatible
terminals support a single set of feature that cannot be modified, not
by termcap style config file, anyway.  (You will see in the Emacs code
that the MSDOS port sets TERM to a special value "internal", to signal
to term.c and its ilk that the internal emulation of a terminal is
used, and also to make use of the normal Emacs mechanism of loading
lisp/term/$(TERM) at startup.  But you cannot set TERM to anything
else and get useful results.)  So neither the MSDOS port nor any other
DOS programs it may run as subsidiary processes could ever care about
the value of TERM.

Third, the MSDOS port indeed does nothing to prevent a subprocess from
writing to the screen, but no program in its right mind should do that
when invoked with its stdout redirected to a file.  If there is a
program which does that, it is simply buggy.  Interactive programs
that need screen access should be invoked after shelling out of Emacs
(with C-x C-z); for this use case, Emacs on MSDOS saves the screen
contents before shelling out and restores it when the subsidiary shell
exits.

I hope these comments help.  Don't hesitate to ask questions if you
have any.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 13595 bytes --]

David Kastrup wrote:
> Karoly Lorentey <karoly@lorentey.hu> writes:
>> No, my memory has failed me.  I had a patch implementing the above
>> design, but what we currently have in the tree is something more
>> complex: environment variables are neither frame-, nor
>> terminal-local, but rather client-local.
> 
> I have seen on the archives of the multi-tty list and its README that
> the implementation has went through several different ideas.  So quite
> a bit of work has been invested already, and there is obviously not
> going to be much enthusiasm for scrapping it.

Sure, but better scrap parts than drop the whole thing.  As you say,
environments have already gone through several reimplementations.  I
certainly don't mind having another iteration. :-)  What we have now is
my personal favourite, but that doesn't mean it's the best for everyone.

I argue that while it is a valid viewpoint to say that things such as
CFLAGS or TEXINPUTS should always come from the original environment, it
is equally valid and defensible to say that they should come from the
local terminal.  (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 think that "client-local" is a complication we really don't want to
> introduce.

Fair enough.  So let's do terminal-local environments.  I hereby
withdraw the current environment implementation, and propose the
following simple solution instead:

	- Make `process-environment' a terminal-local variable
	  (with DEFVAR_KBOARD).

	- Have all environment variables be terminal-local.
	  (Keep reading!) :-)

	- Getenv should look at the current binding of
	  `process-environment' only.

	- Modify the default behaviour of `setenv' to change the
	  variable on all terminals, one by one.  In a loop.

	  If it is desired that M-x setenv affect future terminals as
	  well, then we can make it keep a list of changed variables and
	  apply this list on the terminal-local environment whenever a
	  new terminal is initialized.  I suggest doing this.

	- To support having only DISPLAY and a selected few other
	  variables differ on separate terminals, we can tweak the
	  initialization of terminal-local environment lists to copy the
	  rest of the variables from the original environment.  The
	  lists will, however, remain separate.

The above solution is easy to implement, easy to explain, doesn't
involve fragile Lisp structures, and does not break any existing code.
That is to say, users using a single terminal will not notice any change
whatsoever.  All code that works in Emacs 22 will work in
single-terminal Emacs 23.  All environment-related regressions are
prevented, period.

Multi-terminal users may notice that some environment variables are
different on different terminals.  This will not lead to confusion,
however, since two frames can only appear side by side when they are on
the same terminal.  (This is an important point.)

Existing Elisp code that does not change to a (literally) randomly
selected frame after temporarily setting up a particular environment
will work without changes when multiple terminals are simultaneously
present in Emacs 23.

One deviation in the multi-terminal case is that code like

	(let ((oldval (getenv "FOO"))
	  (setenv "FOO" "fred")
	  (unwind-protect
		...
	     (setenv "FOO" oldval))

will change the value of FOO on all terminals but the current one as a
new side effect.  This is, I believe, acceptable.  Some code adaptation
to make existing code able to take advantage of the new feature set is
inevitable.  We can simply document this concern and suggest solutions
(e.g., let-binding `process-environment' instead, or adding a standard
macro that would save and restore `process-environment' on all
terminals.) in the NEWS file, or wherever we provide an upgrade guide
for package writers.

(Here is another example where some (many) existing packages will fail
in a multi-terminal environment: It is very common in Elisp code to have
window-system dependent variable values be initialized at load time.
This works fine in the single-terminal case, but fails (with symptoms of
various severity) in a tty+X multi-terminal environment.)

I feel this is a good compromise between compatibility and new features.
 In the rest of this mail I'm going to argue for the above proposed design.

> Here is how to approach this with a "minimally invasive hack" (namely
> something which works with most existing code, but which one would not
> really want to ever write into a manual): make process-environment a
> terminal-local variable.

So far, so good. :-)

> It will be an nconc of terminal local
> environment variables and `global-process-environment', the
> environment Emacs got started with.

I really don't see a reason to do a thing like that, but I would accept
it if you think it's important, and if you agree to provide an option to
disable it.

[(Very useful) list of reference use-cases]
> So those are the semantics we want to keep if we possibly can.

All of these use-cases will work unchanged in single-terminal sessions.
Some of them will need to be changed to be fully compatible with
multi-terminal sessions.  Very good.

> We also would want to have terminal-local environment variables (like
> "DISPLAY") appear in process-environment.

We can mark this done.

> For some reason it would seem that

(permanent)

> manipulation of process-environment happens almost
> exclusively through setenv.

In the new design, this will work unchanged in multi-terminal sessions
as well.

> So here are a few options:
> 
> a) make process-environment a terminal-local R/W variable.  Notice
> that this does _not_ imply that anything but the first element of the
> list can't be actually shared among the lists.  As long as
> manipulation of process-environment happens with setenv, we are off
> ok.  Changes of existing values can be done with setcar, so that
> terminal-local environment variables (at the start of the list) will
> stay terminal-local and vice versa.

AFAICS, this is my above design, plus tail-merging, minus global setenv.
 I don't hate it.  As I said above, if you'd really prefer, I can live
with the shared tails, provided they can be easily disabled.

> Disadvantage: if somebody manipulates process-environment with setq
> and a copy, the variable set for this terminal will _then_ become
> completely detached from that of other terminals.

This doesn't affect single-terminal users, and will not lead to
catastrophic failure with multiple terminals either.  Most users will
not even notice, and as you see some will even prefer this state as
default. :-)

> b) make process-environment a global variable that can be manipulated
> like the user wants.  However, whenever call-process or similar are
> invoked, the actual environment passed into the called process has a
> set of terminal-local environment settings prepended.
[...]
> It will be a nuisance and might break those programs that manipulate
> the environment variables accessing the tty, but only those.

I think this solution would be both incompatible and much too complex.

[...]
> And it will also cause a lot of
> inconsistencies that can't really be explained well to the user, like
> "compile" behaving differently in windows that are side-by-side.

I have explained above why I think this is an invalid argument with
terminal-local variables.  If two windows are side by side, then they
are on the same terminal.

>> 	  Terminal-local environments would less complete, but still
>> 	  good enough to be usable without many problems.
> 
> That's what I would aim for, and only for those variables that are
> indeed terminal-dependent.

OK, so let's do that using my design.  Or yours.

>> If you find client-local environments unacceptably ugly, I can
>> update and submit my patch for simple terminal-local environments.
>> The local environment then becomes a simple terminal parameter,
>> initialized when the terminal is created.  This is a much simpler
>> solution that retains much of the feature set of the current design.
> 
> I think we should aim for the simplest solution that we can reasonably
> explain.  My favorite solution, as explained above,

... is complex, hard to explain and backwards incompatible.

> I don't see how we could avoid this while maintaining
> reasonable upwards compatibility.

There is no 100% upwards compatible solution.  (Except perhaps the ones
using hypothetical future trans-human AI programs to automatically
rewrite existing single-terminal code.  I hope we will manage to release
Emacs 23 before the technological singularity makes human-operated
editors obsolete.  On the other hand, self-awareness, intuition and a
little creativity would be killer features to implement for Emacs 24.
We could then let Emacs 25 write itself, and go on holiday.
But I digress.) :-)

My suggested compromise (or your tail-merging variant) is 100% backwards
compatible. People who don't want to take advantage of the fancy new
multi-terminal features will not be bothered with quirky
incompatibilities, while the value of DISPLAY will nicely follow
terminals.  I believe this was our primary mission now.  We can tweak
the details later, once everyone has had a chance to use the branch and
get acquainted with what it offers.

The new design can be basically explained in one short sentence:
"process-environment is terminal-local, but setenv affects all terminals."

* * *

This concludes the relevant discussion.  For the encore, I'd like to
keep beating some dead horses, and resolve some miscellaneous
misunderstandings:

> This is actually a good thing because it provides sort of a litmus
> test for interface usability and design quality: if one feels
> uncomfortable casting existing behavior into a clear description and
> instead is tempted to write something like "don't bother about it, it
> will magically do the right thing", then something is amiss.

I don't recall suggesting doing this or attempting to divert attention
like that.

For example, I believe "environment variables are client-local, but
setenv changes all clients at once" is a pretty useful description of
current environment semantics on the branch.  No handwaving is necessary.

>> 	- For the user, there is a strong sense of connection between
>> 	an emacsclient instance and its set of frames.  If emacsclient
>> 	exits, then its frames are deleted and vice versa.
>>
>> 	C-x C-c kills emacsclient, not the entire Emacs process.  All
>> 	this feels very natural and fits a range of common use-cases,
>> 	particularly the ones involving quick editing jobs from the
>> 	command prompt.  (These are the ones for which Emacs was so
>> 	infamously not well suited before.)
>>
>> 	  This means that having a different set of variables from frame to
>> 	  frame does not normally seem inconsistent or unpredictable to the
>> 	  user.
>
> I am opposed to claiming to create an illusion that we can't actually
> provide.

There is no illusion here.  There really is a strong sense of
connection.  The frame lives and dies with emacsclient.  This is quite
enough to the user to feel as if he had started a new editor instance.
We may choose to ignore this fact or we may try to take advantage of it,
but there is no denying it.

> kill-emacs should work as before.

It does work as before.  It kills Emacs. :-)

> However, one might
> consider providing a different command kill-terminal-group or similar
> which would instead be bound to C-x C-c.

That's exactly what the branch does.  The function is called
`save-buffers-kill-terminal'.

(My .emacs actually rebinds C-x C-c to a variant of the above that kills
Emacs itself when given a prefix argument.  Very useful to end the day.)

>> 	- Furthermore, to me it seems more consistent to have all
>> 	environment variables be local than just a select few of them.
>
> But it will pretty much break every Lisp program involved with the
> environment. That price is too high.

No it doesn't.  Having `process-environment' empty is what breaks _some_
of them.  Having all environment variables be in terminal-local bindings
in `process-environment' (i.e., "the new design") does not actually lead
to blatant breakage as such.

>> 	- The behaviour of M-x shell and similar packages is mostly
>> 	irrelevant here.
>
> Disagree.  "Similar packages" pretty much include _all_ packages that
> would have reason to access the environment, so _certainly_ those
> packages are relevant to the issue.

Um, nope.  M-x shell is special because it creates a long-term
subprocess with which the user may communicate with inside Emacs, from
different terminals.  X clients manually started from an M-x shell
buffer will appear on the terminal that was active at the time the shell
process was forked.  We can not change this fact, no matter how hard we
tweak Emacs's environment variable handling.  This is why I say the
behaviour of M-x shell, M-x term, GUD, ILISP and friends (a.k.a.
"similar packages") is irrelevant to this discussion.

Packages starting x clients such as xdvi and short subprocesses such as
compilations are, on the other hand, indeed relevant.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

> David Kastrup wrote:
>> Karoly Lorentey <karoly@lorentey.hu> writes:
>>> No, my memory has failed me.  I had a patch implementing the above
>>> design, but what we currently have in the tree is something more
>>> complex: environment variables are neither frame-, nor
>>> terminal-local, but rather client-local.
>> 
>> I have seen on the archives of the multi-tty list and its README that
>> the implementation has went through several different ideas.  So quite
>> a bit of work has been invested already, and there is obviously not
>> going to be much enthusiasm for scrapping it.
>
> Sure, but better scrap parts than drop the whole thing.  As you say,
> environments have already gone through several reimplementations.  I
> certainly don't mind having another iteration. :-)  What we have now is
> my personal favourite, but that doesn't mean it's the best for everyone.
>
> I argue that while it is a valid viewpoint to say that things such as
> CFLAGS or TEXINPUTS should always come from the original environment, it
> is equally valid and defensible to say that they should come from the
> local terminal.

But things like a shell-buffer are not tied to a terminal (and most
certainly not to a frame).  Neither are process-buffers.  And yet you
need to start processes in them, and they need to have an environment
which you can more or less reliably _set_.

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

> Fair enough.  So let's do terminal-local environments.  I hereby
> withdraw the current environment implementation, and propose the
> following simple solution instead:
>
> 	- Make `process-environment' a terminal-local variable
> 	  (with DEFVAR_KBOARD).
>
> 	- Have all environment variables be terminal-local.
> 	  (Keep reading!) :-)
>
> 	- Getenv should look at the current binding of
> 	  `process-environment' only.
>
> 	- Modify the default behaviour of `setenv' to change the
> 	  variable on all terminals, one by one.  In a loop.

There is a lot of code that does the equivalent of

(let ((process-environment (copy-sequence process-environment)))
  (setenv "THIS" ...)
  (setenv "THAT" ...)
  (call-process "...")
)

It is the _standard_ way AFAICS to start a process with a custom
environment.  With your approach, this would not retain locality.

With my proposal, it would not work for setenv on any strictly
terminal-related variable (which would not make it into
call-process) unless you used (setenv-terminal "...

> 	  If it is desired that M-x setenv affect future terminals as
> 	  well, then we can make it keep a list of changed variables and
> 	  apply this list on the terminal-local environment whenever a
> 	  new terminal is initialized.  I suggest doing this.

This sounds too complicated for me.  I'd rather have a set of strictly
terminal-local and terminal relevant settings that will _override_
process-environment when processes are being called.

Keeping lists around to apply to other lists when terminals get
initialized: too complex.

> 	- To support having only DISPLAY and a selected few other
> 	variables differ on separate terminals, we can tweak the
> 	initialization of terminal-local environment lists to copy the
> 	rest of the variables from the original environment.  The
> 	lists will, however, remain separate.

I don't like the implications for setting environment variables in
.emacs, for example.

> The above solution is easy to implement, easy to explain, doesn't
> involve fragile Lisp structures, and does not break any existing
> code.

I consider it fragile, and I don't see how you can claim it does not
break existing code when the most common idiom I cited above for
calling a process with temporarily set variables will not work.

> Existing Elisp code that does not change to a (literally) randomly
> selected frame after temporarily setting up a particular environment
> will work without changes when multiple terminals are simultaneously
> present in Emacs 23.

There is lots of Elisp code that does not even run in a frame: network
buffers, spell check buffers, background processes and the like.

> One deviation in the multi-terminal case is that code like
>
> 	(let ((oldval (getenv "FOO"))
> 	  (setenv "FOO" "fred")
> 	  (unwind-protect
> 		...
> 	     (setenv "FOO" oldval))
>
> will change the value of FOO on all terminals but the current one as
> a new side effect.  This is, I believe, acceptable.  Some code
> adaptation to make existing code able to take advantage of the new
> feature set is inevitable.  We can simply document this concern and
> suggest solutions (e.g., let-binding `process-environment' instead,
> or adding a standard macro that would save and restore
> `process-environment' on all terminals.) in the NEWS file, or
> wherever we provide an upgrade guide for package writers.

Huh?  Let-binding process-environment would not keep your
setenv-implementation from iterating through the terminals and/or
keeping score of environment changes to apply, would it?

>> For some reason it would seem that
>
> (permanent)

Please don't "correct" things in my wording that are simply wrong.
The problem is exactly that also temporary changes of
process-environment are done using setenv (after copy-sequencing
process-environment).

>> manipulation of process-environment happens almost
>> exclusively through setenv.
>
> In the new design, this will work unchanged in multi-terminal
> sessions as well.

It won't for temporary changes.

>> So here are a few options:
>> 
>> a) make process-environment a terminal-local R/W variable.  Notice
>> that this does _not_ imply that anything but the first element of the
>> list can't be actually shared among the lists.  As long as
>> manipulation of process-environment happens with setenv, we are off
>> ok.  Changes of existing values can be done with setcar, so that
>> terminal-local environment variables (at the start of the list) will
>> stay terminal-local and vice versa.
>
> AFAICS, this is my above design, plus tail-merging, minus global
> setenv.  I don't hate it.  As I said above, if you'd really prefer,
> I can live with the shared tails, provided they can be easily
> disabled.

Well, I said that this idea has some hackish charm to it, but it
breaks down with regard to determining just where the shared tail
starts, how to initialize this for a new terminal and a few other
things.  I just mentioned it for its hack value, but I really don't
think we should work with such trickiness as a central design part.

>> b) make process-environment a global variable that can be manipulated
>> like the user wants.  However, whenever call-process or similar are
>> invoked, the actual environment passed into the called process has a
>> set of terminal-local environment settings prepended.
> [...]
>> It will be a nuisance and might break those programs that manipulate
>> the environment variables accessing the tty, but only those.
>
> I think this solution would be both incompatible and much too
> complex.

Interesting.  It is actually compatible with existing code (except
those setting the TERM variable if we agree that this is one of the
terminal-local ones), and it is quite simpler than your proposals.
The main disadvantage is that it has _one_ "Huh?" factor: setting a
terminal-related variable with setenv will not propagate to called
processes by default.

In contrast, your proposals have a _lot_ more "Huh?" factors.

> [...]
>> And it will also cause a lot of
>> inconsistencies that can't really be explained well to the user, like
>> "compile" behaving differently in windows that are side-by-side.
>
> I have explained above why I think this is an invalid argument with
> terminal-local variables.  If two windows are side by side, then they
> are on the same terminal.

I think the above comment belonged to a different model
(frame-dependent variables and/or complete environment
terminal/frame-local).

>>> 	  Terminal-local environments would less complete, but still
>>> 	  good enough to be usable without many problems.
>> 
>> That's what I would aim for, and only for those variables that are
>> indeed terminal-dependent.
>
> OK, so let's do that using my design.  Or yours.

If you can improve your design to a point where the
(let ((process-environment (copy-sequence process-environment)))
  (setenv "..."
  (setenv "..."
  (start-process ...
))

scenario accepts setenv for terminal-local variables without
propagating them elsewhere, where
(setenv "..."
alone will affect the environment everywhere (except where
terminal-specific variables are concerned) and there is not a lot of
background stuff going on that is hard to explain, then I would not
mind dropping my proposal.  It is just that at the current point of
time I don't see either your or mine proposal doing all that with a
reasonable amount of simplicity.

>> I think we should aim for the simplest solution that we can reasonably
>> explain.  My favorite solution, as explained above,
>
> ... is complex, hard to explain and backwards incompatible.

Funny.  That's exactly what I consider your solution to be.

> The new design can be basically explained in one short sentence:
> "process-environment is terminal-local, but setenv affects all
> terminals."

But we don't want a setenv DISPLAY to affect all terminals, and we
don't want it to affect any terminal if we are let-binding
process-environment.

> For example, I believe "environment variables are client-local, but
> setenv changes all clients at once" is a pretty useful description
> of current environment semantics on the branch.  No handwaving is
> necessary.

"client-local".  There are a lots of places inside of Emacs where
processes may get started that are a far way from being associated
with any "client".

>> Disagree.  "Similar packages" pretty much include _all_ packages
>> that would have reason to access the environment, so _certainly_
>> those packages are relevant to the issue.
>
> Um, nope.  M-x shell is special because it creates a long-term
> subprocess with which the user may communicate with inside Emacs,
> from different terminals.  X clients manually started from an M-x
> shell buffer will appear on the terminal that was active at the time
> the shell process was forked.  We can not change this fact, no
> matter how hard we tweak Emacs's environment variable handling.
> This is why I say the behaviour of M-x shell, M-x term, GUD, ILISP
> and friends (a.k.a.  "similar packages") is irrelevant to this
> discussion.

Again: disregarding most packages which actually access the
environment as "irrelevant" does not seem like a good idea.

> Packages starting x clients such as xdvi and short subprocesses such
> as compilations are, on the other hand, indeed relevant.

If they don't actually set the environment, they are not relevant for
discussing setting the environment.  They are only relevant for
establishing that we want some sort of locality for terminal-related
environment variables.

But there is agreement about that, so you don't need to cite them as
supporting your position in the unrelated matter of how to deal with
_writing_ to environment variables.

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 6966 bytes --]

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.

>> One deviation in the multi-terminal case is that code like
>>
>> 	(let ((oldval (getenv "FOO"))
>> 	  (setenv "FOO" "fred")
>> 	  (unwind-protect
>> 		...
>> 	     (setenv "FOO" oldval))
>>
>> will change the value of FOO on all terminals but the current one as
>> a new side effect.  This is, I believe, acceptable.  Some code
>> adaptation to make existing code able to take advantage of the new
>> feature set is inevitable.  We can simply document this concern and
>> suggest solutions (e.g., let-binding `process-environment' instead,
>> or adding a standard macro that would save and restore
>> `process-environment' on all terminals.) in the NEWS file, or
>> wherever we provide an upgrade guide for package writers.
> 
> Huh?  Let-binding process-environment would not keep your
> setenv-implementation from iterating through the terminals and/or
> keeping score of environment changes to apply, would it?

On the other hand, let-binding process-environment and consing in front
of it will be an appropriate solution in some of the cases.  That's what
I meant.

>>> manipulation of process-environment happens almost
>>> exclusively through setenv.
>> In the new design, this will work unchanged in multi-terminal
>> sessions as well.
> 
> It won't for temporary changes.

I do not care.  Single-terminal users will not be affected.

>> I think this solution would be both incompatible and much too
>> complex.
> 
> Interesting.  It is actually compatible with existing code (except
> those setting the TERM variable if we agree that this is one of the
> terminal-local ones),

I'm sorry, but this must be a new sense of the word "compatible" I was
not previously aware of.

> and it is quite simpler than your proposals.

Explain it in a single short sentence then.

> The main disadvantage is that it has _one_ "Huh?" factor: setting a
> terminal-related variable with setenv will not propagate to called
> processes by default.

That's a pretty big Huh? for me.  This is a cute, fat little Huh?
oppurtunity even for our sacred single-terminal users.

> In contrast, your proposals have a _lot_ more "Huh?" factors.

Huh?

>>> And it will also cause a lot of
>>> inconsistencies that can't really be explained well to the user, like
>>> "compile" behaving differently in windows that are side-by-side.
>> I have explained above why I think this is an invalid argument with
>> terminal-local variables.  If two windows are side by side, then they
>> are on the same terminal.
> 
> I think the above comment belonged to a different model
> (frame-dependent variables and/or complete environment
> terminal/frame-local).

If we have partially local environments, then all frames will share
"non-terminal related" variables, so your side-by-side argument is
invalid.  If we have a consistently local environment, then side-by-side
windows will share their environment by virtue of being on the same
terminal.  I really don't see why you keep bringing this up.

>> OK, so let's do that using my design.  Or yours.
> 
> If you can improve your design to a point where the
> (let ((process-environment (copy-sequence process-environment)))
>   (setenv "..."
>   (setenv "..."
>   (start-process ...
> ))
> 
> scenario accepts setenv for terminal-local variables without
> propagating them elsewhere, where
> (setenv "..."
> alone will affect the environment everywhere (except where
> terminal-specific variables are concerned) and there is not a lot of
> background stuff going on that is hard to explain, then I would not
> mind dropping my proposal.

I'm really not interested whatsoever in keeping the above code work in
multi-terminal sessions.  However, you were quite effective in
convincing me that single-terminal users must not be affected in any way
by multi-tty features.

>> The new design can be basically explained in one short sentence:
>> "process-environment is terminal-local, but setenv affects all
>> terminals."
> 
> But we don't want a setenv DISPLAY to affect all terminals, 

Actually, I do.  If I manually M-x setenv DISPLAY, then I do that for a
good reason.

>>> Disagree.  "Similar packages" pretty much include _all_ packages
>>> that would have reason to access the environment, so _certainly_
>>> those packages are relevant to the issue.
>> Um, nope.  M-x shell is special because it creates a long-term
>> subprocess with which the user may communicate with inside Emacs,
>> from different terminals.  X clients manually started from an M-x
>> shell buffer will appear on the terminal that was active at the time
>> the shell process was forked.  We can not change this fact, no
>> matter how hard we tweak Emacs's environment variable handling.
>> This is why I say the behaviour of M-x shell, M-x term, GUD, ILISP
>> and friends (a.k.a.  "similar packages") is irrelevant to this
>> discussion.
> 
> Again: disregarding most packages which actually access the
> environment as "irrelevant" does not seem like a good idea.

You don't seem to understand my point.  Please read my paragraph again.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

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

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.

> Clearly I won't convince you by repeating the same arguments over
> and over, and you will definitely not convince me either.

A pity if you disregard the existing typical use cases.

> There is no point in arguing for the sake of arguing.  I throw in
> the towel, you win.  Congratulations.

This is not about winning.  I'd actually be glad to lose in every
respect: if you (or somebody else) came up with a solution that beat
all my concerns and propositions.

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

Uh, but we don't want to have this code break in the multi-tty case.
Let's distinguish two goals here:

a) when a merge into trunk becomes acceptable.  If the single-tty case
works as previously, this will not disrupt people working on other
things.
b) the design of the final code.  There is no point in having "no
regression in the single-tty case" when the multi-tty case does not
have consistent behavior.  And if we have to change the design again,
this might destabilize the trunk temporarily again.  So we want to
have the design more or less in a state where we don't expect many
more disruptive changes.

> I think you are vastly overemphasizing the importance of environment
> variables in general and "future compatibility" in particular.

There is no point in not doing things as good as possible.

>>> One deviation in the multi-terminal case is that code like
>>>
>>> 	(let ((oldval (getenv "FOO"))
>>> 	  (setenv "FOO" "fred")
>>> 	  (unwind-protect
>>> 		...
>>> 	     (setenv "FOO" oldval))
>>>
>>> will change the value of FOO on all terminals but the current one as
>>> a new side effect.  This is, I believe, acceptable.  Some code
>>> adaptation to make existing code able to take advantage of the new
>>> feature set is inevitable.  We can simply document this concern and
>>> suggest solutions (e.g., let-binding `process-environment' instead,
>>> or adding a standard macro that would save and restore
>>> `process-environment' on all terminals.) in the NEWS file, or
>>> wherever we provide an upgrade guide for package writers.
>> 
>> Huh?  Let-binding process-environment would not keep your
>> setenv-implementation from iterating through the terminals and/or
>> keeping score of environment changes to apply, would it?
>
> On the other hand, let-binding process-environment and consing in
> front of it will be an appropriate solution in some of the cases.
> That's what I meant.

If we can detect that process-environment is let-bound (instead of
terminal-local), setenv might refrain from touching other terminals.
That might make your approach work equivalently without having to use
the shared tail hack.

>>>> manipulation of process-environment happens almost
>>>> exclusively through setenv.
>>> In the new design, this will work unchanged in multi-terminal
>>> sessions as well.
>> 
>> It won't for temporary changes.
>
> I do not care.  Single-terminal users will not be affected.

If we don't care for multi-terminal users, we would not be working on
multi-tty in the first place.

>>> I think this solution would be both incompatible and much too
>>> complex.
>> 
>> Interesting.  It is actually compatible with existing code (except
>> those setting the TERM variable if we agree that this is one of the
>> terminal-local ones),
>
> I'm sorry, but this must be a new sense of the word "compatible" I was
> not previously aware of.

Well, tit for tat...

>> and it is quite simpler than your proposals.
>
> Explain it in a single short sentence then.

The environment passed to processes consists of the values in the
terminal-local variable terminal-process-environment and those of the
global variable process-environment, with values in
terminal-process-environment taking priority.

>> The main disadvantage is that it has _one_ "Huh?" factor: setting a
>> terminal-related variable with setenv will not propagate to called
>> processes by default.
>
> That's a pretty big Huh? for me.  This is a cute, fat little Huh?
> oppurtunity even for our sacred single-terminal users.

Yes.  That's why I say I'd like see someone beat my approach.

>> In contrast, your proposals have a _lot_ more "Huh?" factors.
>
> Huh?

They make setenv quite complex, and process-environment is quite more
difficult to interpret and manipulate.

>> If you can improve your design to a point where the
>> (let ((process-environment (copy-sequence process-environment)))
>>   (setenv "..."
>>   (setenv "..."
>>   (start-process ...
>> ))
>> 
>> scenario accepts setenv for terminal-local variables without
>> propagating them elsewhere, where
>> (setenv "..."
>> alone will affect the environment everywhere (except where
>> terminal-specific variables are concerned) and there is not a lot of
>> background stuff going on that is hard to explain, then I would not
>> mind dropping my proposal.
>
> I'm really not interested whatsoever in keeping the above code work
> in multi-terminal sessions.  However, you were quite effective in
> convincing me that single-terminal users must not be affected in any
> way by multi-tty features.

There is no point in having existing code break in multi-tty settings
"only": that way many people will not notice that their code does not
work on multi-tty when it does on single-tty.

"Don't break on single-tty" is important for the merge to the trunk,
but it is pointless as a final goal: in the final state, we would
likely be better off if things break under similar conditions in
multi-tty and single-tty.

>>> The new design can be basically explained in one short sentence:
>>> "process-environment is terminal-local, but setenv affects all
>>> terminals."
>> 
>> But we don't want a setenv DISPLAY to affect all terminals, 
>
> Actually, I do.  If I manually M-x setenv DISPLAY, then I do that
> for a good reason.

"Manually".  setenv is called also non-manually, and in particular
when process-environment might be let-bound.  Can we detect this case?
And are you really sure that if you log into your system remotely,
manually set DISPLAY, work a bit, then log out again, that you would
want your existing session on your home computer retain this manual
setting?

>>>> Disagree.  "Similar packages" pretty much include _all_ packages
>>>> that would have reason to access the environment, so _certainly_
>>>> those packages are relevant to the issue.
>>> Um, nope.  M-x shell is special because it creates a long-term
>>> subprocess with which the user may communicate with inside Emacs,
>>> from different terminals.  X clients manually started from an M-x
>>> shell buffer will appear on the terminal that was active at the time
>>> the shell process was forked.  We can not change this fact, no
>>> matter how hard we tweak Emacs's environment variable handling.
>>> This is why I say the behaviour of M-x shell, M-x term, GUD, ILISP
>>> and friends (a.k.a.  "similar packages") is irrelevant to this
>>> discussion.
>> 
>> Again: disregarding most packages which actually access the
>> environment as "irrelevant" does not seem like a good idea.
>
> You don't seem to understand my point.  Please read my paragraph again.

Can you name some packages using "setenv" that you would not consider
irrelevant in this respect?

-- 
David Kastrup

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Karoly Lorentey]

[-- Attachment #1.1: Type: text/plain, Size: 2936 bytes --]

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.

>> Explain it in a single short sentence then.
>
> The environment passed to processes consists of the values in the
> terminal-local variable terminal-process-environment and those of the
> global variable process-environment, with values in
> terminal-process-environment taking priority.

This sounds just peachy.  Would you like to implement it?

>> Clearly I won't convince you by repeating the same arguments over
>> and over, and you will definitely not convince me either.
> 
> A pity if you disregard the existing typical use cases.

I didn't disregard them.  But they were written with strictly
single-terminal sessions in mind.  I feel it is entirely acceptable to
require them to be changed to take advantage of the new multi-terminal
feature set.

But our discussion on environments really leads nowhere fast, so let's
slightly change the subject, and talk a little more about the "future
compatibility" of existing packages.

You did not react to my observation on how all existing code that looks
at `window-system' during load time breaks in multi-terminal sessions.
`window-system' is frame-local on the multi-tty branch and there is
*really* a lot of code that relies on it having a global binding.
People whose .emacs mentions window-system are likely affected as well.
 Again, single-terminal sessions continue to work fine, but in
multi-terminal sessions, these packages break with various levels of
spectacularity.

I don't think we should even attempt to implement convoluted heuristics
to have these packages still somehow work fine in multi-terminal
sessions.  Would you agree?

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

Karoly Lorentey <karoly@lorentey.hu> writes:

> You did not react to my observation on how all existing code that
> looks at `window-system' during load time breaks in multi-terminal
> sessions.  `window-system' is frame-local on the multi-tty branch
> and there is *really* a lot of code that relies on it having a
> global binding.  People whose .emacs mentions window-system are
> likely affected as well.  Again, single-terminal sessions continue
> to work fine, but in multi-terminal sessions, these packages break
> with various levels of spectacularity.
>
> I don't think we should even attempt to implement convoluted
> heuristics to have these packages still somehow work fine in
> multi-terminal sessions.  Would you agree?

Yes.  I consider it acceptable if everything relying on a single
terminal will break under multiple terminals.  There is no
alternative.

I consider it a _temporary_ advantage for the trunk merge if code
concerned with terminals will work as before in the single-tty case,
and only break in the multi-tty case: that gives people a single-tty
Emacs to work with while we figure out how to fix the breakage in the
multi-tty case.

What I don't consider acceptable if a considerable amount of stuff
working with environments that is _not_ related to multiple or even
single terminals will break.

I want to see the breakage restricted to those things that actually
have anything to do with terminals and ttys.  Even if we aim for a
long-term goal of having people do things in a particular better way
in future, this needs several Emacs versions and deprecated functions
and variables to shake out for good.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Richard Stallman]

I have not been following this thread, because there are two many
messages and it doesn't relate to the release.  I was planning to
let others determine what is best to do, and figured that you would
make a good decision.

But if it has come to an angry dispute, and if important contributors
feel hurt, maybe I should consider the arguments and choose a
solution, so as to reduce the level of hurt feelings.

I won't do this now, because I hope that you can smooth things out.
Please try.  If in a couple of days it still seems to be going badly.
I will start asking people to present the alternatives.

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Károly Lo"rentey]

[-- Attachment #1.1: Type: text/plain, Size: 752 bytes --]

Richard Stallman wrote:
> But if it has come to an angry dispute, and if important contributors
> feel hurt, maybe I should consider the arguments and choose a
> solution, so as to reduce the level of hurt feelings.

I'd like to clarify that actually I don't feel either hurt nor angry.  I
am simply frustrated because I don't think that environments deserve
such a long discussion.  It's such an unimportant issue in practice.

I trust David and the others will be able to continue the argument and
come up with a good implementation without me.  Everybody seems to agree
that at least DISPLAY should remain
[terminal,frame,client,keyboard,*]-local; as long as that's kept, I'll
gladly agree to any solution whatsoever.

-- 
Karoly


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty design (Re: Reordering etc/NEWS)

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> If the design is unsound, we need to rip it out completely, not just
> sabotage it at the points where the problems show.
>
> I'll try to see whether I can find the problematic caller.  But I
> certainly hope that this "paper over it and hope nobody notices it"
> stance does not pervade multi-tty, and that the _bug_ which I fixed
> was not intentional but an oversight.

Ok, here are the Lisp callers which pass a third argument into getenv.

/home/tmp/emacs/lisp/international/mule-cmds.el:2512:	  (setq locale (getenv (pop vars) display)))))
/home/tmp/emacs/lisp/international/mule-cmds.el:2639:		 (equal (getenv "TERM_PROGRAM" display) "Apple_Terminal"))
/home/tmp/emacs/lisp/international/mule-cmds.el:2657:	      (setq locale (getenv (pop vars) display))))
/home/tmp/emacs/lisp/term/rxvt.el:287:  (let ((fgbg (getenv "COLORFGBG" (terminal-id)))
/home/tmp/emacs/lisp/term/x-win.el:2439:			 (setq x-display-name (or (getenv "DISPLAY" (terminal-id))
/home/tmp/emacs/lisp/term/xterm.el:330:  (if (and (getenv "COLORTERM" (terminal-id))
/home/tmp/emacs/lisp/term/xterm.el:331:	   (string-match "\\`rxvt" (getenv "COLORTERM" (terminal-id))))

Most of these appear _not_ to pass a FRAME parameter (as claimed by
getenv's DOC string and its code) but a terminal id.

This is completely messed up, and ignoring the FRAME parameter is
_not_ the right solution.

The c callers are somewhat harder to find: basically, they would be
the ones calling getenv_internal with a non-nil fifth argument.

Then the rest of the code is a mixture of calling getenv (the system
call) and egetenv (which goes through a frame list presumably).

All of this is a mess.

I propose that we split this whole mess apart cleanly.  We create one
read-only variable called
terminal-environment-list
which contains all environment variables relevant for a terminal, and
a terminal-local variable
terminal-environment

When a new terminal gets opened, all environment variables in
terminal-environment-list get transferred to terminal-environment.  We
also provide a convenience routine
getenv-terminal
to read from the current terminal-environment.  Changing it is not
supported.

For debugging purposes (before the next release), we can add code to
getenv that complains when it gets asked about a variable in
terminal-environment-list: this is most likely a bug.

That way, getenv and setenv will continue to work exclusively on a
single process-environment.

Does this sound reasonable?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty design (Re: Reordering etc/NEWS)

[Richard Stallman]

    If there is no way to contact Emacs anymore, that would seem like a
    sensible default once Emacs is idling.

Just closing the connections and frames should not immediately cause
an exit, not while a Lisp program is still running.  However, if Emacs
has no net connections and no frames, and returns to the main loop,
perhaps then it should exit.

Re: Reordering etc/NEWS

[Richard Stallman]

    I intentionally left implementing frameless Emacs sessions after the
    merge, to let us discuss this proposed feature extensively on
    emacs-devel.  I think we need to make non-trivial design decisions.
    (Where do messages go when there are no frames?  How to recover when
    someone accidentally calls server-stop?)

I think messages should be put in *Messages*, only.  A frameless Emacs
job with no server running is a lot like batch mode, so why worry
about it?  So if the code in your frameless Emacs calls server-stop,
either you wanted that and you leave it running, or you didn't want
that and you kill it.

Re: Reordering etc/NEWS

[joakim]

David Kastrup <dak@gnu.org> writes:

> joakim@verona.se writes:
>
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>> joakim@verona.se wrote:
>>>> I use those branches and would be willing to test a merged version on
>>>> gnu+linux and w32. I could possibly dig out more machines with
>>>> different os:es as well if it would be any help.
>>>>   
>>> If the multitty branch works on w32 already, then that gives me a lot
>>> more confidence.
>>
>> I dont know. I have only tested mtty on gnu+linux. mtty doesnt have
>> any value on w32 as far as I can imagine, so I usually just use
>> Lennart Borgmans w32 emacs package.
>
> Why wouldn't it have value?  It allows one to keep an existing Emacs
> session around into which one can connect remotely via ssh+emacsclient
> in order to do work.  At least once emacsclient has been extended with
> a -nw (--no-window-system) option in order to open a frame on the
> emacsclient tty.

Ok, maybe that assesment was too harsh.

Its just that if I could choose which w32 functionality should be
improved, I would choose other more basic stuff*. IMHO having mtty
support as a configure option that is just not available on w32 would
be quite enough for emacs 23.


* like having "find-dired" choose a cygwin find if available, and not
  ever trying the w32 find util, which it doesnt work with anyway. And
  finding some workarounds for c-c c-c killing the local process
  rather than the remote in a shell buffer using a ssh client. And so
  on...
  

> It should also allow keeping an Emacs server session around (not just
> iconified, but actually frameless) that one can plug into using
> emacsclient again, and have it open a fresh frame.
>
>> I can try to compile on w32.
>
> -- 
> David Kastrup

-- 
Joakim Verona

Re: Reordering etc/NEWS

[Jason Rumney]

joakim@verona.se wrote:
> I dont know. I have only tested mtty on gnu+linux. mtty doesnt have
> any value on w32 as far as I can imagine

It currently doesn't have any value on w32, because there are not enough 
developers familiar enough with w32 to devote time to it, so at best it 
works exactly the same as the last trunk revision it was merged with, at 
worst it is horribly broken and does not compile. But w32 currently 
supports -nw operation in a single w32 text console so the potential 
value is the same as other platforms.

Multi-tty branch status (Re: Reordering etc/NEWS)

[Karoly Lorentey]

Jason Rumney wrote:
> joakim@verona.se wrote:
> If the multitty branch works on w32 already, then that gives me a lot
> more confidence.
> 
> My main concern was that it had never been tried to my knowledge, and
> due to the nature of the changes, there probably is work to do on w32
> just to get Emacs to compile if all the work so far has focused on  tty
> and X usage.

Fixing the compile is basically all that is necessary.  I don't think
Windows applications can support multiple displays, so that port will
remain single-terminal in functionality (at least for now).

> The problem is that this work has gone on outside the
> normal emacs development community, so information of this sort is hard
> to come by. 

Yes, this is unfortunate; it was dictated by circumstances.

> Another concern would be whether we have papers for everyone
> who has contributed to this branch.

I changed employers last summer and need to have the papers signed again
before the merge; this shouldn't be a problem.  Dan Nicolaescu, Han
Boetes and Kalle Olavi Niemitalo helped by submitting short patches.
There might have been a few one-liner bugfixes from other people; I will
check my logs.  There were no other code contributions, but loads of
helpful discussion and bug reports.

-- 
Karoly

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[Glenn Morris]

Karoly Lorentey wrote:

>> Another concern would be whether we have papers for everyone
>> who has contributed to this branch.
>
> I changed employers last summer and need to have the papers signed again
> before the merge; this shouldn't be a problem.  Dan Nicolaescu, Han
> Boetes and Kalle Olavi Niemitalo helped by submitting short patches.

FYI, the last two don't have (relevant) assignments AFAICS, so they
would need to sign papers if they made non-trivial contributions.

The delay this will inevitably introduce is IMO another reason to
merge unicode2 first.

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[Kalle Olavi Niemitalo]

[-- Attachment #1.1: Type: text/plain, Size: 871 bytes --]

Glenn Morris <rgm@gnu.org> writes:

> Karoly Lorentey wrote:
>
>> Dan Nicolaescu, Han Boetes and Kalle Olavi Niemitalo helped by
>> submitting short patches.
>
> FYI, the last two don't have (relevant) assignments AFAICS, so they
> would need to sign papers if they made non-trivial contributions.

Grepping from my mail archive, my contributions seem to have been
the following.

2005-08-10 bug report, no patch
2006-05-03 bug report, no patch
2006-05-22 bug report, no patch
2006-07-23 http://permalink.gmane.org/gmane.emacs.multi-tty/607
           patch changed all get_named_tty (NULL) calls to
           get_named_tty ("/dev/tty").  May be trivial.  Applied in
           lorentey@elte.hu--2004/emacs--multi-tty--0--patch-579.
2006-07-25 reference to the earlier patch
2006-11-25 bug report, no patch; this bug may still exist

I am unwilling to assign copyright.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[David Kastrup]

Kalle Olavi Niemitalo <kon@iki.fi> writes:

> Glenn Morris <rgm@gnu.org> writes:
>
>> Karoly Lorentey wrote:
>>
>>> Dan Nicolaescu, Han Boetes and Kalle Olavi Niemitalo helped by
>>> submitting short patches.
>>
>> FYI, the last two don't have (relevant) assignments AFAICS, so they
>> would need to sign papers if they made non-trivial contributions.
>
> Grepping from my mail archive, my contributions seem to have been
> the following.
>
> 2005-08-10 bug report, no patch
> 2006-05-03 bug report, no patch
> 2006-05-22 bug report, no patch
> 2006-07-23 http://permalink.gmane.org/gmane.emacs.multi-tty/607
>            patch changed all get_named_tty (NULL) calls to
>            get_named_tty ("/dev/tty").  May be trivial.  Applied in
>            lorentey@elte.hu--2004/emacs--multi-tty--0--patch-579.

It is a mechanical change without room for creative expression (which
is what copyright protects).  Should not require a copyright
assignment unless you wrote a particularly expressive ChangeLog entry.
But the latter can be replaced easily by a stock one.

> 2006-07-25 reference to the earlier patch
> 2006-11-25 bug report, no patch; this bug may still exist
>
> I am unwilling to assign copyright.

Which sounds a bit harsh.  However, if your above list is complete, it
would not seem to cause a problem in the current situation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[Richard Stallman]

    > 2006-07-23 http://permalink.gmane.org/gmane.emacs.multi-tty/607
    >            patch changed all get_named_tty (NULL) calls to
    >            get_named_tty ("/dev/tty").  May be trivial.  Applied in
    >            lorentey@elte.hu--2004/emacs--multi-tty--0--patch-579.

    It is a mechanical change without room for creative expression (which
    is what copyright protects).  Should not require a copyright
    assignment unless you wrote a particularly expressive ChangeLog entry.
    But the latter can be replaced easily by a stock one.

Can someone show the actual diff?

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[Károly Lo"rentey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glenn Morris wrote:
> Karoly Lorentey wrote:
> 
>>> Another concern would be whether we have papers for everyone
>>> who has contributed to this branch.
>> I changed employers last summer and need to have the papers signed again
>> before the merge; this shouldn't be a problem.  Dan Nicolaescu, Han
>> Boetes and Kalle Olavi Niemitalo helped by submitting short patches.
> 
> FYI, the last two don't have (relevant) assignments AFAICS, so they
> would need to sign papers if they made non-trivial contributions.

I think their contributions can be considered trivial as far as
copyrights are concerned.

Han Boetes sent me a patch copying a few lines from lisp.h into
emacsclient.c:

- --- orig/lib-src/emacsclient.c
+++ mod/lib-src/emacsclient.c
@@ -45,6 +45,25 @@
 #include <signal.h>
 #include <errno.h>

+/* From lisp.h */
+#ifndef DIRECTORY_SEP
+#define DIRECTORY_SEP '/'
+#endif
+#ifndef IS_DIRECTORY_SEP
+#define IS_DIRECTORY_SEP(_c_) ((_c_) == DIRECTORY_SEP)
+#endif
+#ifndef IS_DEVICE_SEP
+#ifndef DEVICE_SEP
+#define IS_DEVICE_SEP(_c_) 0
+#else
+#define IS_DEVICE_SEP(_c_) ((_c_) == DEVICE_SEP)
+#endif
+#endif
+#ifndef IS_ANY_SEP
+#define IS_ANY_SEP(_c_) (IS_DIRECTORY_SEP (_c_))
+#endif
+
+
 \f
 char *getenv (), *getwd ();
 char *(getcwd) ();



Kalle Olavi Niemitalo contributed the following bugfix:

*** orig/src/keyboard.c
- --- mod/src/keyboard.c
***************
*** 10574,10580 ****
    SIGNAL_THREAD_CHECK (signalnum);

    /* See if we have an active terminal on our controlling tty. */
!   terminal = get_named_tty (NULL);
    if (!terminal)
      {
        /* If there are no frames there, let's pretend that we are a
- --- 10574,10580 ----
    SIGNAL_THREAD_CHECK (signalnum);

    /* See if we have an active terminal on our controlling tty. */
!   terminal = get_named_tty ("/dev/tty");
    if (!terminal)
      {
        /* If there are no frames there, let's pretend that we are a
***************
*** 10618,10624 ****
    /* XXX This code needs to be revised for multi-tty support. */
    if (!NILP (Vquit_flag)
  #ifndef MSDOS
!       && get_named_tty (NULL)
  #endif
        )
      {
- --- 10618,10624 ----
    /* XXX This code needs to be revised for multi-tty support. */
    if (!NILP (Vquit_flag)
  #ifndef MSDOS
!       && get_named_tty ("/dev/tty")
  #endif
        )
      {
***************
*** 10915,10928 ****
         doc: /* Specify character used for quitting.
  QUIT must be an ASCII character.

! This function only has an effect on the terminal on the controlling
! tty of the Emacs process.

  See also `current-input-mode'.  */)
         (quit)
         Lisp_Object quit;
  {
!   struct terminal *t = get_named_tty (NULL);
    struct tty_display_info *tty;
    if (t == NULL || t->type != output_termcap)
      return Qnil;
- --- 10915,10928 ----
         doc: /* Specify character used for quitting.
  QUIT must be an ASCII character.

! This function only has an effect on the controlling tty of the Emacs
! process.

  See also `current-input-mode'.  */)
         (quit)
         Lisp_Object quit;
  {
!   struct terminal *t = get_named_tty ("/dev/tty");
    struct tty_display_info *tty;
    if (t == NULL || t->type != output_termcap)
      return Qnil;

I believe these two are the only patches that didn't come from Dan.

> The delay this will inevitably introduce is IMO another reason to
> merge unicode2 first.

I am arguing neither for nor against that.  But where does this sudden
hurry come from?

- --
Karoly
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGRZdZ6eoyqA+yej8RAo0nAJ9/exKzg2K687OLmGL+UmLcymVfkgCfbo9B
wYIV86lO9OjRVf1W0GPr3II=
=gAzS
-----END PGP SIGNATURE-----

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[David Kastrup]

"Károly Lo\"rentey" <karoly@lorentey.hu> writes:

>> The delay this will inevitably introduce is IMO another reason to
>> merge unicode2 first.
>
> I am arguing neither for nor against that.  But where does this
> sudden hurry come from?

I see no hurry involved here.  We branched for the release of 22.1.
The trunk is now open for further development.  We are not currently
discussing actual timelines, but rather what the next steps we are
going to aim for will be.

The mere discussion of future progress should hopefully not strike
terror into Emacs developers' hearts, but then it may feel
unaccustomed.  It may not be as bad as it sounds: we did have
decisions and progress in the past, even though it was not always
apparent.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[Richard Stallman]

Those changes by Boetes and Niemitalo are trivial.
We do not need papers for them.  Thanks for showing me them
so I can be sure of this.

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[Richard Stallman]

    I changed employers last summer and need to have the papers signed again
    before the merge; this shouldn't be a problem.

The best time to arrange that is before accepting a new job, since at
that time you have the most leverage.  Please raise the issue ASAP.

      Dan Nicolaescu, Han
    Boetes and Kalle Olavi Niemitalo helped by submitting short patches.

Since we don't have all the papers, that is one more reason to merge in
unicode-2 first.

Re: Multi-tty branch status (Re: Reordering etc/NEWS)

[Karoly Lorentey]

Richard Stallman wrote:
>     I changed employers last summer and need to have the papers signed again
>     before the merge; this shouldn't be a problem.
> 
> The best time to arrange that is before accepting a new job, since at
> that time you have the most leverage.  Please raise the issue ASAP.

I don't anticipate any problems.  Could you have the papers be sent to me?

Thanks,
-- 
Karoly

Re: Reordering etc/NEWS

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 10 May 2007 08:24:57 +0100, Jason Rumney <jasonr@gnu.org> said:

> That is extremely optimistic. Has anyone even tried the multitty branch 
> on Mac and Windows yet? I know there is still significant work required 
> for emacs-unicode-2 on Windows, though it at least basically works.

As for Mac, I'm planning to quit the development of the Carbon port
for Emacs 23, as the Cocoa/GNUstep port will replace it on that
version.  So, personally I don't care if multitty is incompatible with
the current Carbon code as long as it is not for Emacs 22.x (x > 1).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Reordering etc/NEWS

[Nick Roberts]

 > So regarding your original question: what state of testedness are the
 > multitty and emacs-unicode-2 branches in, and how far out of date
 > w.r.t. trunk are they?

It's not really relevant to anything because Richard has already said the
process is not up for discussion.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Reordering etc/NEWS

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > So regarding your original question: what state of testedness are the
>  > multitty and emacs-unicode-2 branches in, and how far out of date
>  > w.r.t. trunk are they?
>
> It's not really relevant to anything because Richard has already
> said the process is not up for discussion.

Sure.  But nevertheless pretty much everyone (including Richard) has
agreed that it will happen at some point of time, so I don't find it
amiss to answer questions about it.

Of course, I am reporting on my impression of the _current_ state.
Since Károly, the person having done the multitty branch, does not
appear to be available indefinitely for such an effort, the window of
opportunity for merging may close eventually, making things more
awkward than they are now.

But at the current point of time, a merge into the trunk seems quite
feasible.  It would probably shake up people who are used to employing
a random recent trunk snapshot for editing, but I don't think that we
should be bothered to much about them.  I think it is reasonable to
announce on this list that any continuing non-developing/debugging
snapshotters should focus on the Emacs 22 release branch.

Now.

-- 
David Kastrup

Re: Reordering etc/NEWS

[Stefan Monnier]

> I think merges of complex development branches can be handled
> incrementally by using bidirectional merging:
>    1) Repeatedly merge trunk into the branch, so the branch isn't
>    2) Get some developers to agree to run the branch for a while, to
>    3) One day, when the new work on the branch is done, merge it into

This is exactly what we've been doing for the unicoe and the
multitty branches.


        Stefan

Re: Reordering etc/NEWS

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I think merges of complex development branches can be handled
>> incrementally by using bidirectional merging:
>>    1) Repeatedly merge trunk into the branch, so the branch isn't
>>    2) Get some developers to agree to run the branch for a while, to
>>    3) One day, when the new work on the branch is done, merge it into
>
> This is exactly what we've been doing for the unicoe and the
> multitty branches.

That's great!  Then we don't need to be afraid of merging them into trunk.

Re: Reordering etc/NEWS

[Richard Stallman]

    Richard has just announced that he plans on releasing Emacs 22.1 from
    the EMACS_BASE_22 branch.

I mis-stated my point in the previous message.  Of course we were
always planning to make 22.1 from the EMACS_BASE_22.  The change is
that I have decided to make future Emacs 22 versions from EMACS_BASE_22
also, not from the trunk.

Sorry for the confusion.

So people can use the trunk for changes meant for Emacs 23.

Re: Reordering etc/NEWS

[Kenichi Handa]

In article <E1HmPmA-0001n5-S7@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

> So people can use the trunk for changes meant for Emacs 23.

Does it mean that it is ok to merge emacs-unicode-2 into the
trunk now?

---
Kenichi Handa
handa@m17n.org

Re: Reordering etc/NEWS

[Nick Roberts]

 > > So people can use the trunk for changes meant for Emacs 23.
 > 
 > Does it mean that it is ok to merge emacs-unicode-2 into the
 > trunk now?

That seems sensible to me (not that I know much about emacs-unicode-2), but
others have talked about merging multi-tty too.  Let's not merge both in at the
same time.  I also think the first merge should prove stable before the second
is started, or we'll never unravel the mess.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Merging multitty (was: Reordering etc/NEWS)

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <E1HmPmA-0001n5-S7@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
>
>> So people can use the trunk for changes meant for Emacs 23.
>
> Does it mean that it is ok to merge emacs-unicode-2 into the
> trunk now?

Well, this is one of the points we definitely agreed to do for Emacs
23, so it _would_ appear to be in concord with Richard's statement
here.

However, I think we more or less agreed that it would be more prudent
to merge the multitty stuff first and follow up with the Unicode
branch, since that would minimize the merge work on multitty where we
have less active expertise to rely on.

Cc to Károly and the multi-tty list.

In either case, a merge into trunk is quite a bit of work, so it would
certainly not do harm to ask Richard for the explicit goahead if we
can agree on the procedures.

The last updates of multitty appear to have happened on Apr 22nd.
Károly, would it be possible for you to synch one last time to the
trunk and then check the results into a branch in Emacs CVS?

I would propose the following procedure:

a) Károly synchronizes his version to the trunk [very desirable]
[after this has happened, we may already have word from list
participants and Richard whether we can agree on this procedure]
b) if he has CVS write access, he checks the results into a branch
   emacs-multitty.  If he hasn't, we need someone else to do this.
c) The branch is merged into the trunk.  If point a had already been
   done by Károly, this will be trivial.  If he has not been able to
   do this, more work will be involved, but I don't expect serious
   merge conflicts.
d) problems are shaken out.  This will particularly affect platforms
   not yet tested/implemented in multitty.
While d) happens, emacs-unicode2 is synchronized according to what the
developers of the branch feel appropriate.  Synchronizing with the new
trunk will mean that there will be no production-quality
emacs-unicode2 until the trunk has stabilized again.
e) once the worst appears to be over, emacs-unicode2 is merged.

_Afterwards_, pent-up package updates reserved for "post-release" will
get merged.

This means that merge conflicts due to the multitty and unicode
changes will have to be tackled by the people checking in the package
updates.

Comments, better ideas?

-- 
David Kastrup

Re: Merging multitty

[Jason Rumney]

David Kastrup wrote:
> However, I think we more or less agreed that it would be more prudent
> to merge the multitty stuff first and follow up with the Unicode
> branch, since that would minimize the merge work on multitty where we
> have less active expertise to rely on.
>   
I don't recall ever agreeing this, although you have asserted so 
numerous times over the last few weeks.

The merge between multitty and unicode will be the same, whichever order 
it is done in.
The simple fact is that emacs-unicode-2 is ready to go onto the trunk, 
and the multitty is not due to issues mentioned in the README on 
Karoly's website.

> In either case, a merge into trunk is quite a bit of work.
>   

I think in both cases, the branches are well synched with trunk already, 
so there should be very little work in moving either one of the branches 
to the trunk (though in the case of multitty it would break Emacs on 
some platforms). The work comes when the non-merged branch is next 
synched to the trunk. The conflicts will be the same whichever direction 
the merge happens in, so I don't see any compelling reason to hasten the 
multitty merge to trunk (but it should be checked in on a branch ASAP so 
the problems mentioned above can be worked on by someone who is familiar 
with the platforms affected).

Your point that Karoly is not going to be available for much longer is a 
point against merging into trunk quickly IMHO. Either someone else will 
step forward to maintain that code, in which case it doesn't matter if 
the merge to trunk happens later, or noone wants to maintain the 
multitty code, in which case merging into trunk would be a mistake.

Re: Merging multitty

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> However, I think we more or less agreed that it would be more
>> prudent to merge the multitty stuff first and follow up with the
>> Unicode branch, since that would minimize the merge work on
>> multitty where we have less active expertise to rely on.
>>   
> I don't recall ever agreeing this, although you have asserted so
> numerous times over the last few weeks.

Hm.  Maybe the discussion was inconclusive.

> The merge between multitty and unicode will be the same, whichever
> order it is done in.
> The simple fact is that emacs-unicode-2 is ready to go onto the trunk,
> and the multitty is not due to issues mentioned in the README on
> Karoly's website.

I think we more or less agreed (modulo my possibly biased
recollections) that Emacs 23 should have the multitty functionality.
We are also not going to release Emacs 23 next week, and for people
needing a stable version of Emacs there will be EMACS_22_BASE
resp. Emacs 22.1.

So the trunk means the next place where work is going to commence.  If
more work remains for the multitty branch, that would be reason to
merge it sooner.  Another problem is that Károly is not going to be
around to help much.

I have my doubts that if we merge unicode-2 first and postpone
multitty until all issues with it are resolved, the issues will never
actually get resolved.  In particular when multitty is not kept
synched to the trunk after a unicode-2 merge.

So yes, I am aware that multitty will likely destabilize the trunk and
require work until the trunk is useful on all architectures again.

Which is sort of the point: take the multitty branch out of the
X11-only realm and have people work on making it a stable component of
trunk on all platforms.

I don't think that this is likely to happen in Károly's private
repository, I really think that we need to merge it into the trunk for
a reasonable chance to have this happen.

> Your point that Karoly is not going to be available for much longer
> is a point against merging into trunk quickly IMHO. Either someone
> else will step forward to maintain that code, in which case it
> doesn't matter if the merge to trunk happens later, or noone wants
> to maintain the multitty code, in which case merging into trunk
> would be a mistake.

I disagree with that assessment.  It presumes that not making Emacs
multitty-capable ever is a reasonable option.  But it is certainly
something that people have wanted for a long time, and it is an
embarrassing shortcoming as compared to, for example XEmacs which has
had this for very long.  While I agree that a merge of multitty will
likely cause some problems, I don't think that "will work out of the
box" should be a criterion at the _start_ of the Emacs 23 process.  We
are not aiming to release Emacs 23 simultaneously with Emacs 22.

multitty is quite an important aspect for operating Emacs as a server.
I don't think we should let the existing code go waste.

If we can't get to a more or less unanimous agreement between the
developers, it will be the call of Richard or a possibly apointed
Emacs 23 maintainer to make.

Of course, I would prefer if we could manage to reach more or less
consent without the need of reverting to authority.

-- 
David Kastrup

Re: Merging multitty

[Jason Rumney]

David Kastrup wrote:
> I think we more or less agreed (modulo my possibly biased
> recollections) that Emacs 23 should have the multitty functionality.
>   

I am not arguing against including it in Emacs 23, I just think it is a 
mistake to check code that is knowingly broken on some platforms into 
the trunk.
I will put effort into getting it working again on Windows (assuming 
noone else beats me to it), whether it is on a CVS branch or the trunk, 
as I have done with emacs-unicode-2, but due to the time I have 
available this could take a couple of months or more. I don't think it 
is acceptable to have the trunk broken for that long, as it will prevent 
some other developers who use Windows from helping with Emacs 23 
development, if they do not have the w32 api experience to help with 
fixing the multitty breakage, for example they may want to help with 
some Lisp package.

I am not asking that it be flawless before merging, just that it isn't 
horribly broken.

> I have my doubts that if we merge unicode-2 first and postpone
> multitty until all issues with it are resolved, the issues will never
> actually get resolved.  In particular when multitty is not kept
> synched to the trunk after a unicode-2 merge.
>   

Why would you not sync multitty to the trunk after the unicode-2 merge? 
Surely Karoly, Handa and anyone else willing and interested should start 
on resolving the merge problems as soon as possible. Even if we did the 
multitty merge first, we would have the same problems on the unicode-2 
branch, and would require the same people working on resolving them.

> I don't think that this is likely to happen in Károly's private
> repository, I really think that we need to merge it into the trunk for
> a reasonable chance to have this happen.
>   
I agree that it won't happen in Karoly's private repository. I have 
tried using it, but the revision control system he uses seems to be 
unstable (from a user interface perspective), and the instructions he 
gives for checking out no longer work. Reading the the latest quickstart 
guide for bazaar did not really help. But committing it to a branch ASAP 
would let the work commence on stabilizing it on other platforms ready 
for merging into trunk.

>> Your point that Karoly is not going to be available for much longer
>> is a point against merging into trunk quickly IMHO. Either someone
>> else will step forward to maintain that code, in which case it
>> doesn't matter if the merge to trunk happens later, or noone wants
>> to maintain the multitty code, in which case merging into trunk
>> would be a mistake.
>>     
>
> I disagree with that assessment.  It presumes that not making Emacs
> multitty-capable ever is a reasonable option.

It is the only option if we don't have anyone willing to maintain that 
capability. But judging from your activism on this, I don't expect we 
will have that problem.

Re: Merging multitty

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>
>> I disagree with that assessment.  It presumes that not making Emacs
>> multitty-capable ever is a reasonable option.
>
> It is the only option if we don't have anyone willing to maintain
> that capability. But judging from your activism on this, I don't
> expect we will have that problem.

My "activism" does not make me a Windows, DOS, or MacOSX developer, so
it would not carry the day.  While I don't remember a "horribly
broken" assessment either, it does not seem like I have the most
reliable of recollections about the details of the discussion.

I think it is more or less safe to say that it is about time to have
multitty moved into at least a branch in Emacs-CVS since development
in its own repository has IIRC been reduced mostly to synches, anyway.
Since its current version control system is arch-based, it sounds like
the way through the arch-variant of Emacs CVS that Miles proposed
would likely be the best way to do this: the person doing the move
would then work with a system he is familiar with on both ends.

-- 
David Kastrup

Re: Merging multitty

[Karoly Lorentey]

Jason Rumney wrote:
> I will put effort into getting it working again on Windows (assuming
> noone else beats me to it), whether it is on a CVS branch or the trunk,
> as I have done with emacs-unicode-2, but due to the time I have
> available this could take a couple of months or more. I don't think it
> is acceptable to have the trunk broken for that long, as it will
> prevent some other developers who use Windows from helping with
> Emacs 23 development, if they do not have the w32 api experience to
> help with fixing the multitty breakage, for example they may want to
> help with some Lisp package.

I agree that it would be nicer if multi-tty branch would compile on
non-GNU platforms before merging.

Fixing multi-tty on Windows and other platforms does not really need any
platform API experience: it's mostly a matter of understanding C
compiler error messages and changing references to previously global C
variables to their new terminal-local places (accessible via a frame
handle).  If the code compiles successfully, it will likely work.

>> I have my doubts that if we merge unicode-2 first and postpone
>> multitty until all issues with it are resolved, the issues will never
>> actually get resolved.  In particular when multitty is not kept
>> synched to the trunk after a unicode-2 merge.
>>   
> 
> Why would you not sync multitty to the trunk after the unicode-2 merge?
> Surely Karoly, Handa and anyone else willing and interested should start
> on resolving the merge problems as soon as possible.

Yes.  If you guys decide to merge the Unicode branch first, I'll simply
devote a weekend to resolve merge conflicts and continue syncing with
the trunk as long as necessary.

> I agree that it won't happen in Karoly's private repository. I have
> tried using it, but the revision control system he uses seems to be
> unstable (from a user interface perspective), and the instructions he
> gives for checking out no longer work. Reading the the latest quickstart
> guide for bazaar did not really help. But committing it to a branch ASAP
> would let the work commence on stabilizing it on other platforms ready
> for merging into trunk.

The inconvenience and unavailability of Arch/Bazaar on non-GNU platforms
is an excellent point.  We must create a bidirectionally synced branch
for multi-tty in Emacs CVS immediately.

>> I disagree with that assessment.  It presumes that not making Emacs
>> multitty-capable ever is a reasonable option.
> 
> It is the only option if we don't have anyone willing to maintain that
> capability. But judging from your activism on this, I don't expect we
> will have that problem.

I can definitely help maintaining the multi-tty feature set, if you
don't mind occasional delays.  A factor to consider: most if not all
multi-tty bugs I have seen so far were multi-tty specific and did not
occur with single-terminal usage. When multi-tty fails, it fails
gracefully and does not affect single-terminal users and developers.

-- 
Karoly

Re: Merging multitty

[Richard Stallman]

    Fixing multi-tty on Windows and other platforms does not really need any
    platform API experience: it's mostly a matter of understanding C
    compiler error messages and changing references to previously global C
    variables to their new terminal-local places (accessible via a frame
    handle).  If the code compiles successfully, it will likely work.

Let's install this code in a branch in the Emacs repository
immediately.  That way, other people with write access to our
repository can work on making it compile on other systems.

    Yes.  If you guys decide to merge the Unicode branch first, I'll simply
    devote a weekend to resolve merge conflicts and continue syncing with
    the trunk as long as necessary.

In that case, I agree we may as well merge the unicode-2 branch first.

Thank you for your continued help.

Re: Merging multitty

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

[ Károly wrote: ]

>     Fixing multi-tty on Windows and other platforms does not really
>     need any platform API experience: it's mostly a matter of
>     understanding C compiler error messages and changing references
>     to previously global C variables to their new terminal-local
>     places (accessible via a frame handle).  If the code compiles
>     successfully, it will likely work.
>
> Let's install this code in a branch in the Emacs repository
> immediately.

Agreed.  Károly, can you arrange with Miles to figure what it takes to
do this via his arch mirror (sounds like "archbishop" actually)?

> That way, other people with write access to our repository can work
> on making it compile on other systems.
>
>     Yes.  If you guys decide to merge the Unicode branch first, I'll
>     simply devote a weekend to resolve merge conflicts and continue
>     syncing with the trunk as long as necessary.
>
> In that case, I agree we may as well merge the unicode-2 branch first.
>
> Thank you for your continued help.

Ok, here is the beef.  We currently have the the following main
active construction sites:

EMACS_22_BASE
trunk
unicode-2
multi-tty

We have a certain lack of resources.  We currently have several
externally maintained packages in kept-back versions in our trunk in
order to cater for the release.  We have a bunch of hardly-maintained
packages in Emacs CVS.

We presumably want to minimize our workload and minimize bitrot.  We
want to maximize developer motivation and output.

We have by now pretty much fleshed out what Emacs 22.1 will look like
(basically, nothing NEWS-worthy will happen anymore).  What with Emacs
22.2 and what with the rest of the EMACS_22_BASE lifeline after 22.1
is tagged and released?

The core work for Emacs 23.1 is fleshed out already.  I strongly
suggest that we focus all attention on Emacs 23 after the release.
That means that Emacs 22 releases will just contain bugfixes, but no
package updates (unless that is absolutely the cheapest way to fix a
bug).  If there is sufficient interest for a different model, we can
appoint a _separate_ maintainer for Emacs 22 who will have the task of
integrating updates at his discretion while not destabilizing Emacs 22
in the course (separate stable branch managers are actually not
uncommon in software development).

But for the main developer taskforce (all the millions of them), Emacs
22 compatibility should not remain important.  There should be no
energy spent on keeping material in trunk compatible with Emacs 22.

For Emacs 23.x, we might adopt a different strategy if there is no
clearcut plan for Emacs 24 with a more or less clear timeline (I would
expect that the next serious architectural changes could be
bidirectional support in the display engine, and possibly some Lisp
engine changes, like quadrupling the size of Lisp integers).

But 22.x sounds like a good candidate line for a permanent feature
freeze.

If we do that, EMACS_22_BASE is mostly off the chart for continued
work.  So we have just three areas of construction remaining.

Merging unicode-2 will get us rid of another construction area.
Károly has basically agreed to take upon himself the work of keeping
multi-tty in line, so while he is able to keep up with this, we are
down to a single area of development soon.

The main question I currently see is about _when_ to open the trunk
for frozen changes: package updates and code changes that were kept
out of Emacs 22.1 because of the release process.  This is the step
that will get developers again the motivation to _improve_ Emacs all
across the board.  I don't think there is sense in opening the trunk
before merging emacs-unicode-2: code contributions should work right
away with emacs-unicode-2, and emacs-unicode-2 is quite invasive, more
so than multitty (though things like tramp would likely interreact
with both).

So I'd propose to do the following _now_: move multi-tty into a branch
of Emacs CVS.  It is likely that the branch synchronization can then
not only done by Károly (by the way, is that the polite way of
addressing you?  It is hard to figure out for me what part of a
Hungarian name one is supposd to use) but possibly Miles will also
have a handle on this where the arch thing is concerned.  We want to
merge multi-tty as soon as reasonable in order to avoid duplicate
work.

Merge unicode-2 now.  If we can agree that all of 22.x is going to be
released from the EMACS_22_BASE branch and that only bug fixes should
make it there, it does not actually matter whether Emacs 22.1 will be
tagged and released today or in two months: either way, essential bug
fixes will have to be applied to EMACS_22_BASE as well as trunk.

So this would likely end the freeze frustration and put the 22.1
release pressure out of the immediate limelight.

So _after_ the merge of unicode-2, I'd consider a lift of the trunk
freeze for general improvements reasonable.  This will be a temporary
burden for the multi-tty workers, but will take time pressure for the
"stable goal" off them.  And it looks like the architectural
specialties of multi-tty are well-confined enough so that merges will
usually be straightforward.

When are the unicode-2 people ready to merge, and would everybody else
be ok with this plan?  I understand that unicode-2 is working well and
already in active use under several but not all platforms, so it will
mean that some platforms will be cut off from Emacs variants with
updated packages (which would happen in a unicode-2 trunk, but not in
EMACS_22_BASE) for a while, as those would happen only in unicode-2
infested branches.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Merging multitty

[Kenichi Handa]

In article <854pmhdivc.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:

> When are the unicode-2 people ready to merge, and would everybody else
> be ok with this plan?

For me, unicode-2 merge can happen at any time because I've
been using only unicode-2 for long (except for the case of
debugging Emacs 22).

---
Kenichi Handa
handa@m17n.org

Re: Merging multitty

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Fixing multi-tty on Windows and other platforms does not really need any
  >     platform API experience: it's mostly a matter of understanding C
  >     compiler error messages and changing references to previously global C
  >     variables to their new terminal-local places (accessible via a frame
  >     handle).  If the code compiles successfully, it will likely work.
  > 
  > Let's install this code in a branch in the Emacs repository
  > immediately.  That way, other people with write access to our
  > repository can work on making it compile on other systems.
  > 
  >     Yes.  If you guys decide to merge the Unicode branch first, I'll simply
  >     devote a weekend to resolve merge conflicts and continue syncing with
  >     the trunk as long as necessary.
  > 
  > In that case, I agree we may as well merge the unicode-2 branch first.

How about considering the size of the code to merge before making a
decision?

For multi-tty the diffstat summary for the diff between multi-tty and
CVS HEAD is: 
(I tried to exclude all the generated files, from the diff)

 89 files changed, 5200 insertions(+), 2374 deletions(-)

For multi-tty a lot of the changes are mechanical: adding an extra
parameter to some function calls, adding an extra level of
indirection, etc.


For the emacs-unicode-2 the diffstat summary is:

 271 files changed, 29930 insertions(+), 26730 deletions(-)

For multi-tty there have not been any reports of crashes in a long
time (more than a 1 1/2 years if I recall correctly).

Given that multi-tty is a much smaller change, and it touches a much
smaller area of emacs and that the unicode branch is a much more
fundamental change, it should be easier to stabilize the trunk after
merging multi-tty. So, IMHO, it would be more efficient  to first
merge multi-tty and after that the unicode branch. 

Re: Merging multitty

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> For multi-tty there have not been any reports of crashes in a long
> time (more than a 1 1/2 years if I recall correctly).

It does not work at all on several platforms as far as I understand
and thus would completely block the trunk for unrelated development.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Merging multitty

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > For multi-tty there have not been any reports of crashes in a long
  > > time (more than a 1 1/2 years if I recall correctly).
  > 
  > It does not work at all on several platforms as far as I understand
  > and thus would completely block the trunk for unrelated development.

That has been know for several years, and it has not changed. And it
probably won't change until the branch is merged. Karoly says that
it's mostly fixing compilation errors. I would still guesstimate that
the total disruption would be less.

Re: Merging multitty

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > 
>   > > For multi-tty there have not been any reports of crashes in a long
>   > > time (more than a 1 1/2 years if I recall correctly).
>   > 
>   > It does not work at all on several platforms as far as I understand
>   > and thus would completely block the trunk for unrelated development.
>
> That has been know for several years, and it has not changed. And it
> probably won't change until the branch is merged.

There is no branch to merge yet.  We first need to get it into a
branch.  Then people will have a chance to work on it.  At the moment,
it is only kept in a completely different repository.

> Karoly says that it's mostly fixing compilation errors. I would
> still guesstimate that the total disruption would be less.

I don't think it would be a good idea to merge it into trunk before
other people actually had a chance of assessing the problems and
working with them.  Up to now, all we have about the other platforms
are guesses.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Merging multitty

[Samium Gromoff]

At Sat, 12 May 2007 12:32:08 -0700,
Dan Nicolaescu wrote:
> For multi-tty there have not been any reports of crashes in a long
> time (more than a 1 1/2 years if I recall correctly).

I'm all for multi-tty going in, as a user, but i have to say that
it was crashing pretty reliably for me, across many builds, in the past.

The current incarnation seems to be ok, so far, though.

regards, Samium Gromoff

Re: Merging multitty

[Károly Lo"rentey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Rumney wrote:
> I will put effort into getting it working again on Windows (assuming
> noone else beats me to it), whether it is on a CVS branch or the trunk,
> as I have done with emacs-unicode-2, but due to the time I have
> available this could take a couple of months or more. I don't think it
> is acceptable to have the trunk broken for that long, as it will
> prevent some other developers who use Windows from helping with
> Emacs 23 development, if they do not have the w32 api experience to
> help with fixing the multitty breakage, for example they may want to
> help with some Lisp package.

I agree that it would be nicer if multi-tty branch would compile on
non-GNU platforms before merging.

Fixing multi-tty on Windows and other platforms does not really need any
platform API experience: it's mostly a matter of understanding C
compiler error messages and changing references to previously global C
variables to their new terminal-local places (accessible via a frame
handle).  If the code compiles successfully, it will likely work.

>> I have my doubts that if we merge unicode-2 first and postpone
>> multitty until all issues with it are resolved, the issues will never
>> actually get resolved.  In particular when multitty is not kept
>> synched to the trunk after a unicode-2 merge.
>>   
> 
> Why would you not sync multitty to the trunk after the unicode-2 merge?
> Surely Karoly, Handa and anyone else willing and interested should start
> on resolving the merge problems as soon as possible.

Yes.  If you guys decide to merge the Unicode branch first, I'll simply
devote a weekend to resolve merge conflicts and continue syncing with
the trunk as long as necessary.

> I agree that it won't happen in Karoly's private repository. I have
> tried using it, but the revision control system he uses seems to be
> unstable (from a user interface perspective), and the instructions he
> gives for checking out no longer work. Reading the the latest quickstart
> guide for bazaar did not really help. But committing it to a branch ASAP
> would let the work commence on stabilizing it on other platforms ready
> for merging into trunk.

The inconvenience and unavailability of Arch/Bazaar on non-GNU platforms
is an excellent point.  We must create a bidirectionally synced branch
for multi-tty in Emacs CVS immediately.

>> I disagree with that assessment.  It presumes that not making Emacs
>> multitty-capable ever is a reasonable option.
> 
> It is the only option if we don't have anyone willing to maintain that
> capability. But judging from your activism on this, I don't expect we
> will have that problem.

I can definitely help maintaining the multi-tty feature set, if you
don't mind occasional delays.  A factor to consider: most if not all
multi-tty bugs I have seen so far were multi-tty specific and did not
occur with single-terminal usage. When multi-tty fails, it fails
gracefully and does not affect single-terminal users and developers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGRNu46eoyqA+yej8RAk87AKCZtQMGIt2GMPbvNRuBmVARgoE3PgCeLNxN
LvWCpxDkus+V5vYOm53JRNg=
=KMEG
-----END PGP SIGNATURE-----

Re: Merging multitty

[Kenichi Handa]

In article <867irf3cjo.fsf@lola.quinscape.zz>, David Kastrup <dak@gnu.org> writes:

> So yes, I am aware that multitty will likely destabilize the trunk and
> require work until the trunk is useful on all architectures again.

At least, merging unicode-2 doesn't make the trunk unuseful
for any architecture, so I think it must be the first.  It
may cause some problem, but it is just because that part is
not yet tested by any of unicode-2 users.  Once the problem
is reported, I think I can fix it quite soon.

Currently Miles is synchronizing unicode-2 to the trunk
periodically (great thanks for that effort).  If we merge
multitty to the trunk at first, and make the trunk unuseful
for some architecture, unicode-2 branch will also be
unuseful for that architecture after Miles synchronization,
which I do want to avoid.

Unicode branch has been there for more than 5 years, and we
should think that it is a kind of big bugfix for the current
weird/complicated character handling.

---
Kenichi Handa
handa@m17n.org

Re: Merging multitty

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <867irf3cjo.fsf@lola.quinscape.zz>, David Kastrup <dak@gnu.org> writes:
>
>> So yes, I am aware that multitty will likely destabilize the trunk and
>> require work until the trunk is useful on all architectures again.
>
> At least, merging unicode-2 doesn't make the trunk unuseful
> for any architecture, so I think it must be the first.

That is assuming that the trunk should always be working for all
architectures.  I have my doubts that this is the best way to make
progress.  It certainly will be more convenient for people wanting to
_use_ the trunk as opposed to _work_ on it.

At the current point of time, the trunk _is_ more or less what people
are used to using for their everyday work, and snapshots are made from
it and provided as packaged, useful variants of Emacs.

I am not convinced that we will make speedy progress to Emacs 23 if we
insist on maintaining this state.  I think that it is more reasonable
to have this sort of stability on release branches rather than the
trunk.  In particular when we are talking about the _start_ of a new
version.

> Currently Miles is synchronizing unicode-2 to the trunk
> periodically (great thanks for that effort).  If we merge
> multitty to the trunk at first, and make the trunk unuseful
> for some architecture, unicode-2 branch will also be
> unuseful for that architecture after Miles synchronization,
> which I do want to avoid.

A valid concern.  It would probably make sense to cease the
synchronization while the work on multitty is stabilized.

> Unicode branch has been there for more than 5 years, and we should
> think that it is a kind of big bugfix for the current
> weird/complicated character handling.

The concern seems to be that people want to have some more-or-less
stable version of unicode-2 that is kept up-to-date with other work.

If we merge unicode-2 first, the unicode-2 branch is dead.  When
merging multitty afterwards, there will be no current variant of
unicode-2 without multitty.

Merging multitty first will leave us with the following:
a) a release (or release branch) for Emacs 22
b) a destabilized trunk containing multitty that needs to get brought
   up to scratch on all platforms
c) a unicode-2 branch that continues to provide something from which
   one can snapshot Emacs 23.0

Merging unicode-2 first will leave us with:
a) a release (or release branch) for Emacs 23
b) a trunk from which one should be able to provide Emacs 23.0
   snapshots soonish, but without multitty.
c) a multitty branch that needs to get merged with the trunk now
containing Emacs 23.0

The second variant makes separate sense of its own mainly if one
_delays_ merging the multitty branch until it has stabilized on all
platforms.

I don't see that happening by magic.

In short: I am afraid that the second variant will be a "shortcut"
that will not lead to a faster release of Emacs 23, but rather provide
us with a longer "comfort period" on the trunk where the multitty
problems are not being addressed seriously.

-- 
David Kastrup

Re: Merging multitty

[Juanma Barranquero]

On 5/11/07, David Kastrup <dak@gnu.org> wrote:

> It certainly will be more convenient for people wanting to
> _use_ the trunk as opposed to _work_ on it.

No. It will be more convenient for people wanting to _work_ on the
trunk on things _other_ than the multitty support.

> I am not convinced that we will make speedy progress to Emacs 23 if we
> insist on maintaining this state.

There's a difference between breaking the trunk every now and then,
with the understanding that the issues will be fixed ASAP, and
breaking it and saying "here, if you want to use it, start by fixing
it". In particular, the multitty branch is said not to work on
Windows; and Emacs Windows developers are scarce. What if none of us
has the time, knowledge or inclination to fix the multitty code soon?
Saying "use a release branch, then" is a non-answer.

> The second variant makes separate sense of its own mainly if one
> _delays_ merging the multitty branch until it has stabilized on all
> platforms.

Which is a fine idea by itself.

> I don't see that happening by magic.

Either there is people willing to fix the problems in the multitty
branch, and then a branch is fine, or there is not, and then forcing
it on the trunk it's not going to help much (if anything, it'll
diminish some people's enthusiasm).

             Juanma

Re: Merging multitty

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 5/11/07, David Kastrup <dak@gnu.org> wrote:
>
>> It certainly will be more convenient for people wanting to
>> _use_ the trunk as opposed to _work_ on it.
>
> No. It will be more convenient for people wanting to _work_ on the
> trunk on things _other_ than the multitty support.

Good point.  But if other things happen to destabilize the trunk, it
will not exactly help getting a multitty branch into good shape.

>> The second variant makes separate sense of its own mainly if one
>> _delays_ merging the multitty branch until it has stabilized on all
>> platforms.
>
> Which is a fine idea by itself.
>
>> I don't see that happening by magic.
>
> Either there is people willing to fix the problems in the multitty
> branch, and then a branch is fine, or there is not, and then forcing
> it on the trunk it's not going to help much (if anything, it'll
> diminish some people's enthusiasm).

I can see your point.

At any rate, I find that we should move the repository of multitty
_fast_ into the Emacs repository (as a trunk for now), and likely by
way of Miles' arch mirror.

If we don't do that, I don't see multitty going anywhere.

multitty is an architectural change slated for Emacs 23.  trunk or
not, it will be important that people bother with it eventually.  But
it is reasonable to assume that only a subset of the current (and
possibly revived or new) developers will feel able to contribute to
this work, and blocking the others in the mean time does not seem like
a good idea either.

I would however think it prudent to _first_ have the multitty branch
put into place and synchronized before we do the unicode-2 merge into
the trunk.  That will be the best shot we may have at keeping the
multitty branch in a state where its developers have mostly to worry
about multitty issues.

And it would be good if people familiar with unicode-2 would also help
with merging the trunk change into the multitty branch (since they
probably will best know how to deal with the conflicts).

In short: even if we put multitty into a branch, we should give it the
best kickoff we can manage.

-- 
David Kastrup

Re: Merging multitty

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> At any rate, I find that we should move the repository of multitty
> _fast_ into the Emacs repository (as a trunk for now), and likely by
> way of Miles' arch mirror.

As a _branch_ for now, of course.  Sigh.

-- 
David Kastrup

Re: Merging multitty

[Jason Rumney]

David Kastrup wrote:
> David Kastrup <dak@gnu.org> writes:
>
>   
>> At any rate, I find that we should move the repository of multitty
>> _fast_ into the Emacs repository (as a trunk for now), and likely by
>> way of Miles' arch mirror.
>>     
>
> As a _branch_ for now, of course.  Sigh.
>   

I'm definitely in agreement on that.

Re: Merging multitty

[Juanma Barranquero]

On 5/11/07, David Kastrup <dak@gnu.org> wrote:

> Good point.  But if other things happen to destabilize the trunk, it
> will not exactly help getting a multitty branch into good shape.

Agreed.

> I would however think it prudent to _first_ have the multitty branch
> put into place and synchronized before we do the unicode-2 merge into
> the trunk.

Seems like a good plan, as long as it is done soon.

> In short: even if we put multitty into a branch, we should give it the
> best kickoff we can manage.

Agreed.

             Juanma

Re: Merging multitty

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> I would however think it prudent to _first_ have the multitty branch
> put into place and synchronized before we do the unicode-2 merge into
> the trunk.  That will be the best shot we may have at keeping the
> multitty branch in a state where its developers have mostly to worry
> about multitty issues.
>
> And it would be good if people familiar with unicode-2 would also help
> with merging the trunk change into the multitty branch (since they
> probably will best know how to deal with the conflicts).

You're right that probably the first thing to do is make a multi-tty
branch in the emacs arch/CVS repository.  Then at least it becomes easy
to find and use by developers (and easily kept synced by us), and the
platform maintainers can check it out and maybe do some porting work on it.

If it seems in good shape, we can then merge the unicode branch into the
multi-tty branch and see how that turns out (I don't expect too many
conflicts to be honest, but who knows...).  It's easy to do that
periodically afterwards, so it can be kept up to date (with both the
unicode branch, and indirectly with the trunk).

If there _are_ unicode->multi-tty problems they can be worked on slowly
in the multi-tty branch; most importantly, no other important branch
will be affected (multi-tty is nice but it's far less important than the
unicode branch).

So when it comes time to actually merge to the trunk there will be two
choices:  unicode or multi-tty+unicode (since the multi-tty will contain
the unicode branch).  The merge should be equally easy, as they will
both be periodically synced, so the decision can be based purely on
whether the multi-tty stuff is stable enough.  If it's decided to only
merge the unicode branch to the trunk, the multi-tty branch will be easy
to keep up to date, because it will already contain the unicode branch.

-Miles
-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: Merging multitty

[Karoly Lorentey]

Juanma Barranquero wrote:
> In particular, the multitty branch is said not to work on
> Windows; and Emacs Windows developers are scarce. What if none of us
> has the time, knowledge or inclination to fix the multitty code soon?

Then I'll bite the bullet and at some point I'll do the porting myself;
I assume nt/INSTALL is right and I need only GNU tools and the
obligatory copy of Windows that I bought with my box.

I can't do the same for the Mac port, though.

-- 
Karoly

Re: Merging multitty

[Eli Zaretskii]

> Date: Fri, 11 May 2007 23:34:38 +0200
> From: Karoly Lorentey <karoly@lorentey.hu>
> Cc: Kenichi Handa <handa@m17n.org>, emacs-devel@gnu.org
> 
> I assume nt/INSTALL is right and I need only GNU tools and the
> obligatory copy of Windows that I bought with my box.

Yes, nt/INSTALL is right and up-to-date.

If you want advice regarding the several options of where to get
ported GNU tools, please don't hesitate to ask here.

merging Unicode branch and availability of Windows binaries

[Drew Adams]

Caveat: I haven't followed the merge thread closely, and I'm ignorant of
most of what you are discussing there.

Question: Regardless of what you decide about merging, will there be
available for users, somewhere, a Windows binary of the 22 release (as it is
before merge of the Unicode branch)? Until now, I've only found Windows
binaries of the latest CVS build, which, after the merge, would presumably
include Unicode.

I ask because I've had reports by an Icicles user on Emacs 23 (Unicode) that
Icicles key completion does not work with that version. I don't have a
Windows binary of 23, so I haven't been able to look at the problem. If
Emacs 23 treatment of keymaps or key bindings is very different, then
perhaps I'll need to start over, to implement key-completion differently.
(Or perhaps key completion will be impossible or unfeasible for the Unicode
version.)

I would like for Emacs users to continue to be able to find Windows binaries
of the stable Emacs 22, even after Emacs 23 is merged, and I would like,
myself, to be able to find a Windows binary of Emacs 23 (before or after the
merge), to be able to look into the Icicles key-completion problems. Until
now, I've been using Lennart's vanilla Emacs 22 builds on Windows, but I
don't know what Lennart will make available after the merge. My question is,
will I be able to find binaries of both Emacs 22 (without Unicode) and 23
(with Unicode) after the merge? Will the former be available from GNU, for
instance, and the latter from Lennart? Or both from Lennart?

RE: merging Unicode branch and availability of Windows binaries

[Drew Adams]

Resending.

> Sent: Friday, May 11, 2007 6:35 AM
> Caveat: I haven't followed the merge thread closely, and I'm ignorant of
> most of what you are discussing there.
>
> Question: Regardless of what you decide about merging, will there be
> available for users, somewhere, a Windows binary of the 22
> release (as it is
> before merge of the Unicode branch)? Until now, I've only found Windows
> binaries of the latest CVS build, which, after the merge, would presumably
> include Unicode.
>
> I ask because I've had reports by an Icicles user on Emacs 23
> (Unicode) that
> Icicles key completion does not work with that version. I don't have a
> Windows binary of 23, so I haven't been able to look at the problem. If
> Emacs 23 treatment of keymaps or key bindings is very different, then
> perhaps I'll need to start over, to implement key-completion differently.
> (Or perhaps key completion will be impossible or unfeasible for
> the Unicode
> version.)
>
> I would like for Emacs users to continue to be able to find
> Windows binaries
> of the stable Emacs 22, even after Emacs 23 is merged, and I would like,
> myself, to be able to find a Windows binary of Emacs 23 (before
> or after the
> merge), to be able to look into the Icicles key-completion problems. Until
> now, I've been using Lennart's vanilla Emacs 22 builds on Windows, but I
> don't know what Lennart will make available after the merge. My
> question is,
> will I be able to find binaries of both Emacs 22 (without Unicode) and 23
> (with Unicode) after the merge? Will the former be available from GNU, for
> instance, and the latter from Lennart? Or both from Lennart?

Re: merging Unicode branch and availability of Windows binaries

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> Resending.

Why?

>> Sent: Friday, May 11, 2007 6:35 AM
>> Caveat: I haven't followed the merge thread closely, and I'm
>> ignorant of most of what you are discussing there.

If it is important enough for you to resend, wouldn't it be important
enough to read the thread?

>> Question: Regardless of what you decide about merging, will there
>> be available for users, somewhere, a Windows binary of the 22
>> release (as it is before merge of the Unicode branch)? Until now,
>> I've only found Windows binaries of the latest CVS build, which,
>> after the merge, would presumably include Unicode.

The EMACS_22_BASE will, obviously, not be merged with unicode-2, and
that is what Emacs 22.1 will be released from "real soon now"(TM).

-- 
David Kastrup

RE: merging Unicode branch and availability of Windows binaries

[Drew Adams]

> > Resending.
> Why?

Because there was no reply to my question.

> >> Caveat: I haven't followed the merge thread closely, and I'm
> >> ignorant of most of what you are discussing there.
>
> If it is important enough for you to resend, wouldn't it be important
> enough to read the thread?

I did read it. I did not find my question answered in it, so I posed it
explicitly. Do you have the answer, or do you just want to hassle?

> >> Question: Regardless of what you decide about merging, will there
> >> be available for users, somewhere, a Windows binary of the 22
> >> release (as it is before merge of the Unicode branch)? Until now,
> >> I've only found Windows binaries of the latest CVS build, which,
> >> after the merge, would presumably include Unicode.
>
> The EMACS_22_BASE will, obviously, not be merged with unicode-2, and
> that is what Emacs 22.1 will be released from "real soon now"(TM).

I asked about Windows binaries. Where will one be able to find a Windows
binary of Emacs 22?

Re: merging Unicode branch and availability of Windows binaries

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> Because there was no reply to my question.
>
>> >> Caveat: I haven't followed the merge thread closely, and I'm
>> >> ignorant of most of what you are discussing there.
>>
>> If it is important enough for you to resend, wouldn't it be important
>> enough to read the thread?
>
> I did read it. I did not find my question answered in it, so I posed it
> explicitly. Do you have the answer, or do you just want to hassle?
>
>> >> Question: Regardless of what you decide about merging, will there
>> >> be available for users, somewhere, a Windows binary of the 22
>> >> release (as it is before merge of the Unicode branch)? Until now,
>> >> I've only found Windows binaries of the latest CVS build, which,
>> >> after the merge, would presumably include Unicode.
>>
>> The EMACS_22_BASE will, obviously, not be merged with unicode-2, and
>> that is what Emacs 22.1 will be released from "real soon now"(TM).
>
> I asked about Windows binaries. Where will one be able to find a Windows
> binary of Emacs 22?

Same places where you now find Emacs 21 binaries.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Merging multitty

[Richard Stallman]

    Your point that Karoly is not going to be available for much longer is a 
    point against merging into trunk quickly IMHO. Either someone else will 
    step forward to maintain that code, in which case it doesn't matter if 
    the merge to trunk happens later, or noone wants to maintain the 
    multitty code, in which case merging into trunk would be a mistake.

If the code is working, well commented, and clear, then once it is
merged in, people will learn to maintain it.  So I agree with those
that think it is better to merge multi-tty first -- if it is working,
well commented, and clear.

If there are some cases it does not handle yet, that is no great problem
as long as it doesn't totally break those cases, and as long as the gaps
are well documented.

Re: Merging multitty

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Comments, better ideas?

It might be better to merge into the arch version of the trunk, and then
let that be committed to CVS.  The multi-tty is already in arch, so
merging back into the arch-trunk should be basically trivial, and using
the regular arch->CVS gateway is probably safer than doing a one-off.

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Merging multitty

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> David Kastrup <dak@gnu.org> writes:
>> Comments, better ideas?
>
> It might be better to merge into the arch version of the trunk, and then
> let that be committed to CVS.  The multi-tty is already in arch, so
> merging back into the arch-trunk should be basically trivial, and using
> the regular arch->CVS gateway is probably safer than doing a one-off.

This sounds like a good idea.

-- 
David Kastrup

Re: Merging multitty

[Richard Stallman]

    It might be better to merge into the arch version of the trunk, and then
    let that be committed to CVS.  The multi-tty is already in arch, so
    merging back into the arch-trunk should be basically trivial, and using
    the regular arch->CVS gateway is probably safer than doing a one-off.

What does arch->CVS give in the way of CVS log entries?
I hope it does not put the entire change log into each file's CVS log!

Re: Merging multitty

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> What does arch->CVS give in the way of CVS log entries?
> I hope it does not put the entire change log into each file's CVS log!

I would use something simple like "Merge multi-tty branch"
(i.e., exactly what someone merging using CVS would use).

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: Merging multitty

[Nick Roberts]

 > > What does arch->CVS give in the way of CVS log entries?
 > > I hope it does not put the entire change log into each file's CVS log!
 > 
 > I would use something simple like "Merge multi-tty branch"
 > (i.e., exactly what someone merging using CVS would use).

In that case, where would the log for each file's multi-tty related changes be,
and would you be able to access them from CVS? 

When merging using CVS, e.g, for emacs-unicode-2, the log for related changes
can presumably be found in the branch.  Do you do an import first?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Merging multitty

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
> In that case, where would the log for each file's multi-tty related changes be,
> and would you be able to access them from CVS? 

The multi-tty branch has never been in CVS (anywhere), so you'll have to
use arch to see historical log entries.

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Merging multitty

[Nick Roberts]

 > > In that case, where would the log for each file's multi-tty related
 > > changes be, and would you be able to access them from CVS?
 > 
 > The multi-tty branch has never been in CVS (anywhere), so you'll have to
 > use arch to see historical log entries.

You've not answered the first part of my question.  It's not clear to me that
the logs will be in the Emacs repository at Savannah at all, arch or otherwise.

Even if they are accessible from the Emacs repository using arch only, I'm not
sure that's desirable.  AFAIK most of us don't still know how to use it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Merging multitty

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  > > In that case, where would the log for each file's multi-tty related
>  > > changes be, and would you be able to access them from CVS?
>  > 
>  > The multi-tty branch has never been in CVS (anywhere), so you'll have to
>  > use arch to see historical log entries.
>
> You've not answered the first part of my question.  It's not clear to me that
> the logs will be in the Emacs repository at Savannah at all, arch or otherwise.

Which logs, exactly, are you talking about?

The savannah arch branch will contain all the information the original
non-savannah branch, including commit logs (commit logs are essentially
part of the tree in arch).  However these are not per-file logs (arch,
as is typical for modern revision control systems, has no such thing),
but rather per-changeset logs.

These will _not_ be put into the CVS logs when the merge into CVS is
done (that is exactly what Richard asked me not to do).

However, it might make sense to put them into a file in the tree for
non-arch users to peruse.  [There is a command which produces a
ChangeLog-like single-file representation of the commit logs, so it's
quite easy to do so.]

-Miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: Merging multitty

[Karoly Lorentey]

Miles Bader wrote:
> The savannah arch branch will contain all the information the original
> non-savannah branch, including commit logs (commit logs are essentially
> part of the tree in arch).  However these are not per-file logs (arch,
> as is typical for modern revision control systems, has no such thing),
> but rather per-changeset logs.
> 
> These will _not_ be put into the CVS logs when the merge into CVS is
> done (that is exactly what Richard asked me not to do).
> 
> However, it might make sense to put them into a file in the tree for
> non-arch users to peruse.  [There is a command which produces a
> ChangeLog-like single-file representation of the commit logs, so it's
> quite easy to do so.]

Yes.  I always assumed that at some point we will have to integrate my
logs into Emacs's ChangeLog files.

In Arch, the logs follow the RFC 822 message format.  FYI, this is how a
typical log entry looks like:  (There are ~366 of these in the branch.)

	Revision: emacs--multi-tty--0--patch-562
	Archive: lorentey@elte.hu--2004
	Creator: Karoly Lorentey <lorentey@elte.hu>
	Date: Sat May 20 14:20:41 CEST 2006
	Standard-date: 2006-05-20 12:20:41 GMT
	Modified-files: src/term.c src/termhooks.h src/terminal.c
	    src/xterm.c
	New-patches: 	lorentey@elte.hu--2004/emacs--multi-tty--0--patch-562
	Summary: Fix crashes in `delete-terminal' caused by recursive 	calls or
X displays with live frames.
	Keywords:

	* src/termhooks.h (terminal) <deleted>: New member.

	* src/term.c (delete_tty): Use it.
	  (deleting_tty): Remove old variable.
	
	* src/terminal.c (delete_terminal): Use terminal->deleted.

	* src/xterm.c (x_delete_terminal): Use terminal->deleted.
	  Delete all frames on the display explicitly.

We will have to tweak the filenames and split the logs for src/, lisp/
and the rest into separate ChangeLog files, but otherwise I hope the
body of the log message follows Emacs conventions.

BTW, I love the short Summary: line describing the reasons for the
change.  It's a shame we'll have to discard those.

-- 
Karoly

Re: Merging multitty

[Richard Stallman]

    The multi-tty branch has never been in CVS (anywhere), so you'll have to
    use arch to see historical log entries.

That is not good.  Please do not do it.

What needs to be done is this: for each file, extract all its change log items
from the arch changeset change logs (or from ChangLog), and use that as
the CVS log for the file.

    > However, it might make sense to put them into a file in the tree for
    > non-arch users to peruse.

That file is called ChangeLog.  "Merged XYZ branch" is not acceptable
in ChangeLog as a substitute for the actual change log entries.

If the file ChangeLog has not been maintained for the multi-tty
branch, then part of putting it into the Emacs repository is creating
the necessary ChangeLog entries.

    Ok, I've put the multi-tty sources into CVS and arch branches on
    savannah.

Did you do it right, as described above?
If not, it has to be done over.

Re: Merging multitty

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> What needs to be done is this: for each file, extract all its change
> log items from the arch changeset change logs (or from ChangLog), and
> use that as the CVS log for the file.
...
>     Ok, I've put the multi-tty sources into CVS and arch branches on
>     savannah.
>
> Did you do it right, as described above?
> If not, it has to be done over.

I'm sorry, if you want such a thing, you'll have to find somebody else
to do it.  It would be a huge hassle (I use hypothetical "would be"
because to my knowledge, nobody has ever done a merge that way in CVS),
and is simply unnecessary.

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Merging multitty

[Karoly Lorentey]

Richard Stallman wrote:
> What needs to be done is this: for each file, extract all its change log items
> from the arch changeset change logs (or from ChangLog), and use that as
> the CVS log for the file.

With all due respect, that seems an unreasonable request.  The branch is more
than three years old, with hundreds of documented changesets.

Do you have a tool to automatically convert ChangeLog files to individualized
CVS logs?

>     > However, it might make sense to put them into a file in the tree for
>     > non-arch users to peruse.
> 
> That file is called ChangeLog.  "Merged XYZ branch" is not acceptable
> in ChangeLog as a substitute for the actual change log entries.

I think Miles was talking about the CVS log, not ChangeLog.

> If the file ChangeLog has not been maintained for the multi-tty
> branch, then part of putting it into the Emacs repository is creating
> the necessary ChangeLog entries.

The log was maintained in Emacs ChangeLog entry style, but in the Arch logs.
Part of the merge effort is to convert these logs into flat ChangeLog files.
That's very reasonable.  They are not yet there, but they will be soon.

-- 
Karoly

Re: Merging multitty

[Kim F. Storm]

Karoly Lorentey <karoly@lorentey.hu> writes:

> Richard Stallman wrote:
>> What needs to be done is this: for each file, extract all its change log items
>> from the arch changeset change logs (or from ChangLog), and use that as
>> the CVS log for the file.
>
> The log was maintained in Emacs ChangeLog entry style, but in the Arch logs.
> Part of the merge effort is to convert these logs into flat ChangeLog files.
> That's very reasonable.  They are not yet there, but they will be soon.

I think that is sensible.

The ChangeLog files will show the detailed changes (with a suitable
header line) like this:


2007-06-01  Karoly Lorentey <karoly@lorentey.hu>

	Merge multi-tty branch to trunk.

        * file1 (func1): ...

        * file2 (func2): ...


etc.


The cvs logs will just say "Merge multi-tty branch to trunk".

That is more than adequate to follow the changes -- and in such cases,
the individual changes to each file doesn't really make much sense on
their own anyway.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Merging multitty

[Richard Stallman]

    The log was maintained in Emacs ChangeLog entry style, but in the
    Arch logs.  Part of the merge effort is to convert these logs into
    flat ChangeLog files.  That's very reasonable.  They are not yet
    there, but they will be soon.

That is good news.

    I think Miles was talking about the CVS log, not ChangeLog.

These are two ways of representing the change log.
Do you really think that the CVS log is not important?

If it is acceptable to tell people, "don't look at the CVS log,
always look at ChangeLog", then we could be sloppy about the CVS
log.  But I don't think the CVS log is that unimportant.
I look there for info, and I think others do too.

    With all due respect, that seems an unreasonable request.  The branch is more
    than three years old, with hundreds of documented changesets.

The work of collating the change log entries will be much less than
the work it took to write these change log entries in the first place.
And that's not to mention the work of writing the code.  Compared with
the overall size of the task, this is small.

Please don't make a disproportionate fuss over it.

    Do you have a tool to automatically convert ChangeLog files to individualized
    CVS logs?

No, but if this would make the job easier, I am sure people can work on it.

Note, however, that big simplifications are often possible when combining
changes made over a long period.

If a function is new in the multi-tty branch, the only change log it
needs now is "new function".  If you added on date A, and changed it
on date B, the entry for date B can usually be deleted.

I am not sure a program could make these simplifications.

Re: Merging multitty

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 15 May 2007 05:46:41 -0400
> Cc: nickrob@snap.net.nz, emacs-devel@gnu.org, miles.bader@necel.com,
> 	miles@gnu.org
> 
>     I think Miles was talking about the CVS log, not ChangeLog.
> 
> These are two ways of representing the change log.
> Do you really think that the CVS log is not important?
> 
> If it is acceptable to tell people, "don't look at the CVS log,
> always look at ChangeLog", then we could be sloppy about the CVS
> log.  But I don't think the CVS log is that unimportant.
> I look there for info, and I think others do too.

CVS log entries are indeed very important because they are linked to
specific CVS versions, while the ChangeLog entries are not.  Thus,
without CVS logs, it is very hard to reproduce the _exact_ source
level changes that were installed.

However, in this particular case, the entire multi-tty branch is being
merged in one swell whoop, so individual CVS log entries for each and
every change will not add any useful info at all.  Thus, I think in
this case it is okay to have a full list of changes either in CVS or
in ChangeLog (whichever is easier for the folks who do the arch-to-CVS
conversion), but it is not necessary to have both.

Re: Merging multitty

[Richard Stallman]

    > If a function is new in the multi-tty branch, the only change log it
    > needs now is "new function".  If you added on date A, and changed it
    > on date B, the entry for date B can usually be deleted.
    >=20
    > I am not sure a program could make these simplifications.

    Do you mean that we can simplify ChangeLog as well, or do you want this
    shortening to only apply to the CVS logs?

This simplification can be done in ChangeLog too.

So I guess we could use a program to split it up file by file,
and run that program on the hand-simplified ChangeLog file.

Re: Reordering etc/NEWS

[Richard Stallman]

    Whether you then feel offended or badgered by my concerns and the ways
    I have expressed them (I admit to have been exaggerating at times due
    to my growing frustration) is your choice.

I do not remember who said what, so I am not speaking about anyone in
particular, just about what was said overall.

Badgering is not a question of motive.  It means pressuring through
repeated harsh demands.  That is precisely what was being done here to
me.  Whatever the motive may have been, I don't want to be treated
that way.

If people want to raise an issue with me without pressuring me, then I
will discuss it rationally.  However, I won't accept the sheer numbers
of people who disagree with me as proof that I'm mistaken.

We have had a feature freeze for many months, but it is a small
fraction of the time that has gone by since the Emacs 21 release.  So
don't sweat it.  And please don't make a big deal about whether it
will take another week, or even another few weeks, to make the
release.  I will get it done as soon as practical.

Re: Reordering etc/NEWS

[Juanma Barranquero]

On 5/10/07, Richard Stallman <rms@gnu.org> wrote:

> However, I won't accept the sheer numbers
> of people who disagree with me as proof that I'm mistaken.

On the issue of software release procedures, what would you take as
proof that the one we're using (or were using until yesterday, when
you "opened" the trunk) is failed? (Honest question, no sarcasm or
badgering.)

I ask because I fully agree with you that one person can be right
against a hundred, but OTOH software management is not exactly a new
field; there is a considerable know-how, both in this list and in the
software engineering world at large. If you're not accepting the
arguments of very knowledgeable people here on the list, I'm curious
about your reasons.

> And please don't make a big deal about whether it
> will take another week, or even another few weeks, to make the
> release.

Agreed 100%. After five years of development, a week or a month is
irrelevant (at least, once the trunk is open and non-release-related
development can start again).

             Juanma

Re: Reordering etc/NEWS

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 5/10/07, Richard Stallman <rms@gnu.org> wrote:
>
>> And please don't make a big deal about whether it will take another
>> week, or even another few weeks, to make the release.
>
> Agreed 100%. After five years of development, a week or a month is
> irrelevant (at least, once the trunk is open and non-release-related
> development can start again).

But the trunk currently is not open.  It is not clear what kind of
work can commence there.

-- 
David Kastrup

Re: Reordering etc/NEWS

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On 5/10/07, David Kastrup <dak@gnu.org> wrote:

> But the trunk currently is not open.

OK: It is now unaffected by Emacs 22.X releases (at least, for small
values of X :)

> It is not clear what kind of work can commence there.

Agreed.

There was a comment (sorry, I forgot by whom) saying that whether to
merge the unicode and multitty branches or not could depend on the new
maintainer's plans, assuming Richard has selected (or will do) a new
maintainer.

However, it is hard to imagine that a new maintainer wouldn't want to
merge both branches (or, at the very least, the unicode one) and move
along happily towards 23.1. So, I'd vote to merge emacs-unicode-2
ASAP.

My .02€ + VAT

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Reordering etc/NEWS

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> However, it is hard to imagine that a new maintainer wouldn't want
> to merge both branches (or, at the very least, the unicode one) and
> move along happily towards 23.1. So, I'd vote to merge
> emacs-unicode-2 ASAP.

Interesting.  I thought we had already agreed that it would be prudent
to merge the multitty branch first since the availability of Károly
was limited and of course the first merge will be easier (since it is
in essence already done).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

On 5/10/07, David Kastrup <dak@gnu.org> wrote:

> Interesting.  I thought we had already agreed that it would be prudent
> to merge the multitty branch first since the availability of Károly
> was limited and of course the first merge will be easier (since it is
> in essence already done).

Ah. I missed that. Well, at this point any "movement" is OK to me :)

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Reordering etc/NEWS

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> If people want to raise an issue with me without pressuring me, then I
> will discuss it rationally.

I think my recent posts have met this criterion.  Basically, I
proposed always having an open trunk (or some place where new changes
can be checked in).  We'd use branches:

   a) To isolate release lines from trunk churn.
   b) To isolate trunk from large, unstable batches of new code until
      that code is ready.

Such a system can be started at any point, and would allow pent-up
development energy to be put to constructive use.  I've seen it work
very well on other projects.

Thanks,
-Karl

Re: Reordering etc/NEWS

[Ken Manheimer]

this doesn't seem to me to be a good time to try to settle problems
with the development process.  it's unprecedented that a single,
finite issue has been identified as being the only release blocker,
and there is a lot of tension built up around the release and the
process.  it looks like there will be genuine opportunity to address
the development process after the release, and the facts of the way
the process has gone are not going to fade.

sometimes you have to wait.  more.  personally, i urgently want the
pending multi-tty capabilities
(http://lorentey.hu/project/emacs.html), but i see settling the
release as much more important, no question, even if it means missing
a window to land lorentey's changes .  likewise with other
developments - when someone is maxed out, telling them "just give me
instructions and i can get out of your hair" often is more load for
the subject than that requester realizes.

(incidentally, this seems like the worst possile moment for questions
about perceptions of failures in the process.  talk about loaded
questions!  how could you expect a productive conversation about that
right now?  i would wait on that kind of thing, unless you honestly
think they're needed for a direction change that will help *right
now*.)

i like emacs 22.  a lot.  i look forward to it landing.
-- 
ken manheimer
http://myriadicity.net

Re: Reordering etc/NEWS

[Juanma Barranquero]

On 5/10/07, Ken Manheimer <ken.manheimer@gmail.com> wrote:

> how could you expect a productive conversation about that
> right now?

I'm an optimist.

             Juanma

Re: Reordering etc/NEWS

[Eli Zaretskii]

> Cc: storm@cua.dk (Kim F. Storm),  eliz@gnu.org,  emacs-devel@gnu.org
> From: Karl Fogel <kfogel@red-bean.com>
> Date: Thu, 10 May 2007 08:53:08 -0700
> 
> Basically, I proposed always having an open trunk (or some place
> where new changes can be checked in).  We'd use branches:
> 
>    a) To isolate release lines from trunk churn.
>    b) To isolate trunk from large, unstable batches of new code until
>       that code is ready.

Remember my message a day or two ago where I explained that Emacs
development needs experts in many different areas to be part of the
core team (those who can approve or reject patches)?  You agreed with
that, I think.

If we don't have enough experts, how can we make sure the release
branch remains stable?  Someone needs to review patches suggested for
that branch and make sure they are safe.  A single volunteer is not
very good in splitting her attention between two potentially very
different code bases, so many areas will need two people.  And on top
of that, volunteers generally like new development much more than
maintenance-like activity one finds on release branches.

That's the problem in always having an open trunk in Emacs: you need
roughly twice as many experts to handle a stable release branch and
the trunk at the same time.  Right now, we don't even have a single
full team, let alone two.

The MAINTAINERS file was born out of the last similar discussion we
had; it was supposed to become a starting point for bringing people on
board who would volunteer to become our experts for specific areas.
You can take a look at it: since its introduction in November 2001, it
got exactly 4 non-trivial changes, and an alarming amount of core
files and packages still have no responsible expert associated with
them.  Given this situation, it's IMO a miracle we are able to release
a stable version at all.

If you ask me, I won't even consider going to the scheme you suggest
until the list of files in MAINTAINERS for which there's no
responsible individual is significantly reduced.

> I've seen it work very well on other projects.

Please name the largest project where it works very well, and let's
compare its size and the number of disjoint areas of expertise it
requires to those of Emacs.

Re: Reordering etc/NEWS

[Juanma Barranquero]

On 5/11/07, Eli Zaretskii <eliz@gnu.org> wrote:

> The MAINTAINERS file was born out of the last similar discussion we
> had; it was supposed to become a starting point for bringing people on
> board who would volunteer to become our experts for specific areas.
> You can take a look at it: since its introduction in November 2001, it
> got exactly 4 non-trivial changes, and an alarming amount of core
> files and packages still have no responsible expert associated with
> them.

Although what you say it's true, it's also true that many elisp
packages, for example, have maintainers (which varying degrees of
"officialness") whose commitment is not explicitly stated in
MAINTAINERS: ada-mode, desktop, kmacro, ido, bookmark, eshell,
customize, vc, tramp, ibuffer, ps-*, gnus, etc. Moreover, many
packages are simple, or very infrequently updated, and do not need a
maintainer per se (not that it would be bad they had it, of course :)

So MAINTAINERS is not a good indicator of the status of support.

             Juanma

Re: Reordering etc/NEWS

[Eli Zaretskii]

> Date: Fri, 11 May 2007 13:23:20 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On 5/11/07, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The MAINTAINERS file was born out of the last similar discussion we
> > had; it was supposed to become a starting point for bringing people on
> > board who would volunteer to become our experts for specific areas.
> > You can take a look at it: since its introduction in November 2001, it
> > got exactly 4 non-trivial changes, and an alarming amount of core
> > files and packages still have no responsible expert associated with
> > them.
> 
> Although what you say it's true, it's also true that many elisp
> packages, for example, have maintainers (which varying degrees of
> "officialness") whose commitment is not explicitly stated in
> MAINTAINERS

MAINTAINERS lists only core Emacs parts.  Those are the parts where an
unsafe change can cause serious breakage.  I think there was an intent
to add more files and packages to the list if most of those in the
current one would get their responsible individuals, but since nothing
happened, it died out.

> So MAINTAINERS is not a good indicator of the status of support.

It is a good indicator of support in the core areas.

Re: Reordering etc/NEWS

[Juanma Barranquero]

On 5/11/07, Eli Zaretskii <eliz@gnu.org> wrote:

> It is a good indicator of support in the core areas.

I'd say it is a good indicator of *committed* support. While it's true
that there aren't many core areas of Emacs with a clearly determined
maintainer, most of them are not neglected either.

image.c, for example, which I would consider a core area, was not even
listed on MAINTAINERS. However, Kim Storm and others have invested a
considerable amount of time on it. The MacOS port is assigned (so to
speak) to Steven Tamm, but Yamamoto Mitsuharu has done huge amounts of
work. Etc, etc.

             Juanma

Re: Reordering etc/NEWS

[Eli Zaretskii]

> Date: Fri, 11 May 2007 18:09:07 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> image.c, for example, which I would consider a core area, was not even
> listed on MAINTAINERS. However, Kim Storm and others have invested a
> considerable amount of time on it.

Kim was here when MAINTAINERS was created, so having him with us now
does not show any increase in the number of core maintainers.

> The MacOS port is assigned (so to speak) to Steven Tamm, but
> Yamamoto Mitsuharu has done huge amounts of work. Etc, etc.

Working on a file does not necessarily mean one knows it well enough
to assume responsibility.  Until people write their names near the
files that they are willing to take responsibility for, we cannot be
sure.

Re: Reordering etc/NEWS

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
> Remember my message a day or two ago where I explained that Emacs
> development needs experts in many different areas to be part of the
> core team (those who can approve or reject patches)?  You agreed with
> that, I think.
>
> If we don't have enough experts, how can we make sure the release
> branch remains stable?  Someone needs to review patches suggested for
> that branch and make sure they are safe.  A single volunteer is not
> very good in splitting her attention between two potentially very
> different code bases, so many areas will need two people.  And on top
> of that, volunteers generally like new development much more than
> maintenance-like activity one finds on release branches.
>
> That's the problem in always having an open trunk in Emacs: you need
> roughly twice as many experts to handle a stable release branch and
> the trunk at the same time.  Right now, we don't even have a single
> full team, let alone two.

Those who are blocked from checking in new changes on trunk do not
always then volunteer for release stabilization/maintenance work.

I don't, for example, except in the packages that I maintain -- and
that's work I would do anyway, regardless of whether I'm checking in
new trunk code as well.  (Don't most package maintainers behave this
way, maintaining the things for which they've accepted responsibility
regardless of what other work they're doing?)

Zero-sum assumptions don't hold here.

> If you ask me, I won't even consider going to the scheme you suggest
> until the list of files in MAINTAINERS for which there's no
> responsible individual is significantly reduced.

Well, I think this is overestimating both the amount and the style of
control one can really have with a group of volunteers...

>> I've seen it work very well on other projects.
>
> Please name the largest project where it works very well, and let's
> compare its size and the number of disjoint areas of expertise it
> requires to those of Emacs.

The largest I know of off the top of my head is Subversion, which is
smaller than Emacs but also has very disjoint areas of expertise.
(I'm not sure the dimensions of comparison you're proposing here are
valid anyway, though; even if they were, my earlier point about how
volunteers actually allocate their time still holds.)

I think it may be moot now.  Richard seems to have declared trunk
open again.

-Karl

Re: Reordering etc/NEWS

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Karl Fogel <kfogel@red-bean.com>
> Date: Fri, 11 May 2007 10:49:17 -0700
> 
> > That's the problem in always having an open trunk in Emacs: you need
> > roughly twice as many experts to handle a stable release branch and
> > the trunk at the same time.  Right now, we don't even have a single
> > full team, let alone two.
> 
> Those who are blocked from checking in new changes on trunk do not
> always then volunteer for release stabilization/maintenance work.

Who is ``blocked from checking in new changes on trunk''?  Once
someone is approved for write access to CVS, that person can commit
changes anywhere.

> I don't, for example, except in the packages that I maintain -- and
> that's work I would do anyway, regardless of whether I'm checking in
> new trunk code as well.  (Don't most package maintainers behave this
> way, maintaining the things for which they've accepted responsibility
> regardless of what other work they're doing?)

I don't see how this is relevant.

> Zero-sum assumptions don't hold here.

Sorry, I don't understand what you mean here.

> > If you ask me, I won't even consider going to the scheme you suggest
> > until the list of files in MAINTAINERS for which there's no
> > responsible individual is significantly reduced.
> 
> Well, I think this is overestimating both the amount and the style of
> control one can really have with a group of volunteers...

It has nothing to do with control.  What we need (IMO) is to have, for
each expertise area, a person to whom we could turn for a definitive
opinion when a change is suggested.

> >> I've seen it work very well on other projects.
> >
> > Please name the largest project where it works very well, and let's
> > compare its size and the number of disjoint areas of expertise it
> > requires to those of Emacs.
> 
> The largest I know of off the top of my head is Subversion, which is
> smaller than Emacs but also has very disjoint areas of expertise.
> (I'm not sure the dimensions of comparison you're proposing here are
> valid anyway, though; even if they were, my earlier point about how
> volunteers actually allocate their time still holds.)

Without comparing, we have no real measures to judge this.

And time allocation by volunteers is not relevant to what I meant.  No
matter what someone chooses to work on this week, his expertise is
available to us when we want to ask his opinion about a change.

> I think it may be moot now.  Richard seems to have declared trunk
> open again.

I thought you were raising a more general issue of how to maintain
Emacs.  If this was only about opening the trunk, then I don't see any
significant problem here, as the trunk is open 99.99% of the time.

Re: Reordering etc/NEWS

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
> Who is ``blocked from checking in new changes on trunk''?  Once
> someone is approved for write access to CVS, that person can commit
> changes anywhere.

I've frequently been told not to check something in on trunk, because
the release is imminent.  Others have been complaining about that too,
if I'm not misunderstanding recent posts...

Re: Reordering etc/NEWS

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Karl Fogel <kfogel@red-bean.com>
> Date: Fri, 11 May 2007 11:37:13 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Who is ``blocked from checking in new changes on trunk''?  Once
> > someone is approved for write access to CVS, that person can commit
> > changes anywhere.
> 
> I've frequently been told not to check something in on trunk, because
> the release is imminent.

Yes, as long as the release branch is not cut, some risky changes are
postponed.  If we want to change that, IMO we need more maintainers
for the core parts, and we need some of them to work exclusively on
the branch.

Re: Reordering etc/NEWS

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> From: Karl Fogel <kfogel@red-bean.com>
>> Date: Fri, 11 May 2007 11:37:13 -0700
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > Who is ``blocked from checking in new changes on trunk''?  Once
>> > someone is approved for write access to CVS, that person can commit
>> > changes anywhere.
>> 
>> I've frequently been told not to check something in on trunk, because
>> the release is imminent.
>
> Yes, as long as the release branch is not cut,

The release branch _has_ been cut for Emacs 22.

> some risky changes are postponed.  If we want to change that, IMO we
> need more maintainers for the core parts, and we need some of them
> to work exclusively on the branch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Eli Zaretskii]

> Cc: Karl Fogel <kfogel@red-bean.com>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Sat, 12 May 2007 09:59:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Cc: emacs-devel@gnu.org
> >> From: Karl Fogel <kfogel@red-bean.com>
> >> Date: Fri, 11 May 2007 11:37:13 -0700
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> > Who is ``blocked from checking in new changes on trunk''?  Once
> >> > someone is approved for write access to CVS, that person can commit
> >> > changes anywhere.
> >> 
> >> I've frequently been told not to check something in on trunk, because
> >> the release is imminent.
> >
> > Yes, as long as the release branch is not cut,
> 
> The release branch _has_ been cut for Emacs 22.

Surely, I know this; how about reading prior messages before jumping
the gun?  We were talking about development models in general, not
about Emacs 22.1.

Re: Reordering etc/NEWS

[Richard Stallman]

We already have a problem of getting people to work on fixing two
serious bugs (which make Emacs not work at all in certain
circumstances).

Re: Reordering etc/NEWS

[Richard Stallman]

    I think my recent posts have met this criterion.  Basically, I
    proposed always having an open trunk (or some place where new changes
    can be checked in).

I agree, more or less, and this is what we have generally done,
with occasional short exceptions.

Re: Reordering etc/NEWS

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>     I think my recent posts have met this criterion.  Basically, I
>     proposed always having an open trunk (or some place where new changes
>     can be checked in).
>
> I agree, more or less, and this is what we have generally done,
> with occasional short exceptions.

Great, thanks.  I haven't done a quantitative analysis of how often
the exceptions happen, so it may be that I just coincidentally ran
into them a lot.  (It was often enough that I never realized, until
now, that the above was the standard policy.)

Now that trunk open, I'll look at my outstanding changes.

Re: Reordering etc/NEWS

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Whether you then feel offended or badgered by my concerns and
>     the ways I have expressed them (I admit to have been
>     exaggerating at times due to my growing frustration) is your
>     choice.
>
> I do not remember who said what, so I am not speaking about anyone
> in particular, just about what was said overall.
>
> Badgering is not a question of motive.  It means pressuring through
> repeated harsh demands.  That is precisely what was being done here
> to me.  Whatever the motive may have been, I don't want to be
> treated that way.

One problem is that the "demands" seem harsh mostly because you are
literally too busy to cater for them (as far as I can tell, most of
those demands do not ask for action on your behalf but rather for the
setting of policies.  Of course, those are something not well done in
haste and under pressure either).  A similar thing holds for their
perceived repetitiveness.  Since the amount of time and likely also
concentration you can spend catering for the Emacs project has become
more spotty and limited, it is a good thing that you are looking for a
successor in its maintenance.

In the meantime, people are trying to get an idea how to continue
work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Richard Stallman]

    One problem is that the "demands" seem harsh mostly because you are
    literally too busy to cater for them (as far as I can tell, most of
    those demands do not ask for action on your behalf but rather for the
    setting of policies.

Sometimes that is true.  But when people mechanically hammer away with
"TRT is nothing" whenever I say "please DTRT", without even checking
what a fix would entail, that is badgering (and useless).

Re: Reordering etc/NEWS

[Richard Stallman]

    We know that.  But, while waiting for this issue to be resolved,
    there's no need to install changes that do not fix very grave bugs.

That is what I think, and that is why the only nontrivial changes I
have installed were to fix grave bugs.  Furthemore, I take offense at
the insult which is implied by saying this to me as if you thought I
needed to be taught this by you.

I have been insulted and abused many times here lately.  I did not
respond to most of these insults, but I did take offense.

Re: Reordering etc/NEWS

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: rgm@gnu.org, emacs-devel@gnu.org
> Date: Mon, 07 May 2007 12:50:26 -0400
> 
>     We know that.  But, while waiting for this issue to be resolved,
>     there's no need to install changes that do not fix very grave bugs.
> 
> That is what I think, and that is why the only nontrivial changes I
> have installed were to fix grave bugs.

It should be clear by now that we have very different ideas about what
is a grave bug.  Perhaps if you took a few minutes to explain your
criteria, much of the argument could be avoided.

> Furthemore, I take offense at the insult which is implied by saying
> this to me as if you thought I needed to be taught this by you.

There was no insult and therefore no reason to take offense.  It's
just a simple difference of judgment about what is a grave bug.

OTOH, you have no more right to teach me manners than I have to teach
you what is a sound release procedure.  While the latter is a
technical issue that is on-topic in this forum, the former is not
(unless I behave in an uncivilized manner, which I don't think is the
case).

> I have been insulted and abused many times here lately.  I did not
> respond to most of these insults, but I did take offense.

Same here.

Re: Reordering etc/NEWS

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> CC: rgm@gnu.org, emacs-devel@gnu.org
>> Date: Mon, 07 May 2007 12:50:26 -0400
>> 
>>     We know that.  But, while waiting for this issue to be
>>     resolved, there's no need to install changes that do not fix
>>     very grave bugs.
>> 
>> That is what I think, and that is why the only nontrivial changes I
>> have installed were to fix grave bugs.
>
> It should be clear by now that we have very different ideas about
> what is a grave bug.  Perhaps if you took a few minutes to explain
> your criteria, much of the argument could be avoided.

If you compare the above statements you'll find that Richard, in
contrast to you, refers to "nontrivial changes".  So the difference
might not just lie with judging what are grave bugs, but also with
judging what are "trivial changes" and whether it is a good idea to do
them shortly before a release.

>> Furthemore, I take offense at the insult which is implied by saying
>> this to me as if you thought I needed to be taught this by you.
>
> There was no insult and therefore no reason to take offense.  It's
> just a simple difference of judgment about what is a grave bug.
>
> OTOH, you have no more right to teach me manners than I have to
> teach you what is a sound release procedure.  While the latter is a
> technical issue that is on-topic in this forum, the former is not
> (unless I behave in an uncivilized manner, which I don't think is
> the case).

To be fair here: Richard does not teach manners here, but rather tells
us how he reacts to the kind of criticism encountered on the list.
Since his reaction is not indifferent, it is perfectly relevant to the
release and his willingness to answer any question about the release
process and the SCM versioning, and is thus on-topic.

That I don't like it one bit (and suspect I am not alone in that) does
not change its relevance.

>> I have been insulted and abused many times here lately.  I did not
>> respond to most of these insults, but I did take offense.
>
> Same here.

Lots of people have invested lots of time and energy into a common
goal and made it progress.  So the prevailing sentiment on this list
should be gratitude and respect towards one another.

It is getting difficult to remember this.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Reordering etc/NEWS

[Alan Mackenzie]

On Sun, May 06, 2007 at 01:57:11PM -0400, Richard Stallman wrote
[in reply to Glenn Morris]:
>     Please, what now is your plan for making a release? April 23rd was
>     the original date that everyone seemed to consider reasonable. That
>     is now nearly two weeks ago.

> After 5 years, waiting two weeks is not a big deal.  Please don't make
> a mountain out of a molehill on the peak of a mountain.

I'm feeling frustrated and uptight too, not so much because of a
fortnight's delay, more from the uncertainty.  Is our release date going
to be this week, or this month?  The waiting is making me very tense.

I realise that Richard, Chong, and others responsible for deciding will
be feeling this unease much more keenly, and I think I speak for us all
in saying that we very much appreciate you bearing this burden.  Thanks!

Could we release this week?

-- 
Alan Mackenzie (Ittersbach, Germany).

Re: Reordering etc/NEWS

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Could we release this week?

The answer to this question has tentatively been "yes" for so long
that there does not seem much to be gained from asking it.

-- 
David Kastrup

Re: Reordering etc/NEWS

[Jay Belanger]

David Kastrup <dak@gnu.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>> Could we release this week?
>
> The answer to this question has tentatively been "yes" for so long
> that there does not seem much to be gained from asking it.

Perhaps that question should go in the FAQ, then.

Jay

Re: Reordering etc/NEWS

[David Kastrup]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Alan Mackenzie <acm@muc.de> writes:
>>
>>> Could we release this week?
>>
>> The answer to this question has tentatively been "yes" for so long
>> that there does not seem much to be gained from asking it.
>
> Perhaps that question should go in the FAQ, then.

The FAQ view is for users, not for developers.  So the question would
have to be something like

Q: Could a release of Emacs happen this week?

-- 
David Kastrup

Re: Reordering etc/NEWS

[Thomas Hühn]

David Kastrup <dak@gnu.org> writes:

> The FAQ view is for users, not for developers.  So the question would
> have to be something like
>
> Q: Could a release of Emacs happen this week?

A: Probably not, we are afraid of the haste that other software
projects, especially Debian, are showing.

Thomas ;-)

Re: Reordering etc/NEWS

[David Kastrup]

Thomas Hühn <newsgroups@thomas-huehn.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> The FAQ view is for users, not for developers.  So the question would
>> have to be something like
>>
>> Q: Could a release of Emacs happen this week?
>
> A: Probably not, we are afraid of the haste that other software
> projects, especially Debian, are showing.

A: Don't hurd your prospects by asking.

-- 
David Kastrup

Re: Reordering etc/NEWS

[Chong Yidong]

> I realise that Richard, Chong, and others responsible for deciding will
> be feeling this unease much more keenly, and I think I speak for us all
> in saying that we very much appreciate you bearing this burden.  Thanks!

I have nothing to do with "deciding".  I, too, would personally prefer
to make a release since it's now clear that further tinkering is
destabilizing the branch instead of stabilizing it.  But this is
entirely Richard's responsibility.

Re: Reordering etc/NEWS

[Richard Stallman]

      I, too, would personally prefer
    to make a release since it's now clear that further tinkering is
    destabilizing the branch instead of stabilizing it.

On the contrary, it is clear things work better now, and are more
stable now, than they were two weeks ago.

Re: Reordering etc/NEWS

[Richard Stallman]

    I'm feeling frustrated and uptight too, not so much because of a
    fortnight's delay, more from the uncertainty.  Is our release date going
    to be this week, or this month?  The waiting is making me very tense.

I can't tell you when it will be, because it doesn't make sense
to decide in advance.

However, you can relax.  The sort of bugs that people are finding in
CC mode now don't need to be fixed for this release.