Post-22.1 development?

Post-22.1 development?

[Chong Yidong]

Now Emacs 22.1 is released (for those who don't read info-gnu-emacs,
see http://permalink.gmane.org/gmane.emacs.announce/11 ), what is the
development plan for the trunk and the branch?

My understanding is that the EMACS_22_BASE branch will be used to make
future 22.x releases.  Should I bump the version on this branch to
22.1.50?  Should we begin merging the fixes that have been checked
into the trunk over last couple of months into the trunk, and if so,
What is the criterion for choosing patches to merge?

In a recent email, Stefan suggested that we should not restrict 22.x
development to bugfixes, but also include new features if the new
features are not too invasive.  Do people agree with this approach?
If so, I think a reasonable procedure we can follow is to (i) go ahead
and start merging *bugfixes* from the trunk into the branch, and (ii)
make a request to emacs-devel for each new *feature* from the trunk
that we want to add to the branch.

As for the trunk, should we begin merging the unicode branch in?  I
don't think this would interfere much with the process of merging the
trunk patches into the EMACS_22_BASE branch, since that's just a
matter of looking up ChangeLog entries and browing CVS diffs.  Also,
is it "open season" on checkins to the trunk, or do we want to
complete the unicode merge first?

Release announcement [was Re: Post-22.1 development?]

[Glenn Morris]

Chong Yidong wrote:

> Now Emacs 22.1 is released (for those who don't read info-gnu-emacs,
> see http://permalink.gmane.org/gmane.emacs.announce/11 ),

I think the announcement should be X-posted to help-gnu-emacs. Whilst
it's good to have a separate announce mailing list, it gets so little
traffic I think most people will have forgotten it exists. And I'm
sure the readers of help-gnu-emacs will forgive one extra mail with
such good news.

Re: Release announcement [was Re: Post-22.1 development?]

[Kim F. Storm]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
>
>> Now Emacs 22.1 is released (for those who don't read info-gnu-emacs,
>> see http://permalink.gmane.org/gmane.emacs.announce/11 ),
>
> I think the announcement should be X-posted to help-gnu-emacs.

It would also be a nice gesture to announce it to the pre-testers
and thank them for their help...

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

Re: Release announcement [was Re: Post-22.1 development?]

[Richard Stallman]

    It would also be a nice gesture to announce it to the pre-testers
    and thank them for their help...

Good idea -- I just did that.

Re: Release announcement [was Re: Post-22.1 development?]

[Yavor Doganov]

В Mon, 04 Jun 2007 02:59:16 -0400, Glenn Morris написа:

> I think the announcement should be X-posted to help-gnu-emacs.

Or even info-gnu (fsf.announce).  This is a major milestone in the
the development of the GNU system that is certainly going to be celebrated
all over the Free World.

Congrats for the rock-solid release.  It took long, but it's all worth it.

Re: Post-22.1 development?

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> My understanding is that the EMACS_22_BASE branch will be used to make
> future 22.x releases.  Should I bump the version on this branch to
> 22.1.50?

Yes, please do.

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: Post-22.1 development?

[Ulrich Mueller]

>>>>> On Mon, 04 Jun 2007, Andreas Schwab wrote:

> Chong Yidong <cyd@stupidchicken.com> writes:
>> My understanding is that the EMACS_22_BASE branch will be used to
>> make  future 22.x releases.  Should I bump the version on this
>> branch to 22.1.50?

> Yes, please do.

The trunk currently has version 22.1.50, too. Shouldn't this be
changed then (but to what? 22.2.50, 23.0.50?), to minimise confusion?

Ulrich

Re: Post-22.1 development?

[Andreas Schwab]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Mon, 04 Jun 2007, Andreas Schwab wrote:
>
>> Chong Yidong <cyd@stupidchicken.com> writes:
>>> My understanding is that the EMACS_22_BASE branch will be used to
>>> make  future 22.x releases.  Should I bump the version on this
>>> branch to 22.1.50?
>
>> Yes, please do.
>
> The trunk currently has version 22.1.50, too.

Good point.

> Shouldn't this be changed then (but to what? 22.2.50, 23.0.50?), to
> minimise confusion?

IMHO we should merge the unicode branch ASAP and move the trunk to
version 23.0.50.

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: Post-22.1 development?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Mon, 04 Jun 2007 11:24:33 +0200
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
> > The trunk currently has version 22.1.50, too.
> 
> Good point.
> 
> > Shouldn't this be changed then (but to what? 22.2.50, 23.0.50?), to
> > minimise confusion?
> 
> IMHO we should merge the unicode branch ASAP and move the trunk to
> version 23.0.50.

I think we should bump the trunk version to 23.0.50 right now.  We
already decided not to release any 22.x versions from the trunk.

Re: Post-22.1 development?

[David Kastrup]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Mon, 04 Jun 2007, Andreas Schwab wrote:
>
>> Chong Yidong <cyd@stupidchicken.com> writes:
>>> My understanding is that the EMACS_22_BASE branch will be used to
>>> make  future 22.x releases.  Should I bump the version on this
>>> branch to 22.1.50?
>
>> Yes, please do.
>
> The trunk currently has version 22.1.50, too. Shouldn't this be
> changed then (but to what? 22.2.50, 23.0.50?), to minimise confusion?

Merge unicode-2 and move to 23.0.52 (23.0.50 appears to be unicode-2
unmerged IIRC, 23.0.51 appears to be multi-tty branch).  At the
moment, there appears little point in bumbing the last number unless
we have an architectural change/branch merge.

-- 
David Kastrup

Re: Post-22.1 development?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 04 Jun 2007 11:25:30 +0200
> Cc: Andreas Schwab <schwab@suse.de>, Chong Yidong <cyd@stupidchicken.com>,
> 	emacs-devel@gnu.org
> 
> Merge unicode-2 and move to 23.0.52 (23.0.50 appears to be unicode-2
> unmerged IIRC, 23.0.51 appears to be multi-tty branch).

There's no need to bump the .50 version number beyond 50: version
numbers are insignificant until a pretest begins.  All we need is show
that the CVS version is more advanced than any 22.x version we might
release from the branch.

Re: Post-22.1 development?

[Richard Stallman]

    The trunk currently has version 22.1.50, too. Shouldn't this be
    changed then (but to what? 22.2.50, 23.0.50?), to minimise confusion?

I think a good number for the trunk is 22.50.

Re: Post-22.1 development?

[Richard Stallman]

    My understanding is that the EMACS_22_BASE branch will be used to make
    future 22.x releases.  Should I bump the version on this branch to
    22.1.50?

Yes, please do so.

    In a recent email, Stefan suggested that we should not restrict 22.x
    development to bugfixes, but also include new features if the new
    features are not too invasive.  Do people agree with this approach?

We can put in a limited set of new features, but only if they
are really important as well as safe.

    As for the trunk, should we begin merging the unicode branch in?

Let's wait a couple of months.  I think it will be easier to move some
changes selectively to the Emacs 22 branch if we have not included
unicode-2 in the trunk.  As of now, any change in the trunk would work
in the branch.  After unicode-2 is installed, many changes will be
done differently, and they won't work unchanged in the Emacs 22 branch.

RE: Post-22.1 development?

[Drew Adams]

>     In a recent email, Stefan suggested that we should not restrict 22.x
>     development to bugfixes, but also include new features if the new
>     features are not too invasive.  Do people agree with this approach?
>
> We can put in a limited set of new features, but only if they
> are really important as well as safe.
>
>     As for the trunk, should we begin merging the unicode branch in?
>
> Let's wait a couple of months.  I think it will be easier to move some
> changes selectively to the Emacs 22 branch if we have not included
> unicode-2 in the trunk.  As of now, any change in the trunk would work
> in the branch.  After unicode-2 is installed, many changes will be
> done differently, and they won't work unchanged in the Emacs 22 branch.

IIUC, this means that any new features to be added to Emacs, beyond those
deemed "really important as well as safe", will be added to Emacs +
unicode-2. And that will be after "a couple of months" (which really
means...?) plus the time it takes to merge the unicode-2 branch and test it
after merging.

This means that any libraries or other features we might want to add (beyond
those "really important") will need to work with unicode-2 Emacs. I know
already that some of my own code, which works perfectly well with Emacs 22,
will not work as is with unicode-2 Emacs. For example, my code for zooming
frames (default font) breaks.

Unicode will, I suspect, change a lot of things, making it more difficult to
integrate some new features. However, I do understand that there would also
be problems the other way around: if we first integrated, before unicode-2,
various libraries that people have not mentioned during the last few
"feature-freeze" years, then integrating unicode-2 would itself be harder.

I guess that's the way it is, but I thought I'd point this out. I agree that
it is probably better to try to make new features work with unicode-2 than
the other way around. Better to hold up some minor improvements than a major
improvement.

It really is a shame that the release cycle is so long. Because of the
"feature freeze", I (and I assume others too) have been waiting for years,
literally, to bring up some possible features for consideration. Emacs is
definitely a cathedral to which generations of builders contribute
collectively. Perhaps a distant descendent will finally merge a "new"
feature conceived centuries earlier... ;-) A historical viewpoint and a
sense of humor definitely help temper impatience. The good news is that a
long waiting line means that Emacs development is active - the doctor is
just busy with other patients, not on vacation.

Re: Post-22.1 development?

[Richard Stallman]

    This means that any libraries or other features we might want to add (beyond
    those "really important") will need to work with unicode-2 Emacs. I know
    already that some of my own code, which works perfectly well with Emacs 22,
    will not work as is with unicode-2 Emacs. For example, my code for zooming
    frames (default font) breaks.

We are going to merge unicode-2 pretty soon.  Within a few months.
Any other feature that we add will have to be adapted, one way or
another, to work with unicode-2, by that time.

If a feature has conflicts with unicode-2, it makes little sense to
rush to install it in the trunk.  That would just add to the size of
the job of merging the unicode-2 branch.  It is much better to adapt
the other feature _now_ to work with unicode-2, and install it after
that.  That way, the work can be done in parallel.

You could start doing this now.

Meanwhile, if a new feature won't make the unicode-2 merge harder,
then we can install it now into the trunk.

new Emacs maintainer(s)? (was: Re: Post-22.1 development?)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     As for the trunk, should we begin merging the unicode branch in?
  > 
  > Let's wait a couple of months.  I think it will be easier to move some
  > changes selectively to the Emacs 22 branch if we have not included
  > unicode-2 in the trunk.  As of now, any change in the trunk would work
  > in the branch.  After unicode-2 is installed, many changes will be
  > done differently, and they won't work unchanged in the Emacs 22 branch.

Do you still plan to turn over Emacs maintenance to someone else? 
Have you made a decision on who is going to be the new Emacs
maintainer(s)?

If that is still the plan, maybe is better to ask the future
maintainers to formulate the development plan to better suit their
development strategy. 

Re: new Emacs maintainer(s)?

[David Kastrup]

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

> Richard Stallman <rms@gnu.org> writes:
>
>   >     As for the trunk, should we begin merging the unicode branch in?
>   > 
>   > Let's wait a couple of months.  I think it will be easier to
>   > move some changes selectively to the Emacs 22 branch if we have
>   > not included unicode-2 in the trunk.  As of now, any change in
>   > the trunk would work in the branch.  After unicode-2 is
>   > installed, many changes will be done differently, and they won't
>   > work unchanged in the Emacs 22 branch.
>
> Do you still plan to turn over Emacs maintenance to someone else? 
> Have you made a decision on who is going to be the new Emacs
> maintainer(s)?
>
> If that is still the plan, maybe is better to ask the future
> maintainers to formulate the development plan to better suit their
> development strategy. 

If candidates can be found, it might be an idea to have different
maintainers for the Emacs 22 and the Emacs 23 series since there are
somewhat conflicting focuses and interests.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: new Emacs maintainer(s)?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 04 Jun 2007 21:34:45 +0200
> Cc: Chong Yidong <cyd@stupidchicken.com>, rms@gnu.org, emacs-devel@gnu.org
> 
> If candidates can be found, it might be an idea to have different
> maintainers for the Emacs 22 and the Emacs 23 series since there are
> somewhat conflicting focuses and interests.

You are presumably so optimistic as to think we can find more than one
maintainer...

Re: new Emacs maintainer(s)?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 04 Jun 2007 21:34:45 +0200
>> Cc: Chong Yidong <cyd@stupidchicken.com>, rms@gnu.org, emacs-devel@gnu.org
>> 
>> If candidates can be found, it might be an idea to have different
>> maintainers for the Emacs 22 and the Emacs 23 series since there are
>> somewhat conflicting focuses and interests.
>
> You are presumably so optimistic as to think we can find more than one
> maintainer...

Look up "If" in a dictionary of your choice.  Anyway, even if we can't
afford more than one manager, we could look for someone with multiple
personalities in order to fit both the Emacs 22 and Emacs 23
requirements.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: new Emacs maintainer(s)?

[Lennart Borgman (gmail)]

David Kastrup wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: David Kastrup <dak@gnu.org>
>>> Date: Mon, 04 Jun 2007 21:34:45 +0200
>>> Cc: Chong Yidong <cyd@stupidchicken.com>, rms@gnu.org, emacs-devel@gnu.org
>>>
>>> If candidates can be found, it might be an idea to have different
>>> maintainers for the Emacs 22 and the Emacs 23 series since there are
>>> somewhat conflicting focuses and interests.
>> You are presumably so optimistic as to think we can find more than one
>> maintainer...
> 
> Look up "If" in a dictionary of your choice.  Anyway, even if we can't
> afford more than one manager, we could look for someone with multiple
> personalities in order to fit both the Emacs 22 and Emacs 23
> requirements.

It should not be any difficulty. Emacs has so many different sides so 
you really have to have some kind of split personality to master all 
sides of it.

Re: new Emacs maintainer(s)? (was: Re: Post-22.1 development?)

[Richard Stallman]

    Do you still plan to turn over Emacs maintenance to someone else? 

I would still like to do so.

    Have you made a decision on who is going to be the new Emacs
    maintainer(s)?

I have not made a plan.

Re: new Emacs maintainer(s)? (was: Re: Post-22.1 development?)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Do you still plan to turn over Emacs maintenance to someone else? 
  > 
  > I would still like to do so.

What can the Emacs development community can do so that this happens
sooner rather than later? 
I am asserting that your time is extremely valuable, it is better
spent working on FSF/Free Software in general (and technical issues in
Emacs rather than management issues).

  >     Have you made a decision on who is going to be the new Emacs
  >     maintainer(s)?
  > 
  > I have not made a plan.

Here a modest proposal to advance in that direction: name Chong Yidong
as the 22.x maintainer (assuming he wants the job), his work on
pushing 21.1 out was outstanding. 

Re: new Emacs maintainer(s)?

[David Kastrup]

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

> Richard Stallman <rms@gnu.org> writes:
>
>   >     Do you still plan to turn over Emacs maintenance to someone else? 
>   > 
>   > I would still like to do so.
>
> What can the Emacs development community can do so that this happens
> sooner rather than later? 
> I am asserting that your time is extremely valuable, it is better
> spent working on FSF/Free Software in general (and technical issues in
> Emacs rather than management issues).
>
>   >     Have you made a decision on who is going to be the new Emacs
>   >     maintainer(s)?
>   > 
>   > I have not made a plan.
>
> Here a modest proposal to advance in that direction: name Chong Yidong
> as the 22.x maintainer (assuming he wants the job), his work on
> pushing 21.1 out was outstanding. 

++version.  While I agree that his work on 22.1 was outstanding, one
has to be aware that the main task of a maintainer is not writing
code, but rather setting (and following) policies, and organizing,
motivating and structuring the work of others.

-- 
David Kastrup

Re: new Emacs maintainer(s)?

[Karl Fogel]

Perhaps the answer to this has been mentioned elsewhere, but I haven't
seen it.

Is the Emacs maintainer position volunteer or paid?  Or does that
depend on who we get?

Re: new Emacs maintainer(s)?

[Chong Yidong]

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

>   >     Have you made a decision on who is going to be the new Emacs
>   >     maintainer(s)?
>   > 
>   > I have not made a plan.
>
> Here a modest proposal to advance in that direction: name Chong Yidong
> as the 22.x maintainer (assuming he wants the job), his work on
> pushing [22.1] out was outstanding. 

Thank you for the compliment, though of course many others also worked
hard to get the release out the door.

The primary objection to choosing me is that there are several Emacs
hackers on this list who have been contributing to Emacs for much
longer, and have a deeper understanding of the system as a whole.
However, if no one else wants to maintainer, I would not mind doing
it; I think I shall have enough spare time to devote to this, at least
during the next three or four years.

Re: new Emacs maintainer(s)?

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> However, if no one else wants to maintainer, I would not mind doing
> it; I think I shall have enough spare time to devote to this, at least
> during the next three or four years.

Is that for 22.x only, or 23.1 ?

In any case, you have my full support!

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

Re: new Emacs maintainer(s)?

[David Kastrup]

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

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> However, if no one else wants to maintainer, I would not mind doing
>> it; I think I shall have enough spare time to devote to this, at least
>> during the next three or four years.
>
> Is that for 22.x only, or 23.1 ?
>
> In any case, you have my full support!

I am not sure whether it is a good idea to discuss this sort of
personals question on the list: after all, the decision rests with
Richard, so we don't want to get hopes up only to have disappointment
afterwards.

On the other hand, of course I can't resist mouthing off about
something like that, either...

Here would be my scheme for an ideal setup:

22.x principal maintainer: Chong.  Reason: we want to invest minimal
man- and mindpower into 22.x and rather move forward.  Chong has a
history with 22.x across the board for and with pulling through with
technical decisions (even though he did not make most of them on his
own) even on code with which he has not had a long acquaintance.  He
keeps reasonably on top of things, so he is a pretty good candidate
for merging appropriate fixes from the trunk.  If 22.x were in the
hands of Chong, I would have little qualms about moving the trunk to
emacs-unicode2 pretty much right away (well, I wouldn't, anyway, but
in this case I would be rather confident about the consequences).  The
downside would be mostly for Chong himself: it is to be expected that
people indeed will leave 22.x mostly in his hands.  However, if the
decisions to make are mostly in his hands, too, it is likely that
he'll be able to work more efficiently than when he is "on a leash".
And if he can dispense with the 22.x work efficiently and in his own
manner, it might not even take the bulk of his energy and time.

23.x principal maintainer: more difficult.  We want to have a
maintainer that makes working on Emacs fun while still keeping the
"party line" of the GNU Project.  Maybe splitting this into a
technical lead and a policy supervisor would make sense.  Could be an
option to leave the latter somewhat ungrateful job to Richard.  For
the technical lead, at least for part of the way, we want someone who
has familiarity with emacs-unicode-2 though it need not be his primary
focus.  We also want to get to the release at some point of time.  I
guess that my personal favorite here would actually be Kim, mostly
because he has pretty much managed to keep out of the release spats in
spite of his experience and seems well enough in contact with much
code, including the display engine.  Which could help for gathering
the impetus for Emacs 24 (the one with bidirectional language support
for which there is considerable demand by users that are pretty much
out in the cold for now).

Now of course this kind of setup will depend on the people actually
being willing and able to step up to that kind of responsibility.

Of course, there is a list of candidates who certainly would have
enough authority and competence to pull through with the requirements.
That was just my first thought on the "wouldn't it be nice if" scale.

-- 
David Kastrup

Re: new Emacs maintainer(s)?

[Juanma Barranquero]

On 6/6/07, David Kastrup <dak@gnu.org> wrote:

> I am not sure whether it is a good idea to discuss this sort of
> personals question on the list:

I was wondering the same thing.

> Here would be my scheme for an ideal setup:
>
> 22.x principal maintainer: Chong.
> [...]
> 23.x principal maintainer: more difficult.  [...] I
> guess that my personal favorite here would actually be Kim,

I pretty much agree 100%.

> Now of course this kind of setup will depend on the people actually
> being willing and able to step up to that kind of responsibility.

Yes. There are a few worthy candidates; not that many willing, though.

             Juanma

Re: new Emacs maintainer(s)?

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

My ideal setup would be:

Emacs 22.x (maintenance): Richard (who can still pull on anyone to
actually merge/adapt desired fixes from the trunk to the 22.x branch).

Emacs 23.1: A committee of Handa [technical lead], Chong [release manager], 
and a third person (e.g. Stefan).

Emacs 23.x (maintenance): One of the above (or somebody else ?)

Emacs 24.1: A committee of Eli [technical lead], ? [release manager],
and a third person (perferably someone with interest in BIDI).


I thing that once unicode and multi-tty are merged to the trunk, the
bidi work for 24.1 can gain quite some momentum, so it would be good
to form the 24.1 committee quite soon!

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

Re: new Emacs maintainer(s)?

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
> My ideal setup would be:
>
> Emacs 22.x (maintenance): Richard (who can still pull on anyone to
> actually merge/adapt desired fixes from the trunk to the 22.x
> branch).

Funny: that would be pretty much my worst case scenario since Richard
is primarily a manager of people (his intermittent access does not
make much more possible, anyway), and pulling on anyone is going to
detract "anyone" from ongoing work on the trunk.  The admirable
ability to unceremoniously come through with the technical changes
once the direction is clear, is what made me propose Chong: he made
quite a lot of progress even in a zigzag course dictated by changing
opinions and policies.  If he is going to set the policies himself, he
will save himself a few dead ends.

> Emacs 23.1: A committee of Handa [technical lead], Chong [release
> manager], and a third person (e.g. Stefan).

Well, Handa is already the technical lead of unicode-2 and somewhat
biased.  It is clear anyway that he'll be needed to iron out quite a
number of pains in connection with unicode-2, and I would not find it
amiss if there was a somewhat less "partial" person involved with
judging the severity of changes in the API to the general developer
public.  Chong does not make the impression to me of being scared of
complexity.  But I am, and I would like somebody who is conservative
(though not in a destructive way) to counterbalance the unicode-2
leadership.

> Emacs 23.x (maintenance): One of the above (or somebody else ?)

Probably too early to think about that.

> Emacs 24.1: A committee of Eli [technical lead], ? [release
> manager], and a third person (perferably someone with interest in
> BIDI).

What I wrote above for Emacs 23.1 with regard to Handa would apply for
24.1 and Eli similarly.  While it is clear that those are
indispensable for the work in question, I'd prefer having a
counterweight in the project leadership.  This would also make it
possible for them to argue their case without having to be impartial
about it: it would be the job of the respective version leader to
weigh their needs against those of others.

-- 
David Kastrup

Re: new Emacs maintainer(s)?

[Thien-Thi Nguyen]

() David Kastrup <dak@gnu.org>
() Wed, 06 Jun 2007 12:54:35 +0200

   > Emacs 23.x (maintenance): One of the above (or somebody else ?)

   Probably too early to think about that.

i disagree.  if pre-/post-release leadership is incompatible, that's
no good.  wide separation leads to problems even in other releases.

IMHO, whoever handles release x.1 should also maintain x.2+.

thi

Re: new Emacs maintainer(s)?

[David Kastrup]

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

> () David Kastrup <dak@gnu.org>
> () Wed, 06 Jun 2007 12:54:35 +0200
>
>    > Emacs 23.x (maintenance): One of the above (or somebody else ?)
>
>    Probably too early to think about that.
>
> i disagree.  if pre-/post-release leadership is incompatible, that's
> no good.  wide separation leads to problems even in other releases.
>
> IMHO, whoever handles release x.1 should also maintain x.2+.

I disagree.  x.1 is mostly done in the trunk, x.2+ mostly in a
stabilized branch.  It is my opinion that this requires different
skillsets for most of the time.

-- 
David Kastrup

Re: new Emacs maintainer(s)?

[Thien-Thi Nguyen]

() David Kastrup <dak@gnu.org>
() Wed, 06 Jun 2007 14:06:18 +0200

   I disagree.  x.1 is mostly done in the trunk, x.2+ mostly in a
   stabilized branch.  It is my opinion that this requires different
   skillsets for most of the time.

a release coalesces around some vision for that release, not on a
skillset.  it is precisely because there are different skillsets
required that whoever does x.1 should do x.2+, for three reasons:

 - cohesion of vision for the x.* releases
 - self-improvement in the "maintenance" skillset for x.1 folks
 - self-improvement in the ".1 release" skillset for (x+1).1 folks

what often happens when skillset is taken as the arbiter is that the
x.2+ folks lose the original vision of the x.1 folks, through mis- or
non-communication more than anything, and widen the maintenance duties
to "fix design bugs".  then you get into "how dare that Mere QA Dude
change My code" and other class{ic,ist} organizational problems.

i'd say "that way lies madness" but for the stupifying regularity (and
hence evident normalcy) of such an approach's consequence.

anyway, that's all i have to say on the matter.
heinlein sez: "specialization is for insects."

thi

Re: new Emacs maintainer(s)?

[David Kastrup]

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

> () David Kastrup <dak@gnu.org>
> () Wed, 06 Jun 2007 14:06:18 +0200
>
>    I disagree.  x.1 is mostly done in the trunk, x.2+ mostly in a
>    stabilized branch.  It is my opinion that this requires different
>    skillsets for most of the time.
>
> a release coalesces around some vision for that release, not on a
> skillset.  it is precisely because there are different skillsets
> required that whoever does x.1 should do x.2+, for three reasons:
>
>  - cohesion of vision for the x.* releases
>  - self-improvement in the "maintenance" skillset for x.1 folks
>  - self-improvement in the ".1 release" skillset for (x+1).1 folks

I disagree, again.  Moving towards a vision and polishing it are
different goals in my book.  But since I already made my argument,
there is little point in repeating it and we will obviously remain in
disagreement.  Whatever the theory, Richard will have to make the
pick, and whomever he chooses for what task will be human and not a
robot designed according to one of our specifications.

I have little doubt that both of us will find the final choice
appropriate.

[...]

> anyway, that's all i have to say on the matter.

Same here.

-- 
David Kastrup

Re: new Emacs maintainer(s)?

[Kenichi Handa]

In article <868xaxjqtw.fsf@lola.quinscape.zz>, David Kastrup <dak@gnu.org> writes:

> What I wrote above for Emacs 23.1 with regard to Handa would apply for
> 24.1 and Eli similarly.  While it is clear that those are
> indispensable for the work in question, I'd prefer having a
> counterweight in the project leadership.  This would also make it
> possible for them to argue their case without having to be impartial
> about it: it would be the job of the respective version leader to
> weigh their needs against those of others.

I agree.  In addition, as I have many Unicode related works
not yet finished for Emacs 23, and discussions in English
take lot of time for me, I would very much appreciate if
someone else takes the leadership of the whole project.

---
Kenichi Handa
handa@m17n.org

Re: new Emacs maintainer(s)?

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> I agree.  In addition, as I have many Unicode related works
> not yet finished for Emacs 23, and discussions in English
> take lot of time for me, I would very much appreciate if
> someone else takes the leadership of the whole project.

That is why I suggested that we have a committee of 3 people for
each release:

- a "technical lead" which is responsible for the "quality" of the
  major modifications to the software (i.e. C and Lisp code).

- a "release manager" which is responsible for the release, including
  documentation, copyright stuff, packaging, etc  (basically anything
  else)

- a "chairman" (the third person) who has the "final word" on any
  disputes in the committee, based on an overall understanding of
  Emacs "policies, history and visions" (whatever they are)...
  

I still think Handa, Chong and Stefan would be a great team for 23.1

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

Re: new Emacs maintainer(s)?

[Chong Yidong]

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

>> I agree.  In addition, as I have many Unicode related works
>> not yet finished for Emacs 23, and discussions in English
>> take lot of time for me, I would very much appreciate if
>> someone else takes the leadership of the whole project.
>
> That is why I suggested that we have a committee of 3 people for
> each release:
>
> - a "technical lead" which is responsible for the "quality" of the
>   major modifications to the software (i.e. C and Lisp code).
>
> - a "release manager" which is responsible for the release, including
>   documentation, copyright stuff, packaging, etc  (basically anything
>   else)
>
> - a "chairman" (the third person) who has the "final word" on any
>   disputes in the committee, based on an overall understanding of
>   Emacs "policies, history and visions" (whatever they are)...

Similar structures have apparently worked well for many free software
projects.  So I think it's a very good idea, though the decision of
whether or not to go down this route is Richard's to make.

Re: new Emacs maintainer(s)?

[Stefan Monnier]

> Thank you for the compliment, though of course many others also worked
> hard to get the release out the door.

Sure, but you did a good job of staying on-course in the middle of
lots of complaints and anger flying around.

> The primary objection to choosing me is that there are several Emacs
> hackers on this list who have been contributing to Emacs for much
> longer, and have a deeper understanding of the system as a whole.
> However, if no one else wants to maintainer, I would not mind doing
> it; I think I shall have enough spare time to devote to this, at least
> during the next three or four years.

For what it's worth, I've already mentioned to Richard that I'm interested
in taking over maintainership, and am also willing to share it with others.


        Stefan

Re: new Emacs maintainer(s)?

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> For what it's worth, I've already mentioned to Richard that I'm interested
> in taking over maintainership, and am also willing to share it with others.

I think Stefan would make a good maintainer.

Kim's idea of splitting the task into "technical / release / chair"
roles, and his suggestion of Handa, Chong, and Stefan for those roles
also seems reasonable.

[Kenichi seems concerned about the time overhead, but I'm guessing that
in practice he could concentrate on those areas related to the unicode
transition and font machinery, and Stefan could handle other areas.]

-miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: new Emacs maintainer(s)?

[Kenichi Handa]

In article <buoira0xr9z.fsf@dhapc248.dev.necel.com>, Miles Bader <miles.bader@necel.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > For what it's worth, I've already mentioned to Richard that I'm interested
> > in taking over maintainership, and am also willing to share it with others.

> I think Stefan would make a good maintainer.

> Kim's idea of splitting the task into "technical / release / chair"
> roles, and his suggestion of Handa, Chong, and Stefan for those roles
> also seems reasonable.

> [Kenichi seems concerned about the time overhead, but I'm guessing that
> in practice he could concentrate on those areas related to the unicode
> transition and font machinery, and Stefan could handle other areas.]

If Stefan (or someone else) take on a job as a general
techinical leader, I'm willing to help him as a sub-leader
in the Unicode and font area.  I'm sorry for saying this,
but I do lack time for working on the other area.

---
Kenichi Handa
handa@m17n.org

Re: Post-22.1 development?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     In a recent email, Stefan suggested that we should not restrict 22.x
>     development to bugfixes, but also include new features if the new
>     features are not too invasive.  Do people agree with this approach?
>
> We can put in a limited set of new features, but only if they
> are really important as well as safe.
>
>     As for the trunk, should we begin merging the unicode branch in?
>
> Let's wait a couple of months.  I think it will be easier to move
> some changes selectively to the Emacs 22 branch if we have not
> included unicode-2 in the trunk.  As of now, any change in the trunk
> would work in the branch.  After unicode-2 is installed, many
> changes will be done differently, and they won't work unchanged in
> the Emacs 22 branch.

I don't think this is a good plan, and here is why:

EMACS_22_BASE is for work on Emacs 22.2
trunk is for work on Emacs 22.2
unicode-2 is for work on Emacs 23.1

This is clearly one branch too many (and I am not counting multi-tty
yet).  Since you yourself say that only important and safe changes
should get into 22.2, I don't see the point in maintaining three
branches.

In particular, I don't see the point in keeping trunk stalled to
mechanisms that won't work with Emacs 23.1.  There have been a number
of band-aid fixes to functions that were supposed to be replaced by
proper code once the unicode-2 mechanisms are in use.  There is no
point in spending energy on stuff that is neither going to end up in
Emacs 22.2 (since it is not important and safe enough), nor in Emacs
23.1 (since it fails to use the unicode-2 mechanisms).

Please let us not waste time and energy on code that has no proper
place in any future release.

As long as no Emacs 23.1 mechanisms are involved, synching a
unicode-2-empowered trunk's changes (if we want to) to EMACS_22_BASE
will be easy.  And where Emacs 23.1 mechanisms are involved, we don't
actually want to figure out a parallel Emacs 22 mechanism, anyway.
Not if it is not absolutely necessary.

Merging unicode-2 to the trunk now rather than in a few months will
help to keep the focus on the ongoing work for Emacs 23.1.

We have stalled development for years in order to get a stable release
out.  We have put out a release, and created a branch for safe and
important fixes to it.  This is the time for the trunk to move on to
Emacs 23.1.  For Emacs 22.2, we have EMACS_22_BASE.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Post-22.1 development?

[Jason Rumney]

David Kastrup wrote:
>> Let's wait a couple of months.
>>     
>
> I don't think this is a good plan, and here is why:
>
> EMACS_22_BASE is for work on Emacs 22.2
> trunk is for work on Emacs 22.2
> unicode-2 is for work on Emacs 23.1
>   

I agree that 2 months is too long to wait. We should merge any changes
from the trunk that were intended for Emacs 22.2 ASAP, then any future
changes targeted for 22.2 should be made in the EMACS_22_BASE branch and
merged to the trunk, not the other way around.

Re: Post-22.1 development?

[Richard Stallman]

    I agree that 2 months is too long to wait. We should merge any changes
    from the trunk that were intended for Emacs 22.2 ASAP, then any future
    changes targeted for 22.2 should be made in the EMACS_22_BASE branch and
    merged to the trunk, not the other way around.

This is a good plan, but I am not convinced that it is enough reason
to rush to merge unicode-2 into the trunk.

Re: Post-22.1 development?

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>>> Let's wait a couple of months.
>>>     
>>
>> I don't think this is a good plan, and here is why:
>>
>> EMACS_22_BASE is for work on Emacs 22.2
>> trunk is for work on Emacs 22.2
>> unicode-2 is for work on Emacs 23.1
>>   
>
> I agree that 2 months is too long to wait. We should merge any changes
> from the trunk that were intended for Emacs 22.2 ASAP, then any future
> changes targeted for 22.2 should be made in the EMACS_22_BASE branch and
> merged to the trunk, not the other way around.

I've gone ahead and merged several straightforward bugfixes from the
trunk into the branch.  I also drew up a list of the remaining
differences between the trunk and branch.  Could people chime in about
whether these should make their way into the branch?

1. Two new files:

   2007-06-04  Michael Albinus  net/socks.el
   2007-05-31  Stefan Monnier   textmodes/css-mode.el


2. Several package updates and enhancements:

   2007-05-28  Michael Albinus  Tramp 2.0.56.

   2007-06-03  Nick Roberts     [Terminal mouse enhancements]
   ....                        xt-mouse.el, t-mouse.el, keyboard.c, ...

   2007-05-21  Chong Yidong     [image uncaching code]
                                image.c, image-mode.el

   2007-05-24  Chong Yidong     image-mode.el [scrolling in image-mode]

   2007-05-22  Jan Djärv        Use find-source-lisp-file in help-fns.el

   2007-05-17  Vinicius Jose Latorre  Printing 6.9

3. An incompatible package behavior change:

   2007-06-01  David Kastrup

   * dired.el (dired-recursive-deletes, dired-recursive-copies):
     Change default to `top'.

4. Several other fixes whose safety is not known to me:

   2007-06-03  Sam Steingold  <sds@gnu.org>

     Add TIMESTAMP to LOC to handle "incremental compilation", e.g.,
     with `omake -P': the compilation process never terminates and
     automatically recompiles modified files.

     * progmodes/compile.el (compilation-loop): VISITED is not 5th CDR.
     (compilation-next-error-function): Set TIMESTAMP.

   2007-06-03  Sam Steingold  <sds@gnu.org>

     * files.el (kill-buffer-ask): New function.
     (kill-some-buffers): Use it.
     (kill-matching-buffers): New user command.


   2007-05-23  Eli Zaretskii  <eliz@gnu.org>

     * tar-mode.el (tar-header-block-summarize, tar-summarize-buffer)
     (tar-get-descriptor): Handle type 55, an extended pax header.

   2007-05-22  Martin Rudalics  <rudalics@gmx.at>

     * syntax.c (scan_words): Fix arg to UPDATE_SYNTAX_TABLE_BACKWARD.

   2007-04-29  Andreas Schwab  <schwab@suse.de>

     * lisp.h (VECSIZE): Use OFFSETOF.

   2007-04-28  Richard Stallman  <rms@gnu.org>

     * lread.c (read_escape): In a string, \s is always space.

5. And a big pile of changes by Stefan Monnier.  [Stefan, can you
   handle the merge for these by yourself?]

     keymap.c emacs-lisp/derived.el emacs-lisp/copyright.el edmacro.el
     ediff-init.el cus-dep.el composite.el autoinsert.el
     textmodes/sgml-mode.el textmodes/tex-mode.el diff-mode.el
     emacs-lisp/advice.el newcomment.el textmodes/sgml-mode.el vc.el
     progmodes/python.el diff.el

Re: Post-22.1 development?

[Nick Roberts]

 > I've gone ahead and merged several straightforward bugfixes from the
 > trunk into the branch.  I also drew up a list of the remaining
 > differences between the trunk and branch.  Could people chime in about
 > whether these should make their way into the branch?

 >..
 >    2007-06-03  Nick Roberts     [Terminal mouse enhancements]
 >    ....                        xt-mouse.el, t-mouse.el, keyboard.c, ...

The change to xt-mouse.el is insignificant but I'd prefer the other changes
(use of Gpm for console based mouse functionality) are not merged yet.  I think
generally it's a good change, and I don't really want to shoot my own changes
down, but here are a few reasons:

1) The menubar doesn't currently work

2) The function set-mouse-position doesn't work.  I think that in DOS, the
   kernel has a notion of where the mouse pointer is but that that isn't the
   case in Linux.  The pointer position seems to be stored in Gpm and AFAICS
   the API doesn't allow you to change it.

Also I would like to see the following:

1) DOS-like menubar functionality (as already discussed)

2) Functionality extended to work on an xterm.  I notice that midnight
   commander and aptitude can do this, although the latter doesn't appear to
   be linked with Gpm.

So it's kind of a work in progress.  If anyone feels that they can help with
it, please do.


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

Re: Post-22.1 development?

[Richard Stallman]

    1. Two new files:

       2007-06-04  Michael Albinus  net/socks.el
       2007-05-31  Stefan Monnier   textmodes/css-mode.el

It would be ok to include those two, since it is safe,
and url wants socks.

    2. Several package updates and enhancements:

       2007-05-28  Michael Albinus  Tramp 2.0.56.

I don't know what the change was, but Tramp is hairy,
so I would rather not put that into 22.2.

       2007-06-03  Nick Roberts     [Terminal mouse enhancements]
       ....                        xt-mouse.el, t-mouse.el, keyboard.c, ...

Definitely not.  That is hairy.

       2007-05-21  Chong Yidong     [image uncaching code]
				    image.c, image-mode.el

I don't recall what that was.

       2007-05-24  Chong Yidong     image-mode.el [scrolling in image-mode]

What do you think?

       2007-05-22  Jan Djärv        Use find-source-lisp-file in help-fns.el

I think we can do without that.

       2007-05-17  Vinicius Jose Latorre  Printing 6.9

What was the change?

       2007-06-01  David Kastrup

       * dired.el (dired-recursive-deletes, dired-recursive-copies):
	 Change default to `top'.

I think we should put that in.

       2007-06-03  Sam Steingold  <sds@gnu.org>

	 Add TIMESTAMP to LOC to handle "incremental compilation", e.g.,
	 with `omake -P': the compilation process never terminates and
	 automatically recompiles modified files.

	 * progmodes/compile.el (compilation-loop): VISITED is not 5th CDR.
	 (compilation-next-error-function): Set TIMESTAMP.

Not that.

       2007-06-03  Sam Steingold  <sds@gnu.org>

	 * files.el (kill-buffer-ask): New function.
	 (kill-some-buffers): Use it.
	 (kill-matching-buffers): New user command.

Not that.

       2007-05-23  Eli Zaretskii  <eliz@gnu.org>

	 * tar-mode.el (tar-header-block-summarize, tar-summarize-buffer)
	 (tar-get-descriptor): Handle type 55, an extended pax header.

We should install that, so because it is a matter of completeness
in handling files you may encounter.

       2007-05-22  Martin Rudalics  <rudalics@gmx.at>

	 * syntax.c (scan_words): Fix arg to UPDATE_SYNTAX_TABLE_BACKWARD.

That bug fix yes.

       2007-04-29  Andreas Schwab  <schwab@suse.de>

	 * lisp.h (VECSIZE): Use OFFSETOF.

I think that is a cleanup, right?  No need to put it in 22.2.

       2007-04-28  Richard Stallman  <rms@gnu.org>

	 * lread.c (read_escape): In a string, \s is always space.

That is not crucial.  So don't put it in 22.2.

    5. And a big pile of changes by Stefan Monnier.  [Stefan, can you
       handle the merge for these by yourself?]

	 keymap.c emacs-lisp/derived.el emacs-lisp/copyright.el edmacro.el
	 ediff-init.el cus-dep.el composite.el autoinsert.el
	 textmodes/sgml-mode.el textmodes/tex-mode.el diff-mode.el
	 emacs-lisp/advice.el newcomment.el textmodes/sgml-mode.el vc.el
	 progmodes/python.el diff.el

I would rather that Stefan give us a list of the specific ones of these
that he proposes for 22.2, and for each one, why.

Re: Post-22.1 development?

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     2. Several package updates and enhancements:
>
>        2007-05-28  Michael Albinus  Tramp 2.0.56.
>
> I don't know what the change was, but Tramp is hairy,
> so I would rather not put that into 22.2.

The major difference is removal of cl.el. So it might be desirable to
merge it into the branch. admin/FOR-RELEASE says

** viper and tramp should not load cl at run time.

By the way, could you (or somebody else) be a little bit more verbose
about Tramp being "hairy"? What would you like to be changed? Maybe it
is a good time to fix such things in Tramp 2.1 / in the trunk.

Best regards, Michael.

Re: Post-22.1 development?

[Johan Bockgård]

Michael Albinus <michael.albinus@gmx.de> writes:

> The major difference is removal of cl.el. So it might be desirable to
> merge it into the branch. admin/FOR-RELEASE says
>
> ** viper and tramp should not load cl at run time.

The change was unnecessarily drastic.

     However, there is no problem with using the `cl' package at
     compile time, with `(eval-when-compile (require 'cl))'.  That's
     sufficient for using the macros in the `cl' package, because the
     compiler expands them before generating the byte-code.

     -- (info "(elisp)Coding Conventions")

There were no problematic uses in tramp.el, AFAICT (after adding
`eval-when-compile').

-- 
Johan Bockgård

Re: Post-22.1 development?

[David Kastrup]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> The major difference is removal of cl.el. So it might be desirable to
>> merge it into the branch. admin/FOR-RELEASE says
>>
>> ** viper and tramp should not load cl at run time.
>
> The change was unnecessarily drastic.
>
>      However, there is no problem with using the `cl' package at
>      compile time, with `(eval-when-compile (require 'cl))'.  That's
>      sufficient for using the macros in the `cl' package, because the
>      compiler expands them before generating the byte-code.
>
>      -- (info "(elisp)Coding Conventions")
>
> There were no problematic uses in tramp.el, AFAICT (after adding
> `eval-when-compile').

There were so many cases of a warning buffer popping up in many
versions of tramp that it seems pointless to keep cl in it unless it
is really hard to replace: getting this completely right just seems to
be fragile.  After a few dozen failed attempts, "we _can_ do this
right" appears like asking for trouble.

-- 
David Kastrup

Re: Post-22.1 development?

[Michael Albinus]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> The change was unnecessarily drastic.
>
>      However, there is no problem with using the `cl' package at
>      compile time, with `(eval-when-compile (require 'cl))'.  That's
>      sufficient for using the macros in the `cl' package, because the
>      compiler expands them before generating the byte-code.
>
>      -- (info "(elisp)Coding Conventions")

But this would mean that one cannot use such a package if it is NOT
byte compiled. Maybe not the recommended behaviour, but personally I
don't compile Tramp because I perform tests with different (X)Emacs
flavors.

And I don't know whether it is preferrable to urge users for
compilation. They might use the same package on a mounted directory,
on different hosts, which is the case for me @ work.

Best regards, Michael.

Re: Post-22.1 development?

[Andreas Schwab]

Michael Albinus <michael.albinus@gmx.de> writes:

> bojohan+news@dd.chalmers.se (Johan Bockgård) writes:
>
>> The change was unnecessarily drastic.
>>
>>      However, there is no problem with using the `cl' package at
>>      compile time, with `(eval-when-compile (require 'cl))'.  That's
>>      sufficient for using the macros in the `cl' package, because the
>>      compiler expands them before generating the byte-code.
>>
>>      -- (info "(elisp)Coding Conventions")
>
> But this would mean that one cannot use such a package if it is NOT
> byte compiled.

Why?  The require is still evaluated when interpreted.

eval-when-compile is a Lisp macro in `byte-run.el'.
(eval-when-compile &rest BODY)

Like `progn', but evaluates the body at compile time if you're compiling.
Thus, the result of the body appears to the compiler as a quoted constant.
In interpreted code, this is entirely equivalent to `progn'.

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: Post-22.1 development?

[Michael Albinus]

Andreas Schwab <schwab@suse.de> writes:

> Why?  The require is still evaluated when interpreted.
>
> eval-when-compile is a Lisp macro in `byte-run.el'.
> (eval-when-compile &rest BODY)
>
> Like `progn', but evaluates the body at compile time if you're compiling.
> Thus, the result of the body appears to the compiler as a quoted constant.
> In interpreted code, this is entirely equivalent to `progn'.

Hmm, I should have read the doc first. Sorry for the noise.

> Andreas.

Best regards, Michael.

Re: Post-22.1 development?

[Stefan Monnier]

> But this would mean that one cannot use such a package if it is NOT
> byte compiled.

Huh?  We're talking *coding* convention, not *usage* convention.


        Stefan

Re: Post-22.1 development?

[David House]

On 07/06/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Huh?  We're talking *coding* convention, not *usage* convention.

I think Michael was confused and thought that (eval-when-compile
(require 'cl)) would _only_ load the cl library when you were
compiling.

-- 
-David House, dmhouse@gmail.com

Re: Post-22.1 development?

[Richard Stallman]

    By the way, could you (or somebody else) be a little bit more verbose
    about Tramp being "hairy"? What would you like to be changed?

"Hairy" is not a criticism.  It just means Tramp is complex, and has
complex interactions.  Therefore, changes in it could easily break
something.

However, from what you've said, it sounds like THIS upgrade to Tramp
should go into 22.2.  Would you please install it in EMACS_22_BASE?

Re: Post-22.1 development?

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> However, from what you've said, it sounds like THIS upgrade to Tramp
> should go into 22.2.  Would you please install it in EMACS_22_BASE?

done.

Best regards, Michael.

Re: Post-22.1 development?

[Vinicius Jose Latorre]

Richard Stallman wrote:
>        2007-05-17  Vinicius Jose Latorre  Printing 6.9
>
> What was the change?

Group together all XEmacs/Emacs definitions.

Re: Post-22.1 development?

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     As for the trunk, should we begin merging the unicode branch in?
  > 
  > Let's wait a couple of months.  I think it will be easier to move some
  > changes selectively to the Emacs 22 branch if we have not included
  > unicode-2 in the trunk.  As of now, any change in the trunk would work
  > in the branch.  After unicode-2 is installed, many changes will be
  > done differently, and they won't work unchanged in the Emacs 22 branch.

How about merging the multi-tty branch? The changes on that branch are
much more localized, so porting fixes from the trunk to the EMACS_22
branch should not be a big issue. 

Re: Post-22.1 development?

[Richard Stallman]

    How about merging the multi-tty branch? The changes on that branch are
    much more localized, so porting fixes from the trunk to the EMACS_22
    branch should not be a big issue. 

Does anyone see a problem with this idea?

Re: Post-22.1 development?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     How about merging the multi-tty branch? The changes on that branch are
>     much more localized, so porting fixes from the trunk to the EMACS_22
>     branch should not be a big issue. 
>
> Does anyone see a problem with this idea?

Well, the setenv/process-environment thing I wanted to have a look at:
in the current state, it will require quite a few changes in existing
packages (including packages not distributed as part of Emacs), and I
think that the approach which I sketched out would pretty much
eliminate that problem.

Merging multi-tty to the trunk now could mean that some people start
patching up other packages inside or outside of Emacs to work with the
current environment variable settings, while others will change the
mechanisms eventually.

My last weekends have been quite busy and I still have a bunch of
other stuff left in my leasure queue.  So I haven't gotten around to
actually write code in that area.

That's what I would consider sort of speaking against a merge right
now: it might cause unnecessary work (later likely to be reverted) at
other locations.  I will still try to wedge my own attempts of doing
this into my schedule, but I am not yet familiar with the branch code.

-- 
David Kastrup

Re: Post-22.1 development?

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> That's what I would consider sort of speaking against a merge right
> now: it might cause unnecessary work (later likely to be reverted) at
> other locations.

FWIW, I've been periodically merging the trunk into the multi-tty
branch, and there haven't been any notable conflicts, so perhaps there's
no rush.

-Miles

-- 
"Suppose He doesn't give a shit?  Suppose there is a God but He
just doesn't give a shit?"  [George Carlin]

Re: Post-22.1 development?

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Richard Stallman <rms@gnu.org> writes:
  > 
  > >     How about merging the multi-tty branch? The changes on that branch are
  > >     much more localized, so porting fixes from the trunk to the EMACS_22
  > >     branch should not be a big issue. 
  > >
  > > Does anyone see a problem with this idea?
  > 
  > Well, the setenv/process-environment thing I wanted to have a look at:
  > in the current state, it will require quite a few changes in existing
  > packages (including packages not distributed as part of Emacs), and I
  > think that the approach which I sketched out would pretty much
  > eliminate that problem.

Let me reiterate Karoly's (the multi-tty author) opinion on this,
which I also second as a contributor to that branch and as a (almost
exclusive) user for about 2 years: the environment variables thing is
a peripheral issue, and a rather obscure one.

Changing this requires about 50-100 lines of code (including comments)
and it can be done without major impact on the rest of the multi-tty
functionality (it has happened a few times on the multi-tty branch
already).

Karoly does not think there's a problem with the current
implementation (and I second that too), but he would have no objection
if David was to replace the current implementation.

  > Merging multi-tty to the trunk now could mean that some people start
  > patching up other packages inside or outside of Emacs to work with the
  > current environment variable settings, while others will change the
  > mechanisms eventually.

The changes in question for external packages probably amount to 1-2
lines of code. Plus I don't think we should be concerned about
external packages at this point. 

For the code in Emacs, if the implementation changes I volunteer to go
over and fix any issues. I guesstimate this to be less than 10 minutes
of work.

So in conclusion _my_ (quite informed) opinion is that this issue
should not stop a merge. 

Please let's move forward unless there are more serious issues that
need consideration.

Re: Post-22.1 development?

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>   > Richard Stallman <rms@gnu.org> writes:
>   > 
>   > >     How about merging the multi-tty branch? The changes on that branch are
>   > >     much more localized, so porting fixes from the trunk to the EMACS_22
>   > >     branch should not be a big issue. 
>   > >
>   > > Does anyone see a problem with this idea?
>   > 
>   > Well, the setenv/process-environment thing I wanted to have a look at:
>   > in the current state, it will require quite a few changes in existing
>   > packages (including packages not distributed as part of Emacs), and I
>   > think that the approach which I sketched out would pretty much
>   > eliminate that problem.
>
> Let me reiterate Karoly's (the multi-tty author) opinion on this,
> which I also second as a contributor to that branch and as a (almost
> exclusive) user for about 2 years: the environment variables thing
> is a peripheral issue, and a rather obscure one.

Dan, please either either _quote_ Karoly, or speak for yourself.  I
don't think that you do Karoly a favor by this sort of "reiteration".
Anyway, we don't want obscure stuff entered into Emacs.  We want to
have things work as closely to before (and to the expected way) as
possible.  There is exactly _zero_ documentation of the multi-tty
branch in either Emacs and Elisp manual as far as I can see.  And we
want to have the necessary documentation of the multi-tty
functionality (similar to multi-display documentation currently) to be
confined to a single chapter.

The current entanglement of frame-local variables, terminal-local
variables and environment variables, with complete semantics changes
in all of the accessor functions of the environment as well as the
data structures, is completely unfit for an isolated chapter since it
pervades too much other stuff.

If you feel differently, try creating Texinfo documentation for
multi-tty that supplements the existing documentation, without
touching too many existing chapters.

> Changing this requires about 50-100 lines of code (including
> comments) and it can be done without major impact on the rest of the
> multi-tty functionality (it has happened a few times on the
> multi-tty branch already).
>
> Karoly does not think there's a problem with the current
> implementation (and I second that too), but he would have no
> objection if David was to replace the current implementation.

Look, I quoted code both in Emacs itself as well as in external
packages that was affected.

>   > Merging multi-tty to the trunk now could mean that some people
>   > start patching up other packages inside or outside of Emacs to
>   > work with the current environment variable settings, while
>   > others will change the mechanisms eventually.
>
> The changes in question for external packages probably amount to 1-2
> lines of code. Plus I don't think we should be concerned about
> external packages at this point.

Most incompatible API changes don't amount to more than 1-2 lines of
code in external packages.  We still don't do them lightly.  In
particular, when they affect close to everything.

That is the state of affairs with "locales", "specifiers" and
"instantiators" in XEmacs.  They provide a technical framework for
displaying fonts, images, toolbars and other stuff on a variety of
terminals and devices.  They have provided multitty functionality on
XEmacs for probably a decade or more.  They have also made it pretty
much impossible for anybody except a guru to create code dealing with
images and similar stuff even on a single tty.

We don't want a similar exposure of multi-tty building blocks to the
programmer who is not interested in them.  And people dealing with
environment variables are more likely than not expecting to have
multi-tty functionality getting in their way.

> For the code in Emacs, if the implementation changes I volunteer to
> go over and fix any issues. I guesstimate this to be less than 10
> minutes of work.

But we don't want to have to change callers that are not logically
involved with multi-tty functionality.

> So in conclusion _my_ (quite informed) opinion is that this issue
> should not stop a merge.

I disagree.

> Please let's move forward unless there are more serious issues that
> need consideration.

Breaking code in unrelated areas lightly is something which I consider
serious.  You call for ignoring that opinion.

In that case I ask you to draft the necessary documentation in the
Elisp and Emacs manuals so that people get a better feel of the extent
of the effects.  If this is not serious, existing chapters should
hardly be affected, right?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Post-22.1 development?

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > David Kastrup <dak@gnu.org> writes:
  > >
  > >   > Richard Stallman <rms@gnu.org> writes:
  > >   > 
  > >   > >     How about merging the multi-tty branch? The changes on that branch are
  > >   > >     much more localized, so porting fixes from the trunk to the EMACS_22
  > >   > >     branch should not be a big issue. 
  > >   > >
  > >   > > Does anyone see a problem with this idea?
  > >   > 
  > >   > Well, the setenv/process-environment thing I wanted to have a look at:
  > >   > in the current state, it will require quite a few changes in existing
  > >   > packages (including packages not distributed as part of Emacs), and I
  > >   > think that the approach which I sketched out would pretty much
  > >   > eliminate that problem.
  > >
  > > Let me reiterate Karoly's (the multi-tty author) opinion on this,
  > > which I also second as a contributor to that branch and as a (almost
  > > exclusive) user for about 2 years: the environment variables thing
  > > is a peripheral issue, and a rather obscure one.
  > 
  > Dan, please either either _quote_ Karoly, or speak for yourself.  I
  > don't think that you do Karoly a favor by this sort of "reiteration".

I don't appreciate the snide remarks and your off the high horse
attitude, if you find any factual inaccuracies in my statement, please
point to them. 

The citation you asked for is below. I find my statements to be quite
accurate.

Now, for RMS' benefit: I am not sure what the point of your message
was, but you have not disproved in your message the main arguments of
my message: the environments issue is a side story for the multi-tty
branch, it can easily be changed with minimal side effects after the
merge IFF we find there is a problem with the current implementation.

The code on the multi-tty branch is surely not perfect, and more
issues might be discovered after it is merged, but it is functional
today. Getting it into the hands of more developers will only help
this process.

You seem to have very strong opinions about this environment stuff,
you are welcome to offer an alternative implementation that satisfies
all the constraints the current one does, but please stop blocking
progress because of that.


-- citing earlier messages from a different thread as requested -- 
     From: Karoly Lorentey <karoly@lorentey.hu>
     Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
     Newsgroups: gmane.emacs.devel
     To: David Kastrup <dak@gnu.org>
     Cc: Andreas Schwab <schwab@suse.de>, Dan Nicolaescu <dann@ics.uci.edu>, joakim@verona.se, emacs-devel@gnu.org
     Date: Fri, 18 May 2007 13:55:53 +0200
     
     David Kastrup wrote:
     >> (Emacs may have been running in the background for weeks, and I may
     >> have just started working on my brand new TeX file in a recently
     >> started emacsclient session.)  Both viewpoints should be catered
     >> for.
     > 
     > I disagree.  If a viewpoint can't be catered for without breaking a
     > _lot_ of things and guarantees, catering for it might be a bad idea.
     
     OK, I give up in disgust.  Do whatever you want.  I mean it: go ahead
     and implement whatever environment semantics you find most appropriate.
      I have presented all my best reasons why I think we should support
     local environments.  I have even proposed what I think was a reasonable
     compromise.  We simply can not reach a common ground if you keep
     discarding my entire viewpoint and use-cases.
     
     Clearly I won't convince you by repeating the same arguments over and
     over, and you will definitely not convince me either.  There is no point
     in arguing for the sake of arguing.  I throw in the towel, you win.
     Congratulations.
     
     Now that this area is finally taken care of, let us choose and discuss
     another part of multi-tty design instead.
     
     * * *
     
     I'm really not interested in arguing about environments any more, but
     since I have already written my response below, I'll post it for reference.
     
     > There is lots of Elisp code that does not even run in a frame: network
     > buffers, spell check buffers, background processes and the like.
     
     This code will also work fine for single-terminal users.  All existing
     code would work fine for single-terminal users.  Single-terminal users
     will not run into regressions.  We are backward compatible.
     
     I think you are vastly overemphasizing the importance of environment
     variables in general and "future compatibility" in particular.

     [snip, the rest of the message can be found in the archives]

     From: Karoly Lorentey <karoly@lorentey.hu>
     Subject: Re: Multi-tty design (Re: Reordering etc/NEWS)
     Newsgroups: gmane.emacs.devel
     To: David Kastrup <dak@gnu.org>
     Cc: Andreas Schwab <schwab@suse.de>, Dan Nicolaescu <dann@ics.uci.edu>, joakim@verona.se, emacs-devel@gnu.org
     Date: Fri, 18 May 2007 19:40:53 +0200
                                                                
     
     David Kastrup wrote:
     > Karoly Lorentey <karoly@lorentey.hu> writes:
     >>> We simply can not reach a common ground if you keep
     >> discarding my entire viewpoint and use-cases.
     >
     > I don't see that I do.  Presenting existing use-cases and problems
     > with them does not mean that I discard your views and approaches.
     > It
     > just means that I don't consider them optimal.
     
     I want to make it clear that I'm not angry at you, just tired of the
     argument.  I believe I have said everything I had to say on the topic
     of
     environment variables, and I simply don't think that continuing this
     conversation will help us advance towards a mutually satisfactory
     solution.  My position is already available in the archives.
     
     I'll let you implement any solution that is acceptable to you.  I
     promise I won't mind.  Meanwhile, we can move on to discuss some other
     topics.
     
     User feedback will help us decide what (if anything) needs to be
     changed
     later.  We are talking about some 50-100 lines of well-separated code,
     so it's not like it is going to be much work to experiment with
     alternative implementations.
     
     I'm sorry if it is unusual or impolite to just give up arguing like
     that.  It is now clear to me that you care much more about how
     environments behave than I do.

     [snip, the rest of the message can be found in the archives]

--- end citation --- 

  > Anyway, we don't want obscure stuff entered into Emacs.  We want to
  > have things work as closely to before (and to the expected way) as
  > possible.  

What is your point with this statement? Do you want to imply that I am
suggesting otherwise? If you are trying to have a discussion with me
such remarks are completely unproductive. You do similar things
several times in your message.

  > There is exactly _zero_ documentation of the multi-tty
  > branch in either Emacs and Elisp manual as far as I can see.  And we
  > want to have the necessary documentation of the multi-tty
  > functionality (similar to multi-display documentation currently) to be
  > confined to a single chapter.
  > 
  > The current entanglement of frame-local variables, terminal-local
  > variables and environment variables, with complete semantics changes
  > in all of the accessor functions of the environment as well as the
  > data structures, is completely unfit for an isolated chapter since it
  > pervades too much other stuff.
  > 
  > If you feel differently, try creating Texinfo documentation for
  > multi-tty that supplements the existing documentation, without
  > touching too many existing chapters.

RMS has not stated until now that having texinfo documentation is a
merge precondition. I don't remember this being a common practice in
emacs either. Quite the contrary, that is why there is a practice of
using +++ and --- in the NEWS file for stuff that is implemented and
still needs texinfo documentation.

  > > Changing this requires about 50-100 lines of code (including
  > > comments) and it can be done without major impact on the rest of the
  > > multi-tty functionality (it has happened a few times on the
  > > multi-tty branch already).
  > >
  > > Karoly does not think there's a problem with the current
  > > implementation (and I second that too), but he would have no
  > > objection if David was to replace the current implementation.
  > 
  > Look, I quoted code both in Emacs itself as well as in external
  > packages that was affected.

And I addressed that: "The changes in question for external packages
probably amount to 1-2 lines of code. Plus I don't think we should be
concerned about external packages at this point."

  > >   > Merging multi-tty to the trunk now could mean that some people
  > >   > start patching up other packages inside or outside of Emacs to
  > >   > work with the current environment variable settings, while
  > >   > others will change the mechanisms eventually.
  > >
  > > The changes in question for external packages probably amount to 1-2
  > > lines of code. Plus I don't think we should be concerned about
  > > external packages at this point.
  > 
  > Most incompatible API changes don't amount to more than 1-2 lines of
  > code in external packages.  We still don't do them lightly.  In
  > particular, when they affect close to everything.

This is an overly broad statement that you don't support with facts.
You have several of those below. They are not really related to my
original argument so I don't want to derail to discuss them.

Re: Post-22.1 development?

[Richard Stallman]

    Changing this requires about 50-100 lines of code (including comments)
    and it can be done without major impact on the rest of the multi-tty
    functionality (it has happened a few times on the multi-tty branch
    already).

These facts don't invalidate Kastrup's point.  What's important is the
way other programs should access the environment.  We have to get that
right, in multi-tty, before we merge multi-tty.

Re: Post-22.1 development?

[Richard Stallman]

    Well, the setenv/process-environment thing I wanted to have a look at:
    in the current state, it will require quite a few changes in existing
    packages (including packages not distributed as part of Emacs), and I
    think that the approach which I sketched out would pretty much
    eliminate that problem.

    That's what I would consider sort of speaking against a merge right
    now: it might cause unnecessary work (later likely to be reverted) at
    other locations.

That is a good reason for delaying this.

Could you state a precise proposal for how to handle the environment?
I looked at the old mail; one message seems to have mentioned various
options, and subsequent messages referred to "[your] proposal",
so I am not sure precisely what the proposal is.

Re: Post-22.1 development?

[Stefan Monnier]

>     Well, the setenv/process-environment thing I wanted to have a look at:
>     in the current state, it will require quite a few changes in existing
>     packages (including packages not distributed as part of Emacs), and I
>     think that the approach which I sketched out would pretty much
>     eliminate that problem.

>     That's what I would consider sort of speaking against a merge right
>     now: it might cause unnecessary work (later likely to be reverted) at
>     other locations.

> That is a good reason for delaying this.

I think the right way to do it is to change the multi-tty code's handling of
environment so that it preserves the old behavior (and probably breaks
some of the multi-tty support), then merge into the trunk, then try and fix
the multi-tty part of the breakage.


        Stefan

Re: Post-22.1 development?

[Jason Rumney]

Stefan Monnier wrote:
> I think the right way to do it is to change the multi-tty code's handling of
> environment so that it preserves the old behavior (and probably breaks
> some of the multi-tty support), then merge into the trunk, then try and fix
> the multi-tty part of the breakage.
>   

I'm not sure exactly what the current breakage is, and why it is a
problem, but there are a number of environment variables that have come
up in this discussion that there is general agreement that they should
be terminal local (DISPLAY, TERM). So it isn't a binary issue - whether
the environment should be terminal/frame local or not, we are going to
have to deal with the issues for these two variables anyway. Given that,
and the strong opinions of some that the environment should not be
terminal local, can we not have a user configurable option for this?

I'd suggest the following user option:

terminal-local-environment

   nil means the environment is not terminal local (what we have in
Emacs 22)
   t means all the environment is terminal local (what is implemented in
multi-tty currently)
   A cons cell is a list of environment variables that should be treated
as terminal local.

   default value can be '("DISPLAY" "TERM").

Re: Post-22.1 development?

[Stefan Monnier]

>> I think the right way to do it is to change the multi-tty code's handling of
>> environment so that it preserves the old behavior (and probably breaks
>> some of the multi-tty support), then merge into the trunk, then try and fix
>> the multi-tty part of the breakage.

> I'm not sure exactly what the current breakage is, and why it is a

The "breakage" is that process-environment needs to be sometimes replaced by
(environment).  This is partly unavoidable.  Since we will have several
environments, there will need a way for external package to explicitly
request one or the other.

> problem, but there are a number of environment variables that have come
> up in this discussion that there is general agreement that they should
> be terminal local (DISPLAY, TERM).

I don't think the disagreement is about which variables should be
terminal-local and which shouldn't.  Rather it's about what API to present
to external packages to manipulate the environment.  `process-environment'
plus `setenv' does not seem quite sufficient.


        Stefan

Re: Post-22.1 development?

[David Kastrup]

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

>>> I think the right way to do it is to change the multi-tty code's handling of
>>> environment so that it preserves the old behavior (and probably breaks
>>> some of the multi-tty support), then merge into the trunk, then try and fix
>>> the multi-tty part of the breakage.
>
>> I'm not sure exactly what the current breakage is, and why it is a
>
> The "breakage" is that process-environment needs to be sometimes replaced by
> (environment).  This is partly unavoidable.  Since we will have several
> environments, there will need a way for external package to explicitly
> request one or the other.
>
>> problem, but there are a number of environment variables that have come
>> up in this discussion that there is general agreement that they should
>> be terminal local (DISPLAY, TERM).
>
> I don't think the disagreement is about which variables should be
> terminal-local and which shouldn't.  Rather it's about what API to present
> to external packages to manipulate the environment.  `process-environment'
> plus `setenv' does not seem quite sufficient.

The proposal was to have process-environment a terminal-local
variable.  It is set up starting with its own values of DISPLAY and
TERM.  Each last terminal-local cons-cell has a cdr of
global-process-environment.  This is a "shared tail" starting with the
empty string "" (which is an environment element satisfying stringp,
but not matching any useful string pattern).  setenv will use setcar
to replace an existing environment variable definition it finds in
process-environment, and will append non-existing definitions at the
end of process-environment.

This implementation will share all environment variables between
terminals except for the terminal-local ones.  It will keep basically
all the idiosyncratic ways of manipulating the global environment (or
a copy-sequence of it for local manipulations) operative.

And it will make it easy, for those who want to do this, to actually
have no shared environment at all.  Since it will not break existing
ways of accessing the environment, it is a good starting point for
experimenting with both shared as well as disparate environments.

If at one point of time a definite choice for one or the other is
made, a somewhat less tricky API might be developed, and in due time,
this proposal of mine might be faded out (take a few major versions).
It is not a thing of beauty, but it is rather flexible and
backwards-compatible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Post-22.1 development?

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

> The proposal was to have process-environment a terminal-local
> variable.  It is set up starting with its own values of DISPLAY and
> TERM.  Each last terminal-local cons-cell has a cdr of
> global-process-environment.  This is a "shared tail" starting with the
> empty string "" (which is an environment element satisfying stringp,
> but not matching any useful string pattern).  setenv will use setcar
> to replace an existing environment variable definition it finds in
> process-environment, and will append non-existing definitions at the
> end of process-environment.

I think it's a bad idea to use a shared tail in this way.  I can't
think of anywhere else in Emacs where this kind of convoluted setup is
used, and it seems to go against the way similar problems are solved
elsewhere in Emacs.

There are two clean ways to do this is: (i) extend process-environment
so that if a symbol occurs in the list, as opposed to a string, that
symbol names a list whose elements are to be used (as though they had
been inserted in process-environment).  Then the final element for all
default values of process-environment would include the symbol
`global-process-environment'; or (ii) extend process-environment so
that an element of `t' means "the global value of this variable"
(similar to hook variables).

Either of these approaches would be backward compatible for
third-party than the shared-tail idea, but IMHO the gain in
cleanliness more than makes up for it.

Re: Post-22.1 development?

[Richard Stallman]

    There are two clean ways to do this is: (i) extend process-environment
    so that if a symbol occurs in the list, as opposed to a string, that
    symbol names a list whose elements are to be used (as though they had
    been inserted in process-environment).  Then the final element for all
    default values of process-environment would include the symbol
    `global-process-environment'; or (ii) extend process-environment so
    that an element of `t' means "the global value of this variable"
    (similar to hook variables).

These are more elegant, but I am not sure it matters in practice.

    Either of these approaches would be backward compatible for
    third-party than the shared-tail idea, but IMHO the gain in
    cleanliness more than makes up for it.

I don't think so, and the reason is that this won't clean
up the code in Lisp programs at all.  On the contrary, it would
complicate them.

In other words, elegance of the mechanism is not the same thing
as simplicity of the user code.

We use method ii for hooks, but the complexity is hidden inside
two standard functions.

Re: Post-22.1 development?

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     There are two clean ways to do this is: (i) extend process-environment
>     so that if a symbol occurs in the list, as opposed to a string, that
>     symbol names a list whose elements are to be used (as though they had
>     been inserted in process-environment).  Then the final element for all
>     default values of process-environment would include the symbol
>     `global-process-environment'; or (ii) extend process-environment so
>     that an element of `t' means "the global value of this variable"
>     (similar to hook variables).
>
> These are more elegant, but I am not sure it matters in practice.
>
>     Either of these approaches would be backward compatible for
>     third-party than the shared-tail idea, but IMHO the gain in
>     cleanliness more than makes up for it.
>
> I don't think so, and the reason is that this won't clean
> up the code in Lisp programs at all.  On the contrary, it would
> complicate them.
>
> In other words, elegance of the mechanism is not the same thing
> as simplicity of the user code.
>
> We use method ii for hooks, but the complexity is hidden inside
> two standard functions.

In this case, there are setenv and getenv.

As for whether elegance of the mechanism matters in practice, consider
the case where you want to (i) change a variable in the local
environment and leave the global one unchanged, or (ii) ensure that a
change you make in process-environment affects the global environment
too.  Assume you don't want to use setenv and getenv (if you do use
setenv and getenv, the point is moot, since the more elegant mechanism
wins anyway.)  With the shared-tail mechanism, you would need to grep
for the empty string "", and hope that that's really the correct
marker separating the local and global lists, not a spurious marker
inserted by someone else.  Worse, there is no way to know for certain.

Re: Post-22.1 development?

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     There are two clean ways to do this is: (i) extend
>>     process-environment so that if a symbol occurs in the list, as
>>     opposed to a string, that symbol names a list whose elements
>>     are to be used (as though they had been inserted in
>>     process-environment).  Then the final element for all default
>>     values of process-environment would include the symbol
>>     `global-process-environment'; or (ii) extend
>>     process-environment so that an element of `t' means "the global
>>     value of this variable" (similar to hook variables).
>>
>> These are more elegant, but I am not sure it matters in practice.
>>
>>     Either of these approaches would be backward compatible for
>>     third-party than the shared-tail idea, but IMHO the gain in
>>     cleanliness more than makes up for it.
>>
>> I don't think so, and the reason is that this won't clean up the
>> code in Lisp programs at all.  On the contrary, it would complicate
>> them.
>>
>> In other words, elegance of the mechanism is not the same thing
>> as simplicity of the user code.
>>
>> We use method ii for hooks, but the complexity is hidden inside
>> two standard functions.
>
> In this case, there are setenv and getenv.
>
> As for whether elegance of the mechanism matters in practice,
> consider the case where you want to (i) change a variable in the
> local environment and leave the global one unchanged,

Done by manipulating the front of the list.

> or (ii) ensure that a change you make in process-environment affects
> the global environment too.

Done by manipulating the tail.

> Assume you don't want to use setenv and getenv (if you do use setenv
> and getenv, the point is moot, since the more elegant mechanism wins
> anyway.)

The point is not moot since setenv is supposed to have only local
effects if it is called after let-binding process-environment to a
copy of itself.

> With the shared-tail mechanism, you would need to grep for the empty
> string "", and hope that that's really the correct marker separating
> the local and global lists, not a spurious marker inserted by
> someone else.

You'd use global-process-environment, which incidentally starts with
an empty string.

As to someone inserting spurious markers: that is actually nothing to
worry about.  People tampering with internals deserve what they get.

> Worse, there is no way to know for certain.

Which is just as well, since the mechanism is supposed to be workable
for _both_ sharing most of the environment as well as having most of
it disparate.  It keeps open our options for now without sacrificing
backward compatibility.

At one point of time we can close down various options, and at another
point of time we can close down backward compatibility.  This
implementation allows us to tackle this one step at a time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Post-22.1 development?

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> The proposal was to have process-environment a terminal-local
>> variable.  It is set up starting with its own values of DISPLAY and
>> TERM.  Each last terminal-local cons-cell has a cdr of
>> global-process-environment.  This is a "shared tail" starting with the
>> empty string "" (which is an environment element satisfying stringp,
>> but not matching any useful string pattern).  setenv will use setcar
>> to replace an existing environment variable definition it finds in
>> process-environment, and will append non-existing definitions at the
>> end of process-environment.
>
> I think it's a bad idea to use a shared tail in this way.

I concur it is ugly.  However, it is also expedient in that it lets us
experiment with several concepts of sharing and not sharing
environment variables, _without_ requiring to meddle with unrelated
code until we have settled on one or the other paradigm.

> I can't think of anywhere else in Emacs where this kind of
> convoluted setup is used, and it seems to go against the way similar
> problems are solved elsewhere in Emacs.
>
> There are two clean ways to do this is: (i) extend
> process-environment so that if a symbol occurs in the list, as
> opposed to a string, that symbol names a list whose elements are to
> be used (as though they had been inserted in process-environment).
> Then the final element for all default values of process-environment
> would include the symbol `global-process-environment';

It does not work.  setenv is normally supposed to set an environment
variable for _all_ terminals, _unless_ process-environment has been
set to a _copy_ of itself.  The shared tail makes the detach-on-copy
operation work.

> or (ii) extend process-environment so that an element of `t' means
> "the global value of this variable" (similar to hook variables).
>
> Either of these approaches would be backward compatible for

_not_ be backward compatible, you mean.

> third-party than the shared-tail idea, but IMHO the gain in
> cleanliness more than makes up for it.

With that kind of change, we might equally well _remove_
process-environment altogether in favor of some other accessor
functions.  The effect will be the same: pretty much _everything_
looking at process-environment will break.

It might be an API of choice in the long run.  In the mean time, the
shared tail _implementation_ provides a migration strategy.  We can
(once we find ourselves converging to a preferred behavior) introduce
accessor functions at some point of time, and then start deprecating
process-environment.  But that's a long haul.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Post-22.1 development?

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

>> I think it's a bad idea to use a shared tail in this way.
>
> I concur it is ugly.  However, it is also expedient in that it lets
> us experiment with several concepts of sharing and not sharing
> environment variables, _without_ requiring to meddle with unrelated
> code until we have settled on one or the other paradigm.

I don't understand what the purpose of this experimentation is.  What
exactly do you want to find out with these "experiments"?

Instead of making a change that we might want to completely revamp
(or, worse, get stuck with an ugly API because it's too much trouble
to revamp), why not just adopt Stefan's very reasonable plan:

> I think the right way to do it is to change the multi-tty code's
> handling of environment so that it preserves the old behavior (and
> probably breaks some of the multi-tty support), then merge into the
> trunk, then try and fix the multi-tty part of the breakage.

Re: Post-22.1 development?

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> I think it's a bad idea to use a shared tail in this way.
>>
>> I concur it is ugly.  However, it is also expedient in that it lets
>> us experiment with several concepts of sharing and not sharing
>> environment variables, _without_ requiring to meddle with unrelated
>> code until we have settled on one or the other paradigm.
>
> I don't understand what the purpose of this experimentation is.
> What exactly do you want to find out with these "experiments"?

There have been sharp disagreements as to whether or not this
separation is a good idea for unrelated variables, or whether one
would want to share between some clients/terminals/sessions or not.
No agreement could be reached.  Being able to _switch_ will make it
possible for users to work with both approaches, with multiple use
patterns and requirements.  We can then meaningfully poll them at one
point of time.

> Instead of making a change that we might want to completely revamp
> (or, worse, get stuck with an ugly API because it's too much trouble
> to revamp), why not just adopt Stefan's very reasonable plan:
>
>> I think the right way to do it is to change the multi-tty code's
>> handling of environment so that it preserves the old behavior (and
>> probably breaks some of the multi-tty support), then merge into the
>> trunk, then try and fix the multi-tty part of the breakage.

Which is pretty much what my proposal is supposed to achieve: preserve
the old behavior.  It is just that I also have taken the step of
proposing a plan how to fix the multi-tty part of the breakage.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Post-22.1 development?

[Jeremy Maitin-Shepard]

David Kastrup <dak@gnu.org> writes:

[snip]

> With that kind of change, we might equally well _remove_
> process-environment altogether in favor of some other accessor
> functions.  The effect will be the same: pretty much _everything_
> looking at process-environment will break.

> It might be an API of choice in the long run.  In the mean time, the
> shared tail _implementation_ provides a migration strategy.  We can
> (once we find ourselves converging to a preferred behavior) introduce
> accessor functions at some point of time, and then start deprecating
> process-environment.  But that's a long haul.

It seems that it would be useful to provide very soon accessor functions
or macros for performing all environment-related operations that allow
for the desired genericity in implementation choice.  That way, at least
new code can use the accessors, and not need fixing later.  Furthermore,
by adding these accessors to Emacs 22 (but not necessarily changing any
code in Emacs 22 to use them), packages can remain to be compatible with
Emacs 22.

Once this is done, maintaining backwards compatibility becomes less of a
concern, and the need for an implementation hack is lessened.

-- 
Jeremy Maitin-Shepard

Re: Post-22.1 development?

[Miles Bader]

Jeremy Maitin-Shepard <jbms@cmu.edu> writes:
> It seems that it would be useful to provide very soon accessor functions
> or macros for performing all environment-related operations that allow
> for the desired genericity in implementation choice.

It seems a bit hard to be sufficiently generic to accomodate _all_ the
discussed possiblities without a rather awkward interface, mostly
because of the question of what happens when you let-bind
process-environment.

Given that the current interface (without multi-tty) is actually quite
convenient and elegant, I'd rather prefer we aim at preserving it even
with multi-tty.

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: Post-22.1 development?

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> Jeremy Maitin-Shepard <jbms@cmu.edu> writes:
>> It seems that it would be useful to provide very soon accessor functions
>> or macros for performing all environment-related operations that allow
>> for the desired genericity in implementation choice.
>
> It seems a bit hard to be sufficiently generic to accomodate _all_ the
> discussed possiblities without a rather awkward interface, mostly
> because of the question of what happens when you let-bind
> process-environment.
>
> Given that the current interface (without multi-tty) is actually quite
> convenient and elegant, I'd rather prefer we aim at preserving it even
> with multi-tty.

Well, it is not as much an interface rather than exposed internals.
There is no reason, for example, that one needs to write

(let ((process-environment (copy-sequence process-environment)))
  (setenv ...
)

rather than

(with-local-environment
  (setenv ...
)

However, designing, implementing and _mandating_ something like the
latter takes time and several releases.

-- 
David Kastrup

Re: Post-22.1 development?

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Well, it is not as much an interface rather than exposed internals.
> There is no reason, for example, that one needs to write
>
> (let ((process-environment (copy-sequence process-environment)))
>   (setenv ...
> )

Well, nobody actually writes that though.

People write:

   (let ((process-environment (cons ... process-environment)))
     ...)

Which is a documented interface, is very convenient, and works pretty well.

-Miles

-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: Post-22.1 development?

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> David Kastrup <dak@gnu.org> writes:
>> Well, it is not as much an interface rather than exposed internals.
>> There is no reason, for example, that one needs to write
>>
>> (let ((process-environment (copy-sequence process-environment)))
>>   (setenv ...
>> )
>
> Well, nobody actually writes that though.

-*- mode: grep; default-directory: "/usr/share/man/man1/" -*-
Grep started at Thu Jun 14 09:29:00

find /rep/emacs -type f -print0 | xargs -0 -e fgrep -nH -e '(copy-sequence process-environment)'
/rep/emacs/lisp/dired.el:958:	(process-environment (copy-sequence process-environment))
/rep/emacs/lisp/man.el:738:      (let ((process-environment (copy-sequence process-environment))
/rep/emacs/lisp/net/browse-url.el:763:  (let ((process-environment (copy-sequence process-environment)))
/rep/emacs/lisp/net/tramp.el:5691:    (let ((process-environment (copy-sequence process-environment)))
/rep/emacs/lisp/net/tramp.el:5752:    (let ((process-environment (copy-sequence process-environment))
/rep/emacs/lisp/net/tramp.el:5824:    (let ((process-environment (copy-sequence process-environment)))
/rep/emacs/lisp/net/tramp.el:5889:    (let ((process-environment (copy-sequence process-environment)))
/rep/emacs/lisp/progmodes/compile.el:1078:	      (copy-sequence process-environment))))
/rep/emacs/lisp/progmodes/cperl-mode.el:8634:      (let ((process-environment (copy-sequence process-environment)))

Grep finished (matches found) at Thu Jun 14 09:29:18


> People write:
>
>    (let ((process-environment (cons ... process-environment)))
>      ...)

-*- mode: grep; default-directory: "/usr/share/man/man1/" -*-
Grep started at Thu Jun 14 09:32:57

find /rep/emacs -type f -print0 | xargs -0 -e fgrep -nH -e 'process-environment (cons'

Grep exited abnormally with code 123 at Thu Jun 14 09:32:57

-- 
David Kastrup

Re: Post-22.1 development?

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> find /rep/emacs -type f -print0 | xargs -0 -e fgrep -nH -e 'process-environment (cons'
>
> Grep exited abnormally with code 123 at Thu Jun 14 09:32:57

Geez, David, the code isn't _syntactically identical_ to my example.
Look more carefully.

-Miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Post-22.1 development?

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> David Kastrup <dak@gnu.org> writes:
>> find /rep/emacs -type f -print0 | xargs -0 -e fgrep -nH -e 'process-environment (cons'
>>
>> Grep exited abnormally with code 123 at Thu Jun 14 09:32:57
>
> Geez, David, the code isn't _syntactically identical_ to my example.
> Look more carefully.

Anyway, the main point was that you claimed people don't use
copy-sequence on process-environment, and I found _quite_ a few hits
for that, "syntactically identical".

-- 
David Kastrup

Re: Post-22.1 development?

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Anyway, the main point was that you claimed people don't use
> copy-sequence on process-environment, and I found _quite_ a few hits
> for that, "syntactically identical".

Well there are always a few weirdos out there ... :-)

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: Post-22.1 development?

[Stefan Monnier]

> The proposal was to have process-environment a terminal-local
> variable.  It is set up starting with its own values of DISPLAY and
> TERM.

Actually, the value of TERM is only for internal use and should never be
passed on to subprocesses, so its presence in process-environment is
not important.


        Stefan

Re: Post-22.1 development?

[Richard Stallman]

    Actually, the value of TERM is only for internal use and should never be
    passed on to subprocesses, so its presence in process-environment is
    not important.

That is true, in a sense.  However, at present the primitives to create
subprocesses just pass TERM along to the subprocess.  Thus, it is up to
the Lisp code to set it.

Should this work differently?  Should we do something in call-process
and start-process to set TERM?

Re: Post-22.1 development?

[Stefan Monnier]

>     Actually, the value of TERM is only for internal use and should never be
>     passed on to subprocesses, so its presence in process-environment is
>     not important.

> That is true, in a sense.  However, at present the primitives to create
> subprocesses just pass TERM along to the subprocess.  Thus, it is up to
> the Lisp code to set it.

Yes and it's a bug (which occasionally causes things like subprocesses
returning to Emacs ASCII escape sequences where they're not expected).
This bug was temporarily "fixed" (by yours truly) some time in the past on
the CVS trunk by removing TERM from process-environment at startup (or
rather setting it to a safe default such as "TERM=dumb").  This is
fundamentally the right thing to do, although the way I did this was wrong
(which is why it was later reverted).

The right way to do it is to remove it from process-environment
(i.e. remove it from the environment passed to subprocesses) but store it
elsewhere.  I think in general, we should be careful to distinguish the
environment inherited from our parent process (which is currently available
only through process-environment but should be stored elsewhere so as to be
available even after modifying process-environment) from the environment
that will be passed to subprocesses (which is obviously
process-environment, as the name clearly implies).

> Should this work differently?  Should we do something in call-process
> and start-process to set TERM?

It should be done directly at startup.


        Stefan

Re: Post-22.1 development?

[Richard Stallman]

    The proposal was to have process-environment a terminal-local
    variable.  It is set up starting with its own values of DISPLAY and
    TERM.  Each last terminal-local cons-cell has a cdr of
    global-process-environment.  This is a "shared tail" starting with the
    empty string "" (which is an environment element satisfying stringp,
    but not matching any useful string pattern).  setenv will use setcar
    to replace an existing environment variable definition it finds in
    process-environment, and will append non-existing definitions at the
    end of process-environment.

I guess you've verified that the usual ways of using process-environment
will work unchanged with this, right?

Does someone have another idea for a way to avoid the need
to change the programs that operate on the environment?

Re: Post-22.1 development?

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

> Does someone have another idea for a way to avoid the need
> to change the programs that operate on the environment?

I fear it is even more complex. Processes running on remote hosts
(started by process-file, for example) would need a different process
environment but the one inherited from the local host. This is an item
being on my wish list for a long time.

Best regards, Michael.

Re: Post-22.1 development?

[Stefan Monnier]

>> Does someone have another idea for a way to avoid the need
>> to change the programs that operate on the environment?

> I fear it is even more complex.  Processes running on remote hosts
> (started by process-file, for example) would need a different process
> environment but the one inherited from the local host.  This is an item
> being on my wish list for a long time.

I don't understand how that relates.  And I don't understand why it can't be
done in the process-file file-name-handler.


        Stefan

Re: Post-22.1 development?

[Michael Albinus]

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

>>> Does someone have another idea for a way to avoid the need
>>> to change the programs that operate on the environment?
>
>> I fear it is even more complex.  Processes running on remote hosts
>> (started by process-file, for example) would need a different process
>> environment but the one inherited from the local host.  This is an item
>> being on my wish list for a long time.
>
> I don't understand how that relates.  And I don't understand why it can't be
> done in the process-file file-name-handler.

Tramp manages it locally already. The point is when it comes to
environment variables a user wants to be set on the remote host. He
could write of course

(let ((process-envrionment ...))
   (setenv XXX ...)
   (process-file ...))

But $XXX would be set for the local case as well, because Tramp must
start with a local call-process or start-process. This could result in
undesired behaviour.

For the most obvious case, Tramp offers the variable tramp-remote-path.
People could apply something like this before calling process-file:

     (add-to-list 'tramp-remote-path "/usr/local/perl/bin")

But a more general mechanism, applicable for any environment variable on
the remote host, would be desirable, IMHO.

>         Stefan

Best regards, Michael.

Re: Post-22.1 development?

[Stefan Monnier]

>>>> Does someone have another idea for a way to avoid the need
>>>> to change the programs that operate on the environment?
>> 
>>> I fear it is even more complex.  Processes running on remote hosts
>>> (started by process-file, for example) would need a different process
>>> environment but the one inherited from the local host.  This is an item
>>> being on my wish list for a long time.
>> 
>> I don't understand how that relates.  And I don't understand why it can't be
>> done in the process-file file-name-handler.

> Tramp manages it locally already. The point is when it comes to
> environment variables a user wants to be set on the remote host. He
> could write of course

> (let ((process-environment ...))
>    (setenv XXX ...)
>    (process-file ...))

> But $XXX would be set for the local case as well, because Tramp must
> start with a local call-process or start-process. This could result in
> undesired behaviour.

Oh, I see.  So yes, it's related: it shows there's a need to keep both the
normal environment and the "environment for the subprocess started by
call/start-process".

For Tramp, it's indeed pretty tricky: the environment to use for the local
process is not the one you receive from process-environment (which is
destined to the remote process) but is rather "the global default
process-environment" (maybe with a few minor adjustments).  But this default
process-environment is not quite the same as the initial-environment that
I proposed either (although it can probably get by with just
initial-environment).


        Stefan

Re: Post-22.1 development?

[Richard Stallman]

What do people think of this idea: make call-process and start-process
supply the values of the envvars TERM and DISPLAY from two variables,
term-environment-variable and display-environment-variable,
if they are not specified in process-environment.
These two variables would normally be frame-local, and in each frame,
they would have the right values for that frame's terminal.

This way, Lisp programs that bind TERM explicitly will work right.
However, in the future they could bind term-environment-variable and
display-environment-variable, instead of fussing with
process-environment.

Would someone like to check whether this gives good results all
around, for the Lisp code that operates on the environment?

Re: Post-22.1 development?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> What do people think of this idea: make call-process and
> start-process supply the values of the envvars TERM and DISPLAY from
> two variables, term-environment-variable and
> display-environment-variable, if they are not specified in
> process-environment.  These two variables would normally be
> frame-local, and in each frame, they would have the right values for
> that frame's terminal.

I'd make them terminal-local.  One could also put everything into one
terminal-local "terminal-process-environment" which would be
effectively prepended to process-environment.

I'd prefer that approach, and it would mostly work in _my_ preferred
modus operandi.  However, see below:

> This way, Lisp programs that bind TERM explicitly will work right.
> However, in the future they could bind term-environment-variable and
> display-environment-variable, instead of fussing with
> process-environment.
>
> Would someone like to check whether this gives good results all
> around, for the Lisp code that operates on the environment?

The problem I see with this is that Károly expressed a strong
preference for having the _complete_ environment terminal-local
(personally, I think this a bad idea but have not been able to
convince him and several others): he preferred to consider a
separately started emacsclient session to have an _independent_
complete set of environment variables.

Using the above scheme with terminal-process-environment would still
facilitate that, but in that case most of the direct manipulations and
queries working on process-environment would fail to work.

So this scheme, while definitely cleaner than the shared-tail
approach, would not be backward-compatible to a large body of existing
code _if_ people tried to make the bulk of their environment
terminal-local.

The effects would be somewhat ameliorated by only putting environment
variables which _differ_ from the global setting into
terminal-process-environment, but it would be still quite a nuisance.

-- 
David Kastrup

Re: Post-22.1 development?

[Richard Stallman]

      These two variables would normally be
    > frame-local, and in each frame, they would have the right values for
    > that frame's terminal.

    I'd make them terminal-local.

Either one.

    The problem I see with this is that Károly expressed a strong
    preference for having the _complete_ environment terminal-local
    (personally, I think this a bad idea but have not been able to
    convince him and several others): he preferred to consider a
    separately started emacsclient session to have an _independent_
    complete set of environment variables.

If we want that, it can be a separate and independent feature.
There is no need to combine that question with this one.
It is clear that TERM and DISPLAY should go with the terminal
regardless of use of emacsclient.

    Using the above scheme with terminal-process-environment would still
    facilitate that, but in that case most of the direct manipulations and
    queries working on process-environment would fail to work.

`terminal-process-environment' is cumbersome.  I'd rather have
`term-environment-variable' and `display-environment-variable',
as I explained.

This may require rewriting various Lisp programs -- but it brings a
benefit in clarity that can justify an incompatible change.

Re: Post-22.1 development?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       These two variables would normally be
>     > frame-local, and in each frame, they would have the right values for
>     > that frame's terminal.
>
>     I'd make them terminal-local.
>
> Either one.
>
>     The problem I see with this is that Károly expressed a strong
>     preference for having the _complete_ environment terminal-local
>     (personally, I think this a bad idea but have not been able to
>     convince him and several others): he preferred to consider a
>     separately started emacsclient session to have an _independent_
>     complete set of environment variables.
>
> If we want that, it can be a separate and independent feature.
> There is no need to combine that question with this one.
> It is clear that TERM and DISPLAY should go with the terminal
> regardless of use of emacsclient.
>
>     Using the above scheme with terminal-process-environment would still
>     facilitate that, but in that case most of the direct manipulations and
>     queries working on process-environment would fail to work.
>
> `terminal-process-environment' is cumbersome.  I'd rather have
> `term-environment-variable' and `display-environment-variable',
> as I explained.
>
> This may require rewriting various Lisp programs -- but it brings a
> benefit in clarity that can justify an incompatible change.

I think it would be confusing if setenv and most particularly getenv
did not work for TERM and DISPLAY variables, and I see no particular
benefit to letting them stop to work mostly as previously.  If
setenv/getenv are to remain the preferred accessors, it seems
reasonable to gather the terminal-local variables in a single list in
order not to have to special-case every variable.

-- 
David Kastrup

Re: Post-22.1 development?

[Richard Stallman]

    I think it would be confusing if setenv and most particularly getenv
    did not work for TERM and DISPLAY variables, and I see no particular
    benefit to letting them stop to work mostly as previously. 

I agree.  We can write special case code to handle these two
variables in those functions.

     If
    setenv/getenv are to remain the preferred accessors, it seems
    reasonable to gather the terminal-local variables in a single list in
    order not to have to special-case every variable.

I disagree there.  It is just two variables; handling each one specially
is not much complexity, and it is only inside setenv and getenv.
And separate variables will be more convenient for callers
of call-process, etc.

Re: Post-22.1 development?

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 03 Jun 2007 23:31:23 -0400
> 
> In a recent email, Stefan suggested that we should not restrict 22.x
> development to bugfixes, but also include new features if the new
> features are not too invasive.  Do people agree with this approach?
> If so, I think a reasonable procedure we can follow is to (i) go ahead
> and start merging *bugfixes* from the trunk into the branch, and (ii)
> make a request to emacs-devel for each new *feature* from the trunk
> that we want to add to the branch.

FWIW, I don't think we should merge changes that are safe until some
time has passed and we have some kind of idea about how buggy v22.1
is.  If the number of problems we hear on bug-gnu-emacs is large, then
we should stabilize 22.x before we merge changes that can potentially
destabilize it.

Re: Post-22.1 development?

[Richard Stallman]

    FWIW, I don't think we should merge changes that are safe until some
    time has passed and we have some kind of idea about how buggy v22.1
    is.  If the number of problems we hear on bug-gnu-emacs is large, then
    we should stabilize 22.x before we merge changes that can potentially
    destabilize it.

We need to see, first of all, how many problems are reported in 22.1.
We don't know how many Emacs 22 releases will be needed at all.

Re: Post-22.1 development?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     FWIW, I don't think we should merge changes that are safe until
>     some time has passed and we have some kind of idea about how
>     buggy v22.1 is.  If the number of problems we hear on
>     bug-gnu-emacs is large, then we should stabilize 22.x before we
>     merge changes that can potentially destabilize it.
>
> We need to see, first of all, how many problems are reported in
> 22.1.

Why do we need to see that?  Problems in 22.1 will be of two kinds:

a) Problems that have a better fix or solution in Emacs 23
b) Problems that have the same fix or solution in Emacs 23

In case a, we need to synchronize 2 solutions into three branches
(EMACS_22_BASE, trunk and unicode-2), in case b we need to synchronize
one solution into three branches.

That is one branch too many.  We are working towards two release
series at most (22.x and 23.1).  Branches in CVS are enough of a pain
that we don't want to keep three branches for two goals.

> We don't know how many Emacs 22 releases will be needed at all.

It does not matter.  We have the EMACS_22_BASE branch to cater for
them.  It is not like we are betting everything on the trunk.

-- 
David Kastrup

Re: Post-22.1 development?

[Richard Stallman]

    Why do we need to see that?  Problems in 22.1 will be of two kinds:

    a) Problems that have a better fix or solution in Emacs 23
    b) Problems that have the same fix or solution in Emacs 23

Even if it is "the same fix" at an abstract level, the details
may be different due to major redesigns such as unicode-2.

Re: Post-22.1 development?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Why do we need to see that?  Problems in 22.1 will be of two kinds:
>
>     a) Problems that have a better fix or solution in Emacs 23
>     b) Problems that have the same fix or solution in Emacs 23
>
> Even if it is "the same fix" at an abstract level, the details
> may be different due to major redesigns such as unicode-2.

And your point was?  It still does not make fixing a problem in three
branches (one of which will not end in a release) instead of two a
good idea.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Post-22.1 development?

[Richard Stallman]

    And your point was?  It still does not make fixing a problem in three
    branches (one of which will not end in a release) instead of two a
    good idea.

I don't think that accurately describes what we will be doing.

Re: Post-22.1 development?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 05 Jun 2007 08:17:28 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> >     FWIW, I don't think we should merge changes that are safe until
> >     some time has passed and we have some kind of idea about how
> >     buggy v22.1 is.  If the number of problems we hear on
> >     bug-gnu-emacs is large, then we should stabilize 22.x before we
> >     merge changes that can potentially destabilize it.
> >
> > We need to see, first of all, how many problems are reported in
> > 22.1.
> 
> Why do we need to see that?  Problems in 22.1 will be of two kinds:
> 
> a) Problems that have a better fix or solution in Emacs 23
> b) Problems that have the same fix or solution in Emacs 23

In case it wasn't clear, _I_ was talking about merging changes to the
EMACS_22_BASE branch, not to the trunk.

Re: Post-22.1 development?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Tue, 05 Jun 2007 08:17:28 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, cyd@stupidchicken.com, emacs-devel@gnu.org
>> 
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> >     FWIW, I don't think we should merge changes that are safe until
>> >     some time has passed and we have some kind of idea about how
>> >     buggy v22.1 is.  If the number of problems we hear on
>> >     bug-gnu-emacs is large, then we should stabilize 22.x before we
>> >     merge changes that can potentially destabilize it.
>> >
>> > We need to see, first of all, how many problems are reported in
>> > 22.1.
>> 
>> Why do we need to see that?  Problems in 22.1 will be of two kinds:
>> 
>> a) Problems that have a better fix or solution in Emacs 23
>> b) Problems that have the same fix or solution in Emacs 23
>
> In case it wasn't clear, _I_ was talking about merging changes to the
> EMACS_22_BASE branch, not to the trunk.

Hm, I was of the opinion that the topic of the thread was the question
what is keeping us from merging unicode-2 into the trunk.  Richard
suggested that we wanted to keep the trunk close to EMACS_22_BASE for
several months.  I protested, and Jason said that if there were things
in the trunk intended for 22.2, we should merge them into
EMACS_22_BASE now so that the trunk is free for getting unicode-2
merged into it.

And Jason said that 22.2-relevant fixes/changes should then happen in
EMACS_22_BASE and possibly be merged back into the trunk.  I disagree
here, actually: I'd start all fixes that make sense in 23.1 in the
trunk.  Merging them into EMACS_22_BASE would remain the
responsibility of the people interested on working on EMACS_22_BASE
(it would be the job of the Emacs 22 maintainer, whether or not that
is the same person as the trunk maintainer, to check stuff regularly
and nag people about putting them into EMACS_22_BASE if he thinks this
desirable).  Anyway, this is a detail where Jason and I have different
opinions.

Sure, accepting Richard's suggestion that we should keep trunk
parallel to EMACS_22_BASE and have a _separate_ unicode-2 for some
months, leads to the question whether to put Emacs 22.2 development
first into EMACS_22_BASE and then copy to the trunk, or the other way
round.

But I consider it a mistake to even ponder this question: when the
plan is to keep them identical, we don't need two branches for that.
It is just a nonsensical duplication of effort, and whether we copy
from A to B or from B to A while keeping A and B identical is just
smokescreen over the fact that we don't need both A and B if we intend
to keep them the same.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Post-22.1 development?

[Richard Stallman]

      Richard
    suggested that we wanted to keep the trunk close to EMACS_22_BASE for
    several months.

Yes, that is what I want to do.

		     I protested, and Jason said that if there were things
    in the trunk intended for 22.2, we should merge them into
    EMACS_22_BASE now

That is not the reason.  (And I think those merges have been done,
or most of them at least.)

     so that the trunk is free for getting unicode-2
    merged into it.

I've already stated the reason for this, and it still applies.

    But I consider it a mistake to even ponder this question: when the
    plan is to keep them identical, we don't need two branches for that.

There is no plan to keep them identical.
The plan is to install lots of improvements in the trunk,
and put only a few of them into Emacs 22.2.

     > What does the feedback consist of?  Users saying they wish the GTK
     > build were the default?  I believe there are some.  However, how many
     > users said nothing because they are happy that GTK is NOT the default?

    There's a long thread on fedora-devel (Why isn't emacs installed by default)

I can't read it there, but I would like to know what it says
that is relevant.

What did people there say about this particular question?
And how many of them supported it?

Re: Post-22.1 development?

[Nick Roberts]

 >      > What does the feedback consist of?  Users saying they wish the GTK
 >      > build were the default?  I believe there are some.  However, how many
 >      > users said nothing because they are happy that GTK is NOT the default?
 > 
 >     There's a long thread on fedora-devel (Why isn't emacs installed by default)
 > 
 > I can't read it there, but I would like to know what it says
 > that is relevant.
 > 
 > What did people there say about this particular question?
 > And how many of them supported it?

It's a bit rambling, but the relevant part is how Emacs doesn't sit naturally
on a modern Desktop.  I don't fully understand the issues but Jan D. could
probably explain them.

This is what Nicolas Mailhot <nicolas.mailhot at laposte dot net> say:

> > Can you please explain what you are talking about?  By "targets
> > 1995-ish desktops," do you mean that emacs lacks pop-up windows,
> > icons, menus, and so, on?  Or something else you desire?

> I mean emacs does not use the current desktop font infrastructure,
> does not use one of the main GUI desktop toolkits, does not support
> cleanly i18n & our main encoding (UTF-8), does not integrate with the
> accessibility infrastructure, does not integrate with the printing
> infrastructure, and the list goes on and on.

I've not cross-posted, but you could ask him how specifically it could be
improved, e.g., I don't know what he means by printing infrastructure.

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

Re: Post-22.1 development?

[Jan Djärv]

Nick Roberts skrev:
>  >      > What does the feedback consist of?  Users saying they wish the GTK
>  >      > build were the default?  I believe there are some.  However, how many
>  >      > users said nothing because they are happy that GTK is NOT the default?
>  > 
>  >     There's a long thread on fedora-devel (Why isn't emacs installed by default)
>  > 
>  > I can't read it there, but I would like to know what it says
>  > that is relevant.
>  > 
>  > What did people there say about this particular question?
>  > And how many of them supported it?
> 
> It's a bit rambling, but the relevant part is how Emacs doesn't sit naturally
> on a modern Desktop.  I don't fully understand the issues but Jan D. could
> probably explain them.

It is a lot of general comments but very few specific.  Also they seem to be 
based on a non-Gtk build of Emacs.  But even with a Gtk build, there are 
things lacking, and what I think they mean are:

Emacs does not use the desktop (Gnome) infratructure/API:s when it comes to:

- Printing, basically Emacs does not have a "modern" print dialog.

- Fonts, AA fonts and respecting the fonts selected by the user in his desktop 
preferences, including switching fonts on the fly when the user changes his 
preferences.  A font dialog chooser is missing.

- Themes, Emacs currently don't respect themes fully.  I.e. if the icons for 
the tool bar changes, Emacs still uses its own.  If the background/foreground 
color is changed, Emacs does that for Gtk widgets, but not for the main edit 
area.  Ditto for example, cursor colors, cursor shape, mouse pointer shape.

- Session management.  We have that now in 22.1, but Emacs does not restore 
the frame layout as it was.

Some minor things I can think of:

Drag and drop - We can't drag text or images from Emacs to another application.

Image support - Emacs does not use the Gnome infrastructure for this, so Emacs 
is limited to the image types it find libraries for at compile time.

And some things they may mean, but I'm not sure that it matters for a user:

Configuration - Emacs don't use what other Gnome applications use, i.e. GConf.
UTF-8/Pango   - Emacs has its own internationalization infrastructure
that sometime don't play nice with other apps (basically other Gnome apps assume
UTF-8 everywhere).
Gmome libraries - If Emacs where to use more Gnome libraries instead of having 
its own version of some code (session management, font handling, dialogs, 
configuration, themes, widgets, printing), Emacs would benefit automatically 
when these libraries are updated.


Now some of these are being done (AA fonts), some I have patches for (better 
theme handling, dnd), some are on my TODO-list, some we will probably never do 
(for example use GConf instead of ~/.emacs[.d]).

	Jan D.

Re: Post-22.1 development?

[Miles Bader]

Jan Djärv <jan.h.d@swipnet.se> writes:
>> It's a bit rambling, but the relevant part is how Emacs doesn't sit
>> naturally on a modern Desktop.  I don't fully understand the issues but
>> Jan D. could probably explain them.
>
> It is a lot of general comments but very few specific.  Also they seem to
> be based on a non-Gtk build of Emacs.  But even with a Gtk build, there
> are things lacking, and what I think they mean are:

...

A large part of what you listed basically comes down to "Emacs is not a
Gnome program"... which is inarguably true.

But "not a gnome program" != "doesn't sit naturally on a modern desktop":
most of these points apply to almost every other non-gnome program out
there -- including programs using very functional and polished
non-gtk/gnome GUI/infrastructure toolkits.

-Miles
-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: Post-22.1 development?

[Jan Djärv]

Miles Bader skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
>>> It's a bit rambling, but the relevant part is how Emacs doesn't sit
>>> naturally on a modern Desktop.  I don't fully understand the issues but
>>> Jan D. could probably explain them.
>> It is a lot of general comments but very few specific.  Also they seem to
>> be based on a non-Gtk build of Emacs.  But even with a Gtk build, there
>> are things lacking, and what I think they mean are:
> 
> ...
> 
> A large part of what you listed basically comes down to "Emacs is not a
> Gnome program"... which is inarguably true.
> 
> But "not a gnome program" != "doesn't sit naturally on a modern desktop":
> most of these points apply to almost every other non-gnome program out
> there -- including programs using very functional and polished
> non-gtk/gnome GUI/infrastructure toolkits.

Yes, I got the same impression.  Someone argued that firefox/mozilla by that 
standard is not well integrated either.  I often use ghostview, xpdf, xdvi, 
and they are even less integrated than Emacs.  But very useful nontheless and 
the lack of "integration" hasn't been anything I ever thought about.

Some things may be worth adressing, but I think mostly this is the same "If it 
isn't Gnome, it sucks"-attitude that Gnome people seem to have.

	Jan D.

Re: Post-22.1 development?

[Nick Roberts]

 > Yes, I got the same impression.  Someone argued that firefox/mozilla by that
 > standard is not well integrated either.  I often use ghostview, xpdf, xdvi,
 > and they are even less integrated than Emacs.  But very useful nontheless
 > and the lack of "integration" hasn't been anything I ever thought about.
 > 
 > Some things may be worth adressing, but I think mostly this is the same "If
 > it isn't Gnome, it sucks"-attitude that Gnome people seem to have.

There certainly was a line of thought that suggested the application had to fit
the requirements of the desktop, rather than the desktop accommodating the
application.  I guess it shouldn't be ignored, but it does seem to be a case
of the tail wagging the dog.

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

Re: Post-22.1 development?

[Richard Stallman]

    Some things may be worth adressing, but I think mostly this is the same "If it 
    isn't Gnome, it sucks"-attitude that Gnome people seem to have.

I don't think we should adopt an attitude of the form "If it isn't
Gnome, it sucks", but better integration with Gnome is a good thing.
And some Gnome dialogs might be substantially more convenient than the
current Emacs facilities.  Thus, supporting the Gnome dialogs might be
an improvement in general, as well as an improvement in coherence.

Re: Post-22.1 development?

[Jan Djärv]

Richard Stallman skrev:
>     Some things may be worth adressing, but I think mostly this is the same "If it 
>     isn't Gnome, it sucks"-attitude that Gnome people seem to have.
> 
> I don't think we should adopt an attitude of the form "If it isn't
> Gnome, it sucks", but better integration with Gnome is a good thing.
> And some Gnome dialogs might be substantially more convenient than the
> current Emacs facilities.  Thus, supporting the Gnome dialogs might be
> an improvement in general, as well as an improvement in coherence.
> 

It would probably mean that some stuff that are available with Gtk/Gnome won't
be for other ports (i.e. Lucid, Lesstif, basic X11).  Some things alredy are
different, but I suspect the divergence will be greater.  Maybe this isn't
such a big deal.

	Jan D.

Re: Post-22.1 development?

[Tom Tromey]

>>>>> "Jan" == Jan Djärv <jan.h.d@swipnet.se> writes:

Jan> - Printing, basically Emacs does not have a "modern" print dialog.

I thought the comment here was just about using the wrong program to
access printing.  But, I'm not an expert here.

Jan> - Fonts, AA fonts and respecting the fonts selected by the user
Jan> in his desktop preferences, including switching fonts on the fly
Jan> when the user changes his preferences.  A font dialog chooser is
Jan> missing.

Here I thought the problem was Emacs using some old font infrastructure.

Jan> - Session management.  We have that now in 22.1, but Emacs does
Jan> not restore the frame layout as it was.

IMO -- don't bother with this.  The Gnome trend is away from session
management anyhow.


In general my understanding of the issue from the Fedora POV is that
keeping some old infrastructure (old fonts, old print subsystem,
whatever) around is a pain.  Whether or not Emacs looks "Gnome-like"
is not really a distro issue.  So the issue is, make sure Emacs is
using the current blessed technology.

While I think in some cases better desktop integration is nice, Emacs
is also unusual and it doesn't always make sense to try to make it fit
in.  I suppose this is the "old time Emacs user" approach :)


That said, there are a couple desktop integration areas I'm interested
in:

* Notification area support.  I have a hacked zenity that does most of
  what I want -- albeit poorly.  Direct support in Emacs would be much
  better.

* Keyring support.  I have some code for this (supporting either the
  Gnome keyring or a private Emacs-specific one), but I haven't wired
  it in to all the code in Emacs that uses passwords.


Disclaimer: despite my email address I'm not involved in decision
making for Fedora.

Tom

Re: Post-22.1 development?

[David House]

On 07/06/07, Tom Tromey <tromey@redhat.com> wrote:
> * Notification area support.  I have a hacked zenity that does most of
>   what I want -- albeit poorly.  Direct support in Emacs would be much
>   better.

I'd love to see this -- for example, an icon that sits in the tray and
flashes when someone mentions your nick in ERC.

-- 
-David House, dmhouse@gmail.com

Re: Post-22.1 development?

[Tom Tromey]

>>>>> "David" == David House <dmhouse@gmail.com> writes:

>> * Notification area support.  I have a hacked zenity that does most of
>> what I want -- albeit poorly.  Direct support in Emacs would be much
>> better.

David> I'd love to see this -- for example, an icon that sits in the
David> tray and flashes when someone mentions your nick in ERC.

Right now I have:

* ERC support (an "erc-status" module).  Flashes when your nick is
  seen, clicking shows that buffer, notifies when you enter/leave a
  server.  In theory there's a menu but this is broken ATM.

* Calendar support -- kinda buggy, but pops up a notification for an
  appointment, and clicking shows the calendar.

* EMMS support.  Tooltip shows the current song, clicking pauses or
  un-pauses play.

I think more than half of my notification area icons come from Emacs :-)

It is a pain to set up right now, you need to patch zenity (the patch
is in Gnome bugzilla).  See:

    http://tromey.com/blog/?p=309
    http://tromey.com/blog/?p=308

... but look for status.el and erc-status.el on gnu-emacs-sources,
since I posted newer versions.

For real Emacs integration I was thinking of having a new kind of
icon-only frame.  I think this would let the menus work more nicely.
I haven't looked into implementing this... I'd like to but it is hard
to know whether I'll find the time.  Anyway, I welcome advice & input
on this.

Tom

Re: Post-22.1 development?

[Jan Djärv]

Tom Tromey skrev:
>>>>>> "Jan" == Jan Djärv <jan.h.d@swipnet.se> writes:
> 
> Jan> - Printing, basically Emacs does not have a "modern" print dialog.
> 
> I thought the comment here was just about using the wrong program to
> access printing.  But, I'm not an expert here.

Neither am I.  The comments weren't detailed.  But by using the gnome printing 
code, I guess Emacs would automatically use the right program.


> 
> Jan> - Fonts, AA fonts and respecting the fonts selected by the user
> Jan> in his desktop preferences, including switching fonts on the fly
> Jan> when the user changes his preferences.  A font dialog chooser is
> Jan> missing.
> 
> Here I thought the problem was Emacs using some old font infrastructure.

If you consider non-AA fonts the old infrastructure (i.e. basic X11), so yes. 
  But I don't think X11 will suddenly drop all its fonts and the related 
library calls.  Emacs uses plain X11, I don't see why it is such a pain to 
maintain that.  There must be other programs besides Emacs that uses that.

> 
> Jan> - Session management.  We have that now in 22.1, but Emacs does
> Jan> not restore the frame layout as it was.
> 
> IMO -- don't bother with this.  The Gnome trend is away from session
> management anyhow.
> 

Okay, good to know.

> 
> In general my understanding of the issue from the Fedora POV is that
> keeping some old infrastructure (old fonts, old print subsystem,
> whatever) around is a pain.  Whether or not Emacs looks "Gnome-like"
> is not really a distro issue.  So the issue is, make sure Emacs is
> using the current blessed technology.

As you may have noticed, an Emacs release takes time, and in that time the 
blessed technology may have changed several times (like printing).  But any 
printing technology that doesn't offer a plain lpr command is severly broken IMHO.

> 
> While I think in some cases better desktop integration is nice, Emacs
> is also unusual and it doesn't always make sense to try to make it fit
> in.  I suppose this is the "old time Emacs user" approach :)

Emacs is multiplatform, whereas Gnome isn't.  Emacs has as a goal to be useful 
without Gnome.  There is a conflict here.

> 
> 
> That said, there are a couple desktop integration areas I'm interested
> in:
> 
> * Notification area support.  I have a hacked zenity that does most of
>   what I want -- albeit poorly.  Direct support in Emacs would be much
>   better.
> 

What would you think Emacs should do in the notification area?  Mail 
notification from GNUS and such, or just accessable from elisp?

> * Keyring support.  I have some code for this (supporting either the
>   Gnome keyring or a private Emacs-specific one), but I haven't wired
>   it in to all the code in Emacs that uses passwords.

That would be nice, it could be handy for Tramp and such.  But I don't think 
passwords are handeled in a central place in Emacs yet.  Something to work on.

	Jan D.

IPP under emacs [was: Re: Post-22.1 development?]

[Thien-Thi Nguyen]

() Jan Djärv <jan.h.d@swipnet.se>
() Fri, 08 Jun 2007 07:54:17 +0200

   Neither am I.  The comments weren't detailed.  But by using the gnome
   printing code, I guess Emacs would automatically use the right program.

how about emacs talking IPP[0] rfc3380[1] and rfc3998[2] directly?
would be nice to can get it all into emacs lisp where things are more
fluid and fun.  have socket, will spew...

in this way, we need not search for the right program because the right
program is emacs.

thi


[0] internet printing protocol
[1] job and printer set operations
[2] job and printer administrative operations

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Vinicius Jose Latorre]

Thien-Thi Nguyen wrote:
> () Jan Djärv <jan.h.d@swipnet.se>
> () Fri, 08 Jun 2007 07:54:17 +0200
>
>    Neither am I.  The comments weren't detailed.  But by using the gnome
>    printing code, I guess Emacs would automatically use the right program.
>
> how about emacs talking IPP[0] rfc3380[1] and rfc3998[2] directly?
> would be nice to can get it all into emacs lisp where things are more
> fluid and fun.  have socket, will spew...
>
> in this way, we need not search for the right program because the right
> program is emacs.
>
> thi
>
>
> [0] internet printing protocol
> [1] job and printer set operations
> [2] job and printer administrative operations
>   


Some time ago, Eric Marsden created the ipp.el package, see the links:

http://www.emacswiki.org/cgi-bin/wiki/EricMarsden
http://www.emacswiki.org/cgi-bin/wiki/InternetPrintingProtocol

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Ken Raeburn]

On Jun 8, 2007, at 10:25, Vinicius Jose Latorre wrote:
> Some time ago, Eric Marsden created the ipp.el package, see the links:
>
> http://www.emacswiki.org/cgi-bin/wiki/EricMarsden
> http://www.emacswiki.org/cgi-bin/wiki/InternetPrintingProtocol

Skimming the code (via the "permanent" link on the former page, not  
the latter, which seems to be out of date), it looks like at least  
some of the security aspects of the protocol have been omitted.  As  
opposed to some other protocols Emacs implements, where you can use  
it directly without any security, or you can use a helper program in  
a subprocess.

(putting my Network Security Geek hat on...)

I think it would be helpful for Emacs to grow some more network- 
protocol building blocks in this area.  Exactly what functionality  
would be needed and what the APIs should look like, I don't know off  
the top of my head, but it seems that Emacs has to call out to helper  
programs currently for protocols using Kerberos, GSSAPI, SASL, and  
TLS/SSL at least.  Making primitives for some of these available in  
Emacs (perhaps via helper programs, at least initially) would make it  
possible for Emacs to more directly implement application protocols  
like IMAP, IPP, and SMTP even with security features enabled, instead  
of adding helper programs for every application protocol that can  
negotiate security.

Like I said, I'm not sure what the APIs should look like in general.   
 From my own work, I'm pretty sure that GSSAPI primitives would be  
easy to implement with a helper program; the GSSAPI itself mostly  
operates by doing work on data blocks, leaving the caller to manage  
the low-level wire encoding and transmission as specified by the  
application protocol; that would fit in with the helper subprocess  
approach pretty easily.  I seem to recall seeing some work on TLS for  
Emacs done too, but I don't recall how general it was.

An obvious drawback to moving the support into Emacs itself is that  
we probably don't want to require that people have Kerberos/GSSAPI/ 
SASL/TLS/whatever installed in order to install a pre-packaged Emacs,  
nor do we want to inflate the number of Emacs packages that get put  
together by exploding the power set of options.  There are other  
approaches, though: dlopen on the libraries in question, helper  
programs in separate packages, Emacs extensions in C loadable at run  
time, etc.

Ken

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Jason Rumney]

Ken Raeburn wrote:
> I seem to recall seeing some work on TLS for Emacs done too, but I
> don't recall how general it was.

Do you mean lisp/net/tls.el, or something different?

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Ken Raeburn]

On Jun 8, 2007, at 16:20, Jason Rumney wrote:
> Ken Raeburn wrote:
>> I seem to recall seeing some work on TLS for Emacs done too, but I
>> don't recall how general it was.
>
> Do you mean lisp/net/tls.el, or something different?

That may be it.  It looks like it'll support the port-number-selected  
TLS protocols, but I don't see how it would support ones where use of  
TLS is negotiated by the application protocol after the connection is  
established (e.g., STARTTLS in SMTP).

I see gnus also has a starttls.el; it has some interesting other bits  
to it, I don't know if it'll provide that support either though.

I was probably thinking of one of the two; at the moment I can't find  
mention of any other such packages in my email archives.

Ken

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Jason Rumney]

Ken Raeburn wrote:
> That may be it.  It looks like it'll support the port-number-selected
> TLS protocols,
SSL?

> but I don't see how it would support ones where use of TLS is
> negotiated by the application protocol after the connection is established

It effective handles all network traffic by passing it through gnutls or
openssl. The former at least should handle TLS as well as SSL.

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Ken Raeburn]

On Jun 8, 2007, at 17:16, Jason Rumney wrote:
>> but I don't see how it would support ones where use of TLS is
>> negotiated by the application protocol after the connection is  
>> established
>
> It effective handles all network traffic by passing it through  
> gnutls or
> openssl. The former at least should handle TLS as well as SSL.

Yes, but from skimming the code and a couple comments in other email,  
it looks like negotiation of TLS at any time other than connection  
establishment is done using SIGALRM to gnutls, which only starttls.el  
seems to do, and there was a report that it's not working for someone  
on Windows.  I have no idea whether openssl supports something like  
that.  And if a protocol does any special wrapping or encoding of the  
TLS-encoded data, I'm guessing it's not going to work well...

Ken

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Jason Rumney]

Ken Raeburn wrote:
> done using SIGALRM to gnutls, which only starttls.el seems to do, and
> there was a report that it's not working for someone on Windows.
That is hardly surprising, since Windows does not use signals.

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Ken Raeburn]

On Jun 8, 2007, at 17:43, Jason Rumney wrote:
> Ken Raeburn wrote:
>> done using SIGALRM to gnutls, which only starttls.el seems to do, and
>> there was a report that it's not working for someone on Windows.
> That is hardly surprising, since Windows does not use signals.

:-)

So, it's a solution for some protocols, but only on some Emacs  
platforms.

The approach of using signals and in-band text for status reporting  
also makes me wonder about synchronization and spoofing issues, but  
like I indicated, I haven't looked into it closely, it may be fine.

Personally, I'm more interested in the GSSAPI and SASL  
possibilities.  And it looks like that's where more work is needed,  
anyways.  I just hope I find some time to *do* something about it... :-(

Ken

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Richard Stallman]

    Some time ago, Eric Marsden created the ipp.el package, see the links:

What does this do?

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Vinicius Jose Latorre]

Richard Stallman wrote:
>     Some time ago, Eric Marsden created the ipp.el package, see the links:
>
> What does this do?
>   

;; The Internet Printing Protocol is intended to replace the LPD
;; protocol for interacting with network printers. It specifies
;; mechanisms for querying the capabilities of a printer, submitting
;; and cancelling jobs, and queue monitoring.
;;
;; You can find out whether a device is IPP-capable by trying to
;; telnet to port 631. If it accepts the connection it probably
;; understands IPP. You then need to discover the path component of
;; the URI, for example by reading the documentation or from a driver
;; program. Tested or reported to work on the following devices:
;;
;;   * Tektronix Phaser 750, with an URI of the form ipp://host:631/
;;     (empty path component)
;;
;;   * HP Laserjet 4000, with a path component of /ipp/port1.
;;
;;   * Xerox Document Centre 460 ST, with empty path component.
;;
;;   * CUPS printer spooler (see <URL:http://www.cups.org/>).
;;
;;
;;
;; Usage: load this package by putting in your ~/.emacs.el
;;
;;    (require 'ipp)
;;
;; then try printing a file using 'M-x ipp-print'. This will prompt
;; you for a file name (which should be in a format understood by the
;; printer, such as Postscript), and the URI of the printer. There are
;; also two functions for querying the capability of the device
;; `ipp-get-attributes' and examining its queue `ipp-get-jobs'. Until
;; I write display code for these functions you will have to call them
;; from the *scratch* buffer with C-j to examine their return value.
;;
;;
;; The IPP network protocol is based on HTTP/1.1 POST requests, using
;; a special "application/ipp" MIME Content-Type. The data is encoded
;; using simple marshalling rules.
;;
;; The Internet Printing Protocol is described in a number of RFCs:
;;   <URL:http://www.faqs.org/rfcs/rfc2565.html>
;;   <URL:http://www.faqs.org/rfcs/rfc2566.html>
;;   <URL:http://www.faqs.org/rfcs/rfc2568.html>
;;
;; and the Printer Working Group maintain a page at
;;
;;   <URL:http://www.pwg.org/ipp/>
;;
;;
;; Eventually it would be nice to modify the Emacs printing API to
;; support this type of direct printing, so that a user could set
;; `ps-printer-name' to "ipp://modern-printer:631/" or
;; "lpd://ancient-printer/queue" (it would be easy to write a package
;; similar to this one implementing the LPD protocol at the network
;; level; the LDP protocol is very simple).

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Jan Djärv]

Vinicius Jose Latorre skrev:
> Richard Stallman wrote:
>>     Some time ago, Eric Marsden created the ipp.el package, see the 
>> links:
>>
>> What does this do?
>>   
> 
> ;; The Internet Printing Protocol is intended to replace the LPD
> ;; protocol for interacting with network printers. It specifies
> ;; mechanisms for querying the capabilities of a printer, submitting
> ;; and cancelling jobs, and queue monitoring.
> ;;
> ;; You can find out whether a device is IPP-capable by trying to
> ;; telnet to port 631. If it accepts the connection it probably
> ;; understands IPP. You then need to discover the path component of
> ;; the URI, for example by reading the documentation or from a driver
> ;; program. Tested or reported to work on the following devices:
> ;;
> ;;   * Tektronix Phaser 750, with an URI of the form ipp://host:631/
> ;;     (empty path component)
> ;;
> ;;   * HP Laserjet 4000, with a path component of /ipp/port1.
> ;;
> ;;   * Xerox Document Centre 460 ST, with empty path component.
> ;;
> ;;   * CUPS printer spooler (see <URL:http://www.cups.org/>).

So basically you would have to define how to reach printers in Emacs as well 
in the OS you use?  Or can this package get that info from the OS?  I know 
cups has a configuration file for that stuff.

	Jan D.

Re: IPP under emacs [was: Re: Post-22.1 development?]

[Richard Stallman]

What advantage is there in making Emacs use IPP directly,
rather than using lpr?

Re: Post-22.1 development?

[Ken Raeburn]

On Jun 7, 2007, at 14:33, Tom Tromey wrote:
> Jan> - Printing, basically Emacs does not have a "modern" print  
> dialog.
>
> I thought the comment here was just about using the wrong program to
> access printing.  But, I'm not an expert here.

On my Mac I've found the most convenient way to print a file the way  
I wanted to from Emacs was to save it, use "M-! open foo.txt" to  
invoke the Mac TextEdit program, and use the standard Mac print  
dialog available there to select the options I wanted.  I'd like to  
see it available directly in Emacs too.  It allows not just for  
selection of which printer, but page layout/selection/ordering  
configuration options, color processing, saving as PDF files, feeding  
PDFs to other programs (at least some of which I think is customized  
by the user, across all programs using the print dialogs), and other  
options, and apparently (at least in when used in the Mail program)  
application-specific options as well.  All the printers I use are  
postscript, but I assume somewhere between the print dialog and the  
printing subsystem, it also deals with appropriate format conversions  
of text and images for the printer selected, whether it understands  
postscript or something else.

If "use Gnome print dialog" means "use the system print dialog, where  
under X we mean Gnome", then I'm all in favor of adding that as an  
option.  (Of course supporting plain lpr still has its place.)


> * Keyring support.  I have some code for this (supporting either the
>   Gnome keyring or a private Emacs-specific one), but I haven't wired
>   it in to all the code in Emacs that uses passwords.

The Mac also has its Keychain system for storing passwords,  
encrypting them, optionally keeping them synchronized across  
machines, prompting the user to confirm that a program is allowed to  
access passwords stored by other programs, etc.

Ken

Re: Post-22.1 development?

[Andreas Schwab]

Ken Raeburn <raeburn@gnu.org> writes:

> If "use Gnome print dialog" means "use the system print dialog, where
> under X we mean Gnome", then I'm all in favor of adding that as an
> option.  (Of course supporting plain lpr still has its place.)

For CUPS there is also xpp, a plain X front end.

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: Post-22.1 development?

[Tom Tromey]

>>>>> "Ken" == Ken Raeburn <raeburn@gnu.org> writes:

>> * Keyring support.  I have some code for this (supporting either the
>> Gnome keyring or a private Emacs-specific one), but I haven't wired
>> it in to all the code in Emacs that uses passwords.

Ken> The Mac also has its Keychain system for storing passwords,
Ken> encrypting them, optionally keeping them synchronized across
Ken> machines, prompting the user to confirm that a program is allowed to
Ken> access passwords stored by other programs, etc.

Yeah.  I think the Gnome keyring was designed after the Mac's.
Anyway, my implementation has two back ends: an Emacs-specific one
that stores a sexp encrypted with GPG, and a Gnome-specific one that
uses a helper program to contact the Gnome keyring.

Adding a helper program for the Mac sounds doable, at least for
someone who knows the Mac.  It would also be interesting to look at
sharing keyring data in Emacs -- using Emacs to convert keyring
formats, upload to a private shared site, whatever.

Would folks prefer to see what I have now, or is a big patch to fix
everything preferable?

Tom

Re: Post-22.1 development?

[Richard Stallman]

    Gmome libraries - If Emacs where to use more Gnome libraries instead of having 
    its own version of some code (session management, font handling, dialogs, 
    configuration, themes, widgets, printing), Emacs would benefit automatically 
    when these libraries are updated.

To eliminate Emacs's own code is out of the question unless we wanted
to make Emacs work ONLY with Gnome.  We could make Emacs use Gnome
facilities optionally, in the cases where it is worth the trouble.

    - Printing, basically Emacs does not have a "modern" print dialog.

I find those print dialogs inconvenient if every print operation has
to use them.  However, it would be nice to be able to use such a
dialog to do print configuration when one wants to do it.

How hard is that to implement?

    - Fonts, AA fonts and respecting the fonts selected by the user in his desktop 
    preferences, including switching fonts on the fly when the user changes his 
    preferences.  A font dialog chooser is missing.

Would it make sense to use that font dialog
to configure faces in Emacs?

    - Session management.  We have that now in 22.1, but Emacs does not restore 
    the frame layout as it was.

Could you explain that failure more clearly?

    Drag and drop - We can't drag text or images from Emacs to another application.

That is definitely a bug.  Have you implemented this?

    Now some of these are being done (AA fonts), some I have patches for (better 
    theme handling, dnd),

What aspect of theme handling have you improved?

Re: Post-22.1 development?

[Jan Djärv]

Richard Stallman skrev:
>     Gmome libraries - If Emacs where to use more Gnome libraries instead of having 
>     its own version of some code (session management, font handling, dialogs, 
>     configuration, themes, widgets, printing), Emacs would benefit automatically 
>     when these libraries are updated.
> 
> To eliminate Emacs's own code is out of the question unless we wanted
> to make Emacs work ONLY with Gnome.  We could make Emacs use Gnome
> facilities optionally, in the cases where it is worth the trouble.
> 
>     - Printing, basically Emacs does not have a "modern" print dialog.
> 
> I find those print dialogs inconvenient if every print operation has
> to use them.  However, it would be nice to be able to use such a
> dialog to do print configuration when one wants to do it.
> 

Usually it is split into two commands, "Print" and Print/Page setup/settings".
 Also is seems that invoking print from the tool bar justs print without
showing any dialog.  What commands we choose to have dialogs or not is of
course up to us.

> How hard is that to implement?

It is some work.  Gtk+ from 2.10 onvards has printing support (ready made
dialogs and such), but the bad news is that the print data is to rendered with
Cairo.  I don't know how hard that is.

> 
>     - Fonts, AA fonts and respecting the fonts selected by the user in his desktop 
>     preferences, including switching fonts on the fly when the user changes his 
>     preferences.  A font dialog chooser is missing.
> 
> Would it make sense to use that font dialog
> to configure faces in Emacs?

Yes, this is quite easy to do.  The only reason it is not in 22.1 is that the
dialog can't filter out non-AA fonts.  Since Emacs 22.1 can't do AA fonts, it
would be confusing to have a dialog where most fonts the user selects doesn't
work.

> 
>     - Session management.  We have that now in 22.1, but Emacs does not restore 
>     the frame layout as it was.
> 
> Could you explain that failure more clearly?

Say I have 2 or more frames when the session exits.  When the session is
started again (i.e. I log in again in Gnome), the frames are not restored,
only one new initial frame is created.

> 
>     Drag and drop - We can't drag text or images from Emacs to another application.
> 
> That is definitely a bug.  Have you implemented this?

Only for text, and only for Gtk+, since there is considerably API support
there.  I don't think images would be very hard in Gtk+ though.  It is a bit
of work to it in pure X11, but not overly much so.

> 
>     Now some of these are being done (AA fonts), some I have patches for (better 
>     theme handling, dnd),
> 
> What aspect of theme handling have you improved?

I can detect if the font changes, but I currently haven't the code to change
the faces, that requires the unicode2 merged in (i.e. AA fonts).  Themes that
changes tool bar icons also changes the corresponding icons in Emacs.  Both
are Gtk+ only.

	Jan D.

Re: Post-22.1 development?

[Stefan Monnier]

>> - Session management.  We have that now in 22.1, but Emacs does not restore 
>> the frame layout as it was.
>> Could you explain that failure more clearly?
> Say I have 2 or more frames when the session exits.  When the session is
> started again (i.e. I log in again in Gnome), the frames are not restored,
> only one new initial frame is created.

Indeed, desktop.el only saves/restores buffers and windows but not frames.
session.el does save/restore frames.


        Stefan

desktop.el/session.el [was: Post-22.1 development?]

[Davis Herring]

> Indeed, desktop.el only saves/restores buffers and windows but not frames.
> session.el does save/restore frames.

Are you referring to http://emacs-session.sourceforge.net/?  I don't see
any mention of frame configurations there, but I only skimmed the site and
the code.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: desktop.el/session.el

[Stefan Monnier]

>> Indeed, desktop.el only saves/restores buffers and windows but not frames.
>> session.el does save/restore frames.

> Are you referring to http://emacs-session.sourceforge.net/?  I don't see
> any mention of frame configurations there, but I only skimmed the site and
> the code.

Yes, looks like I was confused, sorry.


        Stefan

Re: desktop.el/session.el

[Juri Linkov]

>> Indeed, desktop.el only saves/restores buffers and windows but not frames.
>> session.el does save/restore frames.
>
> Are you referring to http://emacs-session.sourceforge.net/?  I don't see
> any mention of frame configurations there, but I only skimmed the site and
> the code.

There is a package for XEmacs - saveframes.el that saves frames in the
~/.emacs_frames file.

But I think that adding support for saving frames/windows to desktop.el
is better than using a separate package.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Post-22.1 development?

[Richard Stallman]

    Yes, this is quite easy to do.  The only reason it is not in 22.1 is that the
    dialog can't filter out non-AA fonts.  Since Emacs 22.1 can't do AA fonts, it
    would be confusing to have a dialog where most fonts the user selects doesn't
    work.

Would adding this dialog support to unicode-2 avoid that problem?

    I can detect if the font changes, but I currently haven't the code to change
    the faces, that requires the unicode2 merged in (i.e. AA fonts).

Likewise, what do you think of implementing this in unicode-2?

Re: Post-22.1 development?

[Jan Djärv]

Richard Stallman skrev:
>     Yes, this is quite easy to do.  The only reason it is not in 22.1 is that the
>     dialog can't filter out non-AA fonts.  Since Emacs 22.1 can't do AA fonts, it
>     would be confusing to have a dialog where most fonts the user selects doesn't
>     work.
> 
> Would adding this dialog support to unicode-2 avoid that problem?
> 
>     I can detect if the font changes, but I currently haven't the code to change
>     the faces, that requires the unicode2 merged in (i.e. AA fonts).
> 
> Likewise, what do you think of implementing this in unicode-2?

I thought unicode2 would be merged rather quickly so I've waited for that so 
the merge would go easier.

	Jan D.

Re: Post-22.1 development?

[Richard Stallman]

    >     - Session management.  We have that now in 22.1, but Emacs does not restore 
    >     the frame layout as it was.
    > 
    > Could you explain that failure more clearly?

    Say I have 2 or more frames when the session exits.  When the session is
    started again (i.e. I log in again in Gnome), the frames are not restored,
    only one new initial frame is created.

That is a bug.  Can someone please step forward to fix it?

Re: Post-22.1 development?

[Richard Stallman]

    I've not cross-posted, but you could ask him how specifically it could be
    improved, e.g., I don't know what he means by printing infrastructure.

Would you like to ask him for more information?

Re: Post-22.1 development?

[Nick Roberts]

Richard Stallman writes:
 >     I've not cross-posted, but you could ask him how specifically it could be
 >     improved, e.g., I don't know what he means by printing infrastructure.
 > 
 > Would you like to ask him for more information?

I think Jan and others have explained the issues sufficiently well.

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

Re: Post-22.1 development?

[Sean O'Rourke]

Let me just put in a word for the Luddites here...

> There's a long thread on fedora-devel (Why isn't emacs
> installed by default)

I have recently experienced similar "integration with a modern
desktop environment" on Mac OS X, where we have the choice
between standard Carbon Emacs and Aquamacs, which tries to behave
more like other Mac applications.  As a longtime Emacs user on
many platforms, I find Aquamacs highly unpleasant.  Many of its
"enhancements," like widespread use of variable-width fonts,
color themes, and pop-up frames, are counterproductive.

I already have a number of lines in my .emacs disabling various
bits of modernization (e.g. tooltip-mode, tool-bar-mode,
blink-cursor-mode, enormous fringes on both sides), and expect
that acceding to Gnome's wishes would just add to this list.
Emacs has its own ways of doing things, and some of us prefer
them, and believe they are better than more "modern"
alternatives.  There are many clear improvements available in
modern environments, such as the option of having anti-aliased
fonts.  But I urge the Emacs developers to be wary of making
changes simply because they make Emacs more "modern," and to
continue to make it possible to disable such changes.

/s

Re: Post-22.1 development?

[Nick Roberts]

 > I have recently experienced similar "integration with a modern
 > desktop environment" on Mac OS X, where we have the choice
 > between standard Carbon Emacs and Aquamacs, which tries to behave
 > more like other Mac applications.  As a longtime Emacs user on
 > many platforms, I find Aquamacs highly unpleasant.  Many of its
 > "enhancements," like widespread use of variable-width fonts,
 > color themes, and pop-up frames, are counterproductive.

When there is choice I don't see how they can be counterproductive;
presumably you can just use Carbon Emacs.

 > I already have a number of lines in my .emacs disabling various
 > bits of modernization (e.g. tooltip-mode, tool-bar-mode,
 > blink-cursor-mode, enormous fringes on both sides),

Enormous is an exaggeration - they're one character wide - and since
you _can_ disable them I see no problem.  I don't see these features
simply as modernisation.  I find the toolbar useful for debugging and
the fringe displays breakpoint icons.  I imagine other people have other
uses for them.

 >                                                     and expect
 > that acceding to Gnome's wishes would just add to this list.
 > Emacs has its own ways of doing things, and some of us prefer
 > them, and believe they are better than more "modern"
 > alternatives.  There are many clear improvements available in
 > modern environments, such as the option of having anti-aliased
 > fonts.  But I urge the Emacs developers to be wary of making
 > changes simply because they make Emacs more "modern," and to
 > continue to make it possible to disable such changes.

I think a bit of flexibility is needed on both sides.  This could get
blown up out of proportion, but I think it should really be a small
issue.

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

Re: Post-22.1 development?

[Sean O'Rourke]

Nick Roberts <nickrob@snap.net.nz> writes:
> When there is choice I don't see how they can be
> counterproductive; presumably you can just use Carbon Emacs.

I do use Carbon Emacs.  But there's always risk in being part of
a silent minority, since the options of interest to such a
minority are more likely to be removed for the sake of
simplicity, etc. (see below).

>  > I already have a number of lines in my .emacs disabling various
>  > bits of modernization (e.g. tooltip-mode, tool-bar-mode,
>  > blink-cursor-mode, enormous fringes on both sides),
>
> Enormous is an exaggeration - they're one character wide - and since
> you _can_ disable them I see no problem. 

True, but IIRC it was only possible to disable the fringes after
a number of people complained.  And "enormous" is relative -- for
me at the time, the fringe made it impossible to have two
non-overlapping, 80-column frames side-by-side with my preferred
font.

> I don't see these features simply as modernisation.  I find the
> toolbar useful for debugging and the fringe displays breakpoint
> icons.  I imagine other people have other uses for them.

I have since re-added a half-width left fringe for debugging
arrows.  I would prefer that it only appear when the arrow was
needed, but I now prefer it to the old text arrow.

> I think a bit of flexibility is needed on both sides.  This
> could get blown up out of proportion, but I think it should
> really be a small issue.

Agreed.  I'm happy as long as I can disable these things in my
.emacs.  I just thought that there are probably quite a few of us
out here who prefer doing things the "old way," that this very
preference is part of what keeps us using Emacs rather than
Eclipse or something, and that it's important to remind everyone
that we exist.

/s

Re: Post-22.1 development?

[Miles Bader]

"Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:
> I just thought that there are probably quite a few of us
> out here who prefer doing things the "old way," that this very
> preference is part of what keeps us using Emacs rather than
> Eclipse or something, and that it's important to remind everyone
> that we exist.

Indeed, though I think there's not much chance of old-timers' interests
being ignored on _this_ list... :-)

BTW, since you mentioned Eclipse, I should note that Eclipse has a
fairly decent "Emacs keybindings" mode:  Though it's only a shallow
emulation layer, it seems a lot more complete than is typical for such
add-on keybinding sets (Emacs' somewhat complex and multi-level bindings
seem beyond the capability of many programs).  This mode was a godsend
when I recently had to do a lot of hacking in Eclipse!

Eclipse makes Emacs look positively light-weight and svelte though... :-}

-Miles

-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish are
breaking up??!  Shit, white people oughtta understand, their job is to GIVE
people the blues, not to get them!    -- George Carlin

Re: Post-22.1 development?

[Alan Mackenzie]

Evening, Sean!

On Thu, Jun 07, 2007 at 03:17:33PM -0700, Sean O'Rourke wrote:
> Nick Roberts <nickrob@snap.net.nz> writes:
> > When there is choice I don't see how they can be
> > counterproductive; presumably you can just use Carbon Emacs.

> I do use Carbon Emacs.  But there's always risk in being part of a
> silent minority, since the options of interest to such a minority are
> more likely to be removed for the sake of simplicity, etc. (see below).

I use Emacs on a 48 line Linux tty.  RMS also uses a tty.  So does Thi,
and I think one or two other Emacs developers.  Uncluttered editing on
Emacs isn't going to disappear any time soon.

> >  > I already have a number of lines in my .emacs disabling various
> >  > bits of modernization (e.g. tooltip-mode, tool-bar-mode,
> >  > blink-cursor-mode, enormous fringes on both sides),

> > Enormous is an exaggeration - they're one character wide - and since
> > you _can_ disable them I see no problem. 

> True, but IIRC it was only possible to disable the fringes after
> a number of people complained.  And "enormous" is relative -- for
> me at the time, the fringe made it impossible to have two
> non-overlapping, 80-column frames side-by-side with my preferred
> font.

The unsuppressability of the fringes (introduced in Emacs 21) was IMAO a
big mistake.  It was one of the very few "enhancements" in Emacs which
couldn't be turned off.  I think it's safe to say that there is
absolutely NO new feature which somebody won't hate.  The help fora were
inundated in 2001 by people wanting to turn off the fringes.

> > I don't see these features simply as modernisation.  I find the
> > toolbar useful for debugging and the fringe displays breakpoint
> > icons.  I imagine other people have other uses for them.
 
> I have since re-added a half-width left fringe for debugging
> arrows.  I would prefer that it only appear when the arrow was
> needed, but I now prefer it to the old text arrow.
 
> > I think a bit of flexibility is needed on both sides.  This
> > could get blown up out of proportion, but I think it should
> > really be a small issue.
 
> Agreed.  I'm happy as long as I can disable these things in my
> .emacs.  I just thought that there are probably quite a few of us
> out here who prefer doing things the "old way," that this very
> preference is part of what keeps us using Emacs rather than
> Eclipse or something, and that it's important to remind everyone
> that we exist.
 
Agreed on all points.

-- 
Alan Mackenzie.

48 line console [was Re: Post-22.1 development]?

[Nick Roberts]

 > I use Emacs on a 48 line Linux tty.  RMS also uses a tty.  So does Thi,
 > and I think one or two other Emacs developers.  Uncluttered editing on
 > Emacs isn't going to disappear any time soon.

I realise it's a bit off-topic, but just how do you set up a 48 line console?
I'd like to just use the console for Emacs more often, but getting just 24/25
lines can be a real killer.

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

Re: 48 line console

[Thien-Thi Nguyen]

() Nick Roberts <nickrob@snap.net.nz>
() Fri, 8 Jun 2007 11:06:18 +1200

   I realise it's a bit off-topic, but just how do you
   set up a 48 line console?  I'd like to just use the
   console for Emacs more often, but getting just 24/25
   lines can be a real killer.

in /boot/grub/menu.lst, i see:

# kopt=root=/dev/hda2 ro vga=0x307

vga=0x307 results in 64 lines by 160 characters on a
1280x1024 pixel monitor.  see vsafb.txt for more info.

thi

Re: 48 line console

[Nick Roberts]

 > in /boot/grub/menu.lst, i see:
 > 
 > # kopt=root=/dev/hda2 ro vga=0x307
 > 
 > vga=0x307 results in 64 lines by 160 characters on a
 > 1280x1024 pixel monitor.  see vsafb.txt for more info.

I think that might be the problem.  When I used vga=ask, my monitor listed
about eight choices but only actually provided about three, the maximum number
of lines being about thirty.

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

Re: 48 line console

[Thien-Thi Nguyen]

() Nick Roberts <nickrob@snap.net.nz>
() Fri, 8 Jun 2007 13:34:31 +1200

    > vga=0x307 results in 64 lines by 160 characters on a
    > 1280x1024 pixel monitor.  see vsafb.txt for more info.

   I think that might be the problem.  When I used vga=ask, my monitor
   listed about eight choices but only actually provided about three,
   the maximum number of lines being about thirty.

it's a problem until you read vesafb.txt (sorry for the typo above).
have you done that?

thi

Re: 48 line console

[Nick Roberts]

 >     > vga=0x307 results in 64 lines by 160 characters on a
 >     > 1280x1024 pixel monitor.  see vsafb.txt for more info.
 > 
 >    I think that might be the problem.  When I used vga=ask, my monitor
 >    listed about eight choices but only actually provided about three,
 >    the maximum number of lines being about thirty.
 > 
 > it's a problem until you read vesafb.txt (sorry for the typo above).
 > have you done that?

I looked at svga.txt, vesafb.txt seems to say similar things.  It looks like my
monitor doesn't support more than thirty lines.  Perhaps you can give me more
specific advice (but not just "feel the force, Luke"!).

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

Re: 48 line console

[Thien-Thi Nguyen]

() Nick Roberts <nickrob@snap.net.nz>
() Fri, 8 Jun 2007 20:59:01 +1200

    > it's a problem until you read vesafb.txt (sorry for the typo
    > above).  have you done that?

   I looked at svga.txt, vesafb.txt seems to say similar things.
   It looks like my monitor doesn't support more than thirty
   lines.  Perhaps you can give me more specific advice (but not
   just "feel the force, Luke"!).

ok how about this: read, understand and try out some of the
settings documented in vesafb.txt.  have you done that?

i don't suggest feeling the force.  instead, i suggest action
(informed experimentation).  if you prefer not to act, i have no
more suggestions.

thi

Re: 48 line console [was Re: Post-22.1 development]?

[Alan Mackenzie]

Hi, Nick!

On Fri, Jun 08, 2007 at 11:06:18AM +1200, Nick Roberts wrote:
>  > I use Emacs on a 48 line Linux tty.  RMS also uses a tty.  So does
>  > Thi, and I think one or two other Emacs developers.  Uncluttered
>  > editing on Emacs isn't going to disappear any time soon.

> I realise it's a bit off-topic, but just how do you set up a 48 line
> console?  I'd like to just use the console for Emacs more often, but
> getting just 24/25 lines can be a real killer.
 
For anybody else who's reading, you've got to compile "frame buffer"
into your (Linux) kernel.  With "make menuconfig" (called from the
directory kernel-source-2.6.n, or the like), go down this branch of the
menu structure:
    <Device Drivers>/<Graphics Support>
, then enable
    <Support for frame buffer devices>
, then click on the right video card.  Don't forget "Logo
Configuration", which is the kernel hackers' secret code word for Tux
the penguin.  :-)

A tip: rather than configuring your kernel from scratch, extract the
current config from your running kernel with 
    gunzip -c /proc/config.gz > .config

Having compiled your new kernel and got it to boot up (no mean
achievement, the first time you manage it - don't be deluded by the
hordes of smart Alecs on the Web telling you how easy it is and how it
can be done "in half an hour".  It hurts. ;-), you have to give it a
parameter like

    video=matroxfb:vesa:791,

but I've forgotten exactly what that means, it was so long ago.  The
documentation is under ..../kernel-2.6.n/Documentation/fb/.  My lilo
stanza in its entirety looks like this

image= /home/acm/kernel-source-2.6.8/arch/i386/boot/bzImage
  label = Deb-Sarge-NW
  read-only
  append = "root=/dev/hdg6 video=matroxfb:vesa:791 ide3=0xd800,0xdc02,11 parport=0x378,7 lp=parport0"
  root = /dev/hdg6
  vga = 0x030A

> -- Nick

-- 
Alan.

Re: Post-22.1 development?

[David Reitter]

On 7 Jun 2007, at 20:48, Sean O'Rourke wrote:

> I have recently experienced similar "integration with a modern
> desktop environment" on Mac OS X, where we have the choice
> between standard Carbon Emacs and Aquamacs, which tries to behave
> more like other Mac applications.  As a longtime Emacs user on
> many platforms, I find Aquamacs highly unpleasant.  Many of its
> "enhancements," like widespread use of variable-width fonts,
> color themes, and pop-up frames, are counterproductive.

I generally recommend Carbon Emacs to people who have been using  
Emacs for a long time. Even though we have a fair amount of switchers  
who come from the "Emacs way" of doing things and are now quite happy  
to alter what they are used to, it appears that Aquamacs gets a lot  
of users who wouldn't like to use Emacs otherwise, and it doesn't  
attract that many experienced Emacs users like you.

Not giving in to demands to make it more "Emacs" like and less "Mac"  
like is part of the concept - we can't please everyone. And besides,  
there's a perfectly nice and very Emacs-like Emacs (Carbon Emacs!)  
available for the platform.

I wouldn't want the GNU Emacs to be "modernized" with respect to the  
UI where the changes would annoy long-time users. However, I would  
want it to offer some of these modernizations as an option in 23. For  
example:

- better support of variable-width fonts
- better support of editing in variable-size windows (e.g.  
replacement or addendum to longlines-mode)
- optional replacement of windows inside frames with multiple frames   
(*)
- toolbars using the system's toolkit rather than something homegrown
- toolkit based dialogs with a redesigned customization hierarchy  
rather than customization buffers

This would make it a lot easier for new users to use Emacs (on all  
platforms).

The extension marked with (*) is actually implemented in Aquamacs  
using a mode called `one-buffer-one-frame-mode'. This is a hack that  
I'd like to rewrite as a patch to the Emacs sources so that it can  
eventually be offered as a standard option. 

Re: Post-22.1 development?

[Sean O'Rourke]

David Reitter <david.reitter@gmail.com> writes:
> I generally recommend Carbon Emacs to people who have been using
> Emacs for a long time.

Right, and although there's something to be said for doing things
à la Emacs, I'm gradually accepting that it's not possible to
convert everyone to the old-school point of view. ;)

> - better support of variable-width fonts

Absolutely, e.g. for reading info pages.  It should be little
more work to do this agreeably than to do it at all.

> - optional replacement of windows inside frames with multiple
>   frames

This, on the other hand, seems harder to get right without
disturbing people's habits.  Perhaps adding more customization to
pop-to-buffer and display-buffer is the way to go?

> - toolbars using the system's toolkit rather than something homegrown
> - toolkit based dialogs with a redesigned customization hierarchy
> rather than customization buffers

As long as they're optional.  Figuring out the interaction
between `custom-set-variables' and `setq' wasn't my idea of a
good time, and I'd rather not do something similar for
`gui-save-dialog-options'.  :)

/s

Re: Post-22.1 development?

[David Reitter]

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

On 7 Jun 2007, at 23:42, Sean O'Rourke wrote:

> Right, and although there's something to be said for doing things
> à la Emacs, I'm gradually accepting that it's not possible to
> convert everyone to the old-school point of view. ;)

Absolutely. If all my other applications used the same interaction  
paradigms, it would be acceptable. Humans are very adaptive (i.e.  
intelligent) animals, but we still don't like to switch modes.

I'd love to see an "Emacs component" as the plug-in editor in all  
editing fields in GUI applications, like as the editor in the e-mail  
client that I am using right now. Having a programmable editor that  
runs just inside other applications is what I'd much rather have than  
a multitude of applications running inside the programmable editor.

>> - better support of variable-width fonts
>
> Absolutely, e.g. for reading info pages.  It should be little
> more work to do this agreeably than to do it at all.

I'd actually like to use such fonts to write text. But they really  
don't play well with longlines-mode.
And I had to write a number of extra functions to be able to move the  
cursor up and down in between lines with variable-width fonts. The  
plain GNU Emacs as it comes just doesn't support that, even though  
variable-width fonts have been added a long time ago.

>> - optional replacement of windows inside frames with multiple
>>   frames
>
> This, on the other hand, seems harder to get right without
> disturbing people's habits.  Perhaps adding more customization to
> pop-to-buffer and display-buffer is the way to go?

Yes, difficult indeed, and `one-buffer-one-frame-mode' indeed works  
by changing the display function (amongst various other things).



[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 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: Post-22.1 development?

[Mathias Dahl]

> I'd love to see an "Emacs component" as the plug-in editor in all
> editing fields in GUI applications, like as the editor in the e-mail
> client that I am using right now. Having a programmable editor that
> runs just inside other applications is what I'd much rather have than
> a multitude of applications running inside the programmable editor.

Amen! :)

Re: Post-22.1 development?

[Richard Stallman]

    I'd love to see an "Emacs component" as the plug-in editor in all =20
    editing fields in GUI applications, like as the editor in the e-mail =20
    client that I am using right now. Having a programmable editor that =20
    runs just inside other applications is what I'd much rather have than =20=

This is something I've wished for ever since Emacs started working
with X Windows.  If someone would like to implement this, either at
the general X level or based on Gnome, it would be really nice.

Re: Post-22.1 development?

[csant]

On Fri, 08 Jun 2007 16:24:00 +0200, Richard Stallman <rms@gnu.org> wrote:

>     I'd love to see an "Emacs component" as the plug-in editor

> If someone would like to implement this, either at
> the general X level or based on Gnome, it would be really nice.

If this would not be too heavily Gnome (GTK) dependant, it could be used  
equally well by other applications that use different toolkits and run in  
different desktop environments.  KDE (and Qt) is typically another  
widespread environment...

/c

Re: Post-22.1 development?

[Jan Djärv]

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

csant skrev:
> On Fri, 08 Jun 2007 16:24:00 +0200, Richard Stallman <rms@gnu.org> wrote:
> 
>>     I'd love to see an "Emacs component" as the plug-in editor
> 
>> If someone would like to implement this, either at
>> the general X level or based on Gnome, it would be really nice.
> 
> If this would not be too heavily Gnome (GTK) dependant, it could be used
> equally well by other applications that use different toolkits and run
> in different desktop environments.  KDE (and Qt) is typically another
> widespread environment...

It is easy to do with GtkPlug/GtkSocket.  The XEmbed protocol is used so I
guess KDE/Qt can embed Emacs also.  But it is easy in Gtk+ Emacs only.  I've
attached a screen shot of a simple demo.  Note the two menu bars.  Emacs is
running as an separate process.

	Jan D.

[-- Attachment #2: plugtst.png --]
[-- Type: image/png, Size: 23367 bytes --]

[-- 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: Post-22.1 development?

[YAMAMOTO Mitsuharu]

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

>>>>> On Thu, 7 Jun 2007 23:25:50 +0100, David Reitter <david.reitter@gmail.com> said:

> I wouldn't want the GNU Emacs to be "modernized" with respect to the
> UI where the changes would annoy long-time users. However, I would
> want it to offer some of these modernizations as an option in
> 23. For example:

> - toolbars using the system's toolkit rather than something
> homegrown

The GTK+ port already uses its toolkit toolbars.  The Cocoa/GNUstep
port at http://emacs-app.sourceforge.net/ also uses them and I think
it will be available for Emacs 23.

For the Carbon port, some experimental code is working on my side, and
it will be installed to the trunk when a few minor problems get fixed.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: carbon-toolbar.png --]
[-- Type: image/png, Size: 21641 bytes --]

[-- 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: Post-22.1 development?

[Nick Roberts]

Chong Yidong writes:
 > Now Emacs 22.1 is released (for those who don't read info-gnu-emacs,
 > see http://permalink.gmane.org/gmane.emacs.announce/11 ), what is the
 > development plan for the trunk and the branch?

Looking at feedback on the Internet about Emacs 22, I think:

1) We should immediately make GTK the default build for both the trunk and the
   branch to bring it more in line with other desktop applications.

2) The branch of CVS Emacs, which supports antialiased fonts  (unicode-xft?
   XFT_JHD_BRANCH?) should also be merged into the trunk for the same
   reason.


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

Re: Post-22.1 development?

[David Kastrup]

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

> Chong Yidong writes:
>  > Now Emacs 22.1 is released (for those who don't read info-gnu-emacs,
>  > see http://permalink.gmane.org/gmane.emacs.announce/11 ), what is the
>  > development plan for the trunk and the branch?
>
> Looking at feedback on the Internet about Emacs 22, I think:
>
> 1) We should immediately make GTK the default build for both the
> trunk and the branch to bring it more in line with other desktop
> applications.

I had argued for doing this for 22.1 already.  I am, however, not sure
whether we should really do significant changes like that in the 22.x
release series.

If I remember correctly, one of the reasons not to switch was that we
had quite mixed reports about what happened with multi-tty, at least
with some Gtk+ versions.

> 2) The branch of CVS Emacs, which supports antialiased fonts
> (unicode-xft?  XFT_JHD_BRANCH?) should also be merged into the trunk
> for the same reason.

I guess it is clear that this is no 22.x material.

-- 
David Kastrup

Re: Post-22.1 development?

[Kenichi Handa]

In article <18021.14832.773611.296335@kahikatea.snap.net.nz>, Nick Roberts <nickrob@snap.net.nz> writes:

> 2) The branch of CVS Emacs, which supports antialiased fonts  (unicode-xft?
>    XFT_JHD_BRANCH?) should also be merged into the trunk for the same
>    reason.

emacs-unicode-2 branch already contains antialiased font
support.

---
Kenichi Handa
handa@m17n.org

Re: Post-22.1 development?

[Nick Roberts]

 > > 2) The branch of CVS Emacs, which supports antialiased fonts  (unicode-xft?
 > >    XFT_JHD_BRANCH?) should also be merged into the trunk for the same
 > >    reason.
 > 
 > emacs-unicode-2 branch already contains antialiased font
 > support.

OK, I didn't realise that.  Probably an ignorant question, but are they
related features?

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

Re: Post-22.1 development?

[Kenichi Handa]

In article <18021.53381.245926.17150@kahikatea.snap.net.nz>, Nick Roberts <nickrob@snap.net.nz> writes:

> > 2) The branch of CVS Emacs, which supports antialiased fonts  (unicode-xft?
> >    XFT_JHD_BRANCH?) should also be merged into the trunk for the same
> >    reason.
> 
> emacs-unicode-2 branch already contains antialiased font
> support.

> OK, I didn't realise that.  Probably an ignorant question, but are they
> related features?

What do you mean by "they"?  "Unicode support" and
"antialiazed font support"?  The latter is just a side
effect of supporting client side fonts (e.g. Xft/Freetype).
And support for client side fonts is surely necessary for a
good support of Unicode because many Asian scripts require
OpenType fonts (available only by client side fonts).

---
Kenichi Handa
handa@m17n.org

Re: Post-22.1 development?

[Richard Stallman]

    Looking at feedback on the Internet about Emacs 22, I think:

    1) We should immediately make GTK the default build for both the trunk and the
       branch to bring it more in line with other desktop applications.

We certainly should not do this for the branch.
I am not sure that change is a good idea in the trunk.

What does the feedback consist of?  Users saying they wish the GTK
build were the default?  I believe there are some.  However, how many
users said nothing because they are happy that GTK is NOT the default?

A half-way change, to make use of GTK the default when GTK dev libs
are present, might be good.

Re: Post-22.1 development?

[Jason Rumney]

Richard Stallman wrote:
> A half-way change, to make use of GTK the default when GTK dev libs
> are present, might be good.
>   

That's not a halfway change, its the full change! I don't think anyone
was suggesting that we require GTK to build Emacs.

Re: Post-22.1 development?

[Richard Stallman]

    > A half-way change, to make use of GTK the default when GTK dev libs
    > are present, might be good.
    >   

    That's not a halfway change, its the full change! I don't think anyone
    was suggesting that we require GTK to build Emacs.

For the trunk, please make GTK build the default
if the GTK development libraries are installed.

Re: Post-22.1 development?

[Nick Roberts]

 >     Looking at feedback on the Internet about Emacs 22, I think:
 > 
 >     1) We should immediately make GTK the default build for both the trunk
 >        and the branch to bring it more in line with other desktop
 >        applications.
 > 
 > We certainly should not do this for the branch.
 > I am not sure that change is a good idea in the trunk.

I thought that we almost did this for the release (when I argued against it).
Now that 22.1 is out, users will always have the option to downgrade, as well
as not using the default build if they are building themselves.  Also there is
some breathing space to iron out any problems that there might be.  Being
realistic about timescales, changes on the trunk won't get released for a long
time.

 > What does the feedback consist of?  Users saying they wish the GTK
 > build were the default?  I believe there are some.  However, how many
 > users said nothing because they are happy that GTK is NOT the default?

There's a long thread on fedora-devel (Why isn't emacs installed by default)
Generally, the impression I get is that Emacs is gradually being marginalised.
I think we should take steps to reverse that.

 > A half-way change, to make use of GTK the default when GTK dev libs
 > are present, might be good.

This is what making it the default means, isn't it?

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

Re: Post-22.1 development?

[Richard Stallman]

     > We certainly should not do this for the branch.
     > I am not sure that change is a good idea in the trunk.

    I thought that we almost did this for the release (when I argued against it).

I don't want to make such major changes in Emacs 22.2.

Re: Post-22.1 development?

[Neal Becker]

I love antialiased fonts!

I've been building from cvs trunk using:
 --with-gtk --enable-font-backend --with-xft

Which branch(es) should I be using if I want a maximally stable emacs but
with antialiased fonts?

Re: Post-22.1 development?

[David House]

On 06/06/07, Neal Becker <ndbecker2@gmail.com> wrote:
> Which branch(es) should I be using if I want a maximally stable emacs but
> with antialiased fonts?

At this point, I believe unicode-2 is your best bet. The plan is to
merge that into the trunk, though, so that Emacs 23 will contain
support for XFT fonts by default. That's a while off yet, however.

-- 
-David House, dmhouse@gmail.com

Re: Post-22.1 development?

[Jay Belanger]

Chong Yidong <cyd@stupidchicken.com> writes:
...
> Also, is it "open season" on checkins to the trunk, or do we want to
> complete the unicode merge first?

I probably missed it among the many messages in this thread, but under
what conditions (after the unicode or multi-tty merges?) will the
trunk be open for non-trivial, non-bugfix changes?

Jay