Carbon port and multi-tty

Carbon port and multi-tty

[Chong Yidong]

This concerns the recent drama over the Carbon port and multi-tty.

As I understand, in the CVS tree the Carbon port is unmaintained, since
Yamamoto Mitsuharu has declined to continue supporting Carbon for Emacs
23 and no other developer has offered to take on his role.  We can't let
the lack of a maintainer for a non-free software platform stall Emacs
development indefinitely.  Thus, merging multi-tty into the trunk was
the correct decision, even if we couldn't---and apparently still
can't---find a developer to make it work properly on Carbon.  I'm glad
that Dan at least tried to work on it, even if he didn't manage to
finish the job.  If you're disturbed by the remaining problems on
Carbon, please try working on a fix instead of complaining.

Regarding the Carbon changes to the Emacs 22 branch: Yamamoto Mitsuharu
is actively maintaining the Carbon-specific code in the branch, and as a
platform maintainer he has considerable discretion to make
platform-specific changes.  If he says that his changes won't pose a
problem in the event of a security release from the branch, that's fine
by me.  If anyone has problems with a specific change has made to the
branch, please pose it to him, or to the list.

Thanks.

Re: Carbon port and multi-tty

[Ted Zlatanov]

On Tue, 06 May 2008 12:55:28 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> This concerns the recent drama over the Carbon port and multi-tty.
CY> As I understand, in the CVS tree the Carbon port is unmaintained, since
CY> Yamamoto Mitsuharu has declined to continue supporting Carbon for Emacs
CY> 23 and no other developer has offered to take on his role.  We can't let
CY> the lack of a maintainer for a non-free software platform stall Emacs
CY> development indefinitely.  Thus, merging multi-tty into the trunk was
CY> the correct decision, even if we couldn't---and apparently still
CY> can't---find a developer to make it work properly on Carbon.  I'm glad
CY> that Dan at least tried to work on it, even if he didn't manage to
CY> finish the job.  If you're disturbed by the remaining problems on
CY> Carbon, please try working on a fix instead of complaining.

I thought one of the reasons the Carbon port is unmaintained in CVS is
that the Emacs.app code, which uses Cocoa, is likely to replace it (at
least that was my understanding from the many discussions and the
impression I got from Stefan Monnier's message linked below).  See:

http://news.gmane.org/find-root.php?message_id=%3cjwvk5kjijh6.fsf%2dmonnier%2bemacs%40gnu.org%3e
http://news.gmane.org/find-root.php?group=gmane.emacs.devel&article=91230

If this is incorrect, please let me know.

Ted

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 06 May 2008 12:55:28 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> I'm glad that Dan at least tried to work on it, even if he didn't
> manage to finish the job.

I would be too if it didn't contain the changes that are unrelated to
multi-tty.  Actually I appreciated him first because I didn't notice
such changes immediately and I took it for granted that he was at
least familiar enough with multi-tty to do that job even if he was not
familiar with Carbon.

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

Re: Carbon port and multi-tty

[Stefan Monnier]

>> I'm glad that Dan at least tried to work on it, even if he didn't
>> manage to finish the job.

> I would be too if it didn't contain the changes that are unrelated to
> multi-tty.

This is simply not true.  Maybe some of the changes appear unrelated
because you know they should be done differently, but I'm pretty sure
Dan's changes had no other intention than "do the bare minimum to get it
to compile&start".


        Stefan

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 06 May 2008 21:58:55 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>> I'm glad that Dan at least tried to work on it, even if he didn't
>>> manage to finish the job.

>> I would be too if it didn't contain the changes that are unrelated
>> to multi-tty.

> This is simply not true.  Maybe some of the changes appear unrelated
> because you know they should be done differently, but I'm pretty
> sure Dan's changes had no other intention than "do the bare minimum
> to get it to compile&start".

I suspect so too.  I mean, he did the job that is similar to
"forward-line" -> "next-line".

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

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 May 2008 11:36:29 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I suspect so too.  I mean, he did the job that is similar to
> "forward-line" -> "next-line".

Sorry, "next-line" -> "forward-line".

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

Re: Carbon port and multi-tty

[Stefan Monnier]

>>> I would be too if it didn't contain the changes that are unrelated
>>> to multi-tty.

>> This is simply not true.  Maybe some of the changes appear unrelated
>> because you know they should be done differently, but I'm pretty
>> sure Dan's changes had no other intention than "do the bare minimum
>> to get it to compile&start".

> I suspect so too.  I mean, he did the job that is similar to
> "forward-line" -> "next-line".

With one major difference: his patch did not make anything worse.
If anything it helped since it turned a 100% non-functional code into
code that at least works in some limited way.  If you can do better,
show us.  Otherwise, please stop complaining,


        Stefan

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 06 May 2008 23:13:37 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>>> I would be too if it didn't contain the changes that are
>>>> unrelated to multi-tty.

>>> This is simply not true.  Maybe some of the changes appear
>>> unrelated because you know they should be done differently, but
>>> I'm pretty sure Dan's changes had no other intention than "do the
>>> bare minimum to get it to compile&start".

>> I suspect so too.  I mean, he did the job that is similar to
>> "forward-line" -> "next-line".

> With one major difference: his patch did not make anything worse.

It actually introduced a bug in the part that is unrelated to
multi-tty.

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

Re: Carbon port and multi-tty

[Nick Roberts]

 > > With one major difference: his patch did not make anything worse.
 > 
 > It actually introduced a bug in the part that is unrelated to
 > multi-tty.

You've already made this point before (or ones like it).  You appear to be a
brilliant programmer but this is starting to become destructive.

On a more pragmatic level, why not propose some peer review/approval process
for certain categories of change.  I have already suggested something along
these lines and I still think the lack of any kind of charter will result in
similar altercations in the future.

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

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 7 May 2008 15:52:15 +1200, Nick Roberts <nickrob@snap.net.nz> said:

>> > With one major difference: his patch did not make anything worse.
>> 
>> It actually introduced a bug in the part that is unrelated to
>> multi-tty.

> You've already made this point before (or ones like it).  You appear
> to be a brilliant programmer but this is starting to become
> destructive.

I don't find myself a brilliant programmer, but I think I'm careful
enough not to touch the part I'm not familiar with.

Is it too much to expect similar kind of carefulness to those who have
a write access?  Are those who are defending him encouraging literal,
superficial changes without understanding the meanings?

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

Re: Carbon port and multi-tty

[Stefan Monnier]

> Are those who are defending him encouraging literal,
> superficial changes without understanding the meanings?

I make such changes every day.  Hell, I rarely do anything else,


        Stefan

Re: Carbon port and multi-tty

[David Kastrup]

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

>  > > With one major difference: his patch did not make anything worse.
>  > 
>  > It actually introduced a bug in the part that is unrelated to
>  > multi-tty.
>
> You've already made this point before (or ones like it).  You appear
> to be a brilliant programmer but this is starting to become
> destructive.

Is "appear to be a brilliant programmer" a remark about social skills?
Anyway, I disagree on the "starting" bit.

I have never used a killfile on emacs-devel, but I am seriously starting
to consider it.

It is really, really enough.  I told Dan that he would make a better
impression by just dropping out of this "conversation".  I am at a loss
of words concerning Yamamoto, though, since I can't see how to make it
more obvious to him how he is coming across than has been done already.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Carbon port and multi-tty

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 7 May 2008 15:52:15 +1200
> Cc: Chong Yidong <cyd@stupidchicken.com>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> On a more pragmatic level, why not propose some peer review/approval process
> for certain categories of change.  I have already suggested something along
> these lines and I still think the lack of any kind of charter will result in
> similar altercations in the future.

Such suggestions were made many times in the past, but they never
flew.

Re: Carbon port and multi-tty

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Tue, 06 May 2008 23:13:37 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:
  > 
  > >>>> I would be too if it didn't contain the changes that are
  > >>>> unrelated to multi-tty.
  > 
  > >>> This is simply not true.  Maybe some of the changes appear
  > >>> unrelated because you know they should be done differently, but
  > >>> I'm pretty sure Dan's changes had no other intention than "do the
  > >>> bare minimum to get it to compile&start".
  > 
  > >> I suspect so too.  I mean, he did the job that is similar to
  > >> "forward-line" -> "next-line".
  > 
  > > With one major difference: his patch did not make anything worse.
  > 
  > It actually introduced a bug in the part that is unrelated to
  > multi-tty.

Please show us the exact bug, and I'll fix it or back out the change.
Had this information been available, this would have happened a year ago.

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 06 May 2008 21:28:37 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

>> It actually introduced a bug in the part that is unrelated to
>> multi-tty.

> Please show us the exact bug, and I'll fix it or back out the
> change.  Had this information been available, this would have
> happened a year ago.

The change corresponds to this entry:

2007-08-29  Dan Nicolaescu  <dann@ics.uci.edu>

	(Fx_create_frame): Fix doc string.  Rename the parameter.  Set the
	frame parameters following what is done in X11 and w32.

Actually the comment was not right.  This has changed the Mac code
from what is done in X11 to what is done in W32.

The bug introduced by this change is mentioned here:
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html

And the following change is totally unrelated to multi-tty.

	(mac_window): Add 2 new parameters for consistency with other systems.

Again, the comment was not right.  The X11 counterpart (x_window) has
several versions, one of which has only one argument as in the
original mac_window.

There might be others, but the above is what I could find.

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

Re: Carbon port and multi-tty

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Tue, 06 May 2008 21:28:37 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > >> It actually introduced a bug in the part that is unrelated to
  > >> multi-tty.
  > 
  > > Please show us the exact bug, and I'll fix it or back out the
  > > change.  Had this information been available, this would have
  > > happened a year ago.
  > 
  > The change corresponds to this entry:
  > 
  > 2007-08-29  Dan Nicolaescu  <dann@ics.uci.edu>
  > 
  > 	(Fx_create_frame): Fix doc string.  Rename the parameter.  Set the
  > 	frame parameters following what is done in X11 and w32.
  > 
  > Actually the comment was not right.  This has changed the Mac code
  > from what is done in X11 to what is done in W32.

You mean the ChangeLog entry?  I used both X11 and w32 as inspiration.
There was an incorrect comment talking about an inexistent ALIST
parameter that the original patch fixed.

  > The bug introduced by this change is mentioned here:
  > http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html

OK, a 1 line change (in a ~1000 lines patch) that you seemed to have
known about for a while.

Interesting choice of action: raising all this hell instead of just
fixing it.  Fine, if your judgment tells you such a behavior is wise...

  > And the following change is totally unrelated to multi-tty.
  > 
  > 	(mac_window): Add 2 new parameters for consistency with other systems.
  > 
  > Again, the comment was not right.  The X11 counterpart (x_window) has
  > several versions, one of which has only one argument as in the
  > original mac_window.

This has not functional value, just esthetic, it has zero effect on
functionality.  I changed it anyway.

  > There might be others, but the above is what I could find.

Please find them, if they actually exist.

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 06 May 2008 22:55:12 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

>> The bug introduced by this change is mentioned here:
>> http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html

> OK, a 1 line change (in a ~1000 lines patch) that you seemed to have
> known about for a while.

1-line change can introduce a nasty bug as actually seen in this case.
And this could be easily avoided by not changing the part that is
unrelated to multi-tty.

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

Re: Carbon port and multi-tty

[David Kastrup]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Tue, 06 May 2008 22:55:12 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
>
>>> The bug introduced by this change is mentioned here:
>>> http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html
>
>> OK, a 1 line change (in a ~1000 lines patch) that you seemed to have
>> known about for a while.
>
> 1-line change can introduce a nasty bug as actually seen in this case.
> And this could be easily avoided by not changing the part that is
> unrelated to multi-tty.

Please try improving your signal-to-annoyance ratio.  We can't afford to
have a 20+ posting fallout over every single-line bug.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 May 2008 08:40:03 +0200, David Kastrup <dak@gnu.org> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>>>>>> On Tue, 06 May 2008 22:55:12 -0700, Dan Nicolaescu
>>>>>>> <dann@ics.uci.edu> said:
>> 
>>>> The bug introduced by this change is mentioned here:
>>>> http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html
>> 
>>> OK, a 1 line change (in a ~1000 lines patch) that you seemed to
>>> have known about for a while.
>> 
>> 1-line change can introduce a nasty bug as actually seen in this
>> case.  And this could be easily avoided by not changing the part
>> that is unrelated to multi-tty.

> Please try improving your signal-to-annoyance ratio.  We can't
> afford to have a 20+ posting fallout over every single-line bug.

I really deeply apologize about any annoyances, and I'll stop here.
But please understand that what I wanted to say is not about this
particular single-line bug, but about mixing unrelated changes.

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

Re: Carbon port and multi-tty

[Stephen J. Turnbull]

YAMAMOTO Mitsuharu writes:

 > But please understand that what I wanted to say is not about this
 > particular single-line bug, but about mixing unrelated changes.

Just get used to it; it's a part of life in distributed development of
a project as large as Emacs, unless you're willing to do a *lot* more
review than most people.  Heck, I can't even enforce compiling one's
changes before committing.

Re: Carbon port and multi-tty

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> YAMAMOTO Mitsuharu writes:
>
>  > But please understand that what I wanted to say is not about this
>  > particular single-line bug, but about mixing unrelated changes.
>
> Just get used to it; it's a part of life in distributed development of
> a project as large as Emacs, unless you're willing to do a *lot* more
> review than most people.  Heck, I can't even enforce compiling one's
> changes before committing.

It is not like we are applying the final layers of polish here.  We are
talking about Emacs 23 development.  I have to say that people who
_whine_ about other developers' work to support _their_ platform are not
on my list of favorites.  Large amounts of work for some programs go
into supporting things like compatibility with Windows or XEmacs or
similar where the developers themselves are not actually using the
platform in question.

Things like that often prove to be a time sink.  And being beraved for
good-faith efforts that would not have happened otherwise doesn't make
that more pleasant.

I can't really blame developers who decide to cut their losses in such a
situation, even though I find it sad.

Fortunately, with Emacs we have "native" developers for most platforms.
It appears that we don't have any with Carbon.  So it might make sense
for Carbon developers not willing to invest any time of theirselves to
remain constructive and polite, even more so than with platforms for
which active developers have a vested interest.

-- 
David Kastrup

Re: Carbon port and multi-tty

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Wed, 07 May 2008 10:42:15 +0200
> Cc: Chong Yidong <cyd@stupidchicken.com>, Dan Nicolaescu <dann@ics.uci.edu>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>,
> 	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, emacs-devel@gnu.org
> 
> I have to say that people who
> _whine_ about other developers' work to support _their_ platform are not
> on my list of favorites.  Large amounts of work for some programs go
> into supporting things like compatibility with Windows or XEmacs or
> similar where the developers themselves are not actually using the
> platform in question.
> 
> Things like that often prove to be a time sink.  And being beraved for
> good-faith efforts that would not have happened otherwise doesn't make
> that more pleasant.
> 
> I can't really blame developers who decide to cut their losses in such a
> situation, even though I find it sad.
> 
> Fortunately, with Emacs we have "native" developers for most platforms.
> It appears that we don't have any with Carbon.  So it might make sense
> for Carbon developers not willing to invest any time of theirselves to
> remain constructive and polite, even more so than with platforms for
> which active developers have a vested interest.

Politeness is a two-way street.  If you are being impolite to others
(e.g., by saying that supporting their platforms is a ``time sink''
for you), don't expect too much politeness in response.

Being more active then others gives one credit for one's contribution,
but it doesn't make one less responsible for the consequences of one's
contributions.  In fact, IMO it makes one _more_ responsible, since if
you are more active, you have more resources to make sure your work's
quality.

On a more broad scale, what good is Free Software with its underlying
social agenda, if all we do is care about our own platforms, and ``cut
our losses'' about all the rest?

Re: Carbon port and multi-tty

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> On a more broad scale, what good is Free Software with its underlying
> social agenda, if all we do is care about our own platforms, and ``cut
> our losses'' about all the rest?

The GNU project's goal is about giving its users an environment where
they don't need to compromise about helping others.  Proprietary
platforms don't meet that objective.  Supporting them comes at a cost.
If this comes at considerable expense of support for free platforms, the
priorities are mixed up.

If the users and in particular the developers of other platforms don't
care enough about their own platform to invest any actual work of their
own, it is nonsensical to bend over backwards to do it for them.

If they don't care enough, why should I when I am not even affected?

-- 
David Kastrup

Re: Carbon port and multi-tty

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 07 May 2008 12:05:03 +0200
> 
> If they don't care enough, why should I when I am not even affected?

Because you want to be better then they are?

Re: Carbon port and multi-tty

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 07 May 2008 12:05:03 +0200
>> 
>> If they don't care enough, why should I when I am not even affected?
>
> Because you want to be better then they are?

I have a better chance for that on my home turf.  Because there I have a
good notion about what is important and what not, and I _see_ the
results of my work every day and can estimate its quality.

As an example: I seem to remember that you gave the MSDOS port a
text-mode CUA-like menu behavior and look, whereas this does not hold
true for text-mode on other operating systems (where tmm-mode is almost
universally despised).

I am not even sure there is any remaining user of MSDOS Emacs.  So how
does it make you a better person if you focus on supporting something
which nobody seems to care about, anyway?  Then this "better" is
basically just making a statement about your skills, but not its
beneficial effect on others.

I am not in a position to direct your efforts elsewhere, and indeed I
use text mode rarely enough nowadays that it would make much of a
difference for myself.  There are users that still prefer text
terminals, though.  But then the MSDOS code presumably is there, and if
somebody was _really_ agitated about it, he could attempt a port.  It
may be a wart, but it is not like it is a fresh one...

-- 
David Kastrup

Re: Carbon port and multi-tty

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 07 May 2008 12:51:36 +0200
> 
> As an example: I seem to remember that you gave the MSDOS port a
> text-mode CUA-like menu behavior and look, whereas this does not hold
> true for text-mode on other operating systems (where tmm-mode is almost
> universally despised).

You have your history backwards: the MSDOS menu support was coded
_before_ tmm was made part of Emacs.  Back when menus were added to
the MSDOS port, the text-mode Emacs would only _show_ the menu bar,
but you couldn't get to it nor invoke the menus in any way.  The only
platform with menus back then was X11, which is why the menu support
in msdos.c is an emulation of the Xlib functions.

> I am not even sure there is any remaining user of MSDOS Emacs.

There were lots of them back when I actually was working on the MSDOS
port.  There was a whole project, called DJGPP, which ported a whole
lot of GNU packages (see http://www.delorie.com/djgpp, if you are
interested), and the DOS port of Emacs was an important part of it.
I'm talking about 1992-1998 time frame, when GNU/Linux was in diapers
and unsuitable for general public, and every other platform besides
DOS/Windows was expensive and of course proprietary.  NTEmacs just
began to be barely available, could only be compiled by a proprietary
compiler, and at first lacked the GUI features it has now.  The DOS
port of Emacs (and the rest of DJGPP) was used on both plain DOS and
on Windows back then, and its support for menus, mouse, clipboard, and
long file names made it suitable for quite an audience.

> So how does it make you a better person if you focus on supporting something
> which nobody seems to care about, anyway?

Well, nowadays, when ``nobody cares about'' DOS, I don't work on the
DOS port, either.  Check out the logs, and you will see where most of
my (admittedly, minimal) free time is invested in Emacs.

> I am not in a position to direct your efforts elsewhere, and indeed I
> use text mode rarely enough nowadays that it would make much of a
> difference for myself.  There are users that still prefer text
> terminals, though.  But then the MSDOS code presumably is there, and if
> somebody was _really_ agitated about it, he could attempt a port.  It
> may be a wart, but it is not like it is a fresh one...

Some of the code and experience gained by the DOS port _was_ brought
to the text-mode Emacs: the whole color-mapping feature, the one that
transparently and automatically finds a suitable text color when some
Lisp requests something like "BurlyWood" (see tty-colors.el), was a
reimplementation of color mapping developed for the MSDOS port, when
it was the only text-mode platform that supported colors.  Before
that, unless one of 8 ANSI colors supported by a terminal was
requested, Emacs would simply fall back on the default color, which
made many features dysfunctional.

I'm sorry I no longer have time to port the menus to the text-mode
terminal, but we don't always control what happens in our lives.  I'm
even more sorry that I cannot finish the bidi iterator for Emacs
display engine: I think it's much more important than text-mode menus.

Anyway, I hope this wasn't just about my personal contribution, but
about being kinder and more cooperative, even if you don't always get
the same measure in response.

Re: Carbon port and multi-tty

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 07 May 2008 12:51:36 +0200
>> 
>> As an example: I seem to remember that you gave the MSDOS port a
>> text-mode CUA-like menu behavior and look, whereas this does not hold
>> true for text-mode on other operating systems (where tmm-mode is
>> almost universally despised).
>
> You have your history backwards:

That may well be.

> I'm sorry I no longer have time to port the menus to the text-mode
> terminal, but we don't always control what happens in our lives.  I'm
> even more sorry that I cannot finish the bidi iterator for Emacs
> display engine: I think it's much more important than text-mode menus.

I very much agree.

> Anyway, I hope this wasn't just about my personal contribution, but
> about being kinder and more cooperative, even if you don't always get
> the same measure in response.

It certainly was not supposed to be a complaint about your personal
contribution at all and I am sorry if it came across as such: we
certainly have had enough in the line of "you should be doing this and
that" recently.  I just wanted to give sort of a hands-on example of my
stance.  It may not have been the best idea to pick that.

-- 
David Kastrup

Re: Carbon port and multi-tty

[Richard M Stallman]

    Because you want to be better then they are?

Spending time to support a non-free system is not, in general, a
virtue, and is not a particularly effective way to become a better
person.

Re: Carbon port and multi-tty

[David Kastrup]

Richard M Stallman <rms@gnu.org> writes:

>     Because you want to be better then they are?
>
> Spending time to support a non-free system is not, in general, a
> virtue, and is not a particularly effective way to become a better
> person.

Taking morals aside for a moment, one tends to be most effectively
recognizing and treating the problems in software one is actively
working with.  That holds particularly for productive software like an
editor.  So it may be smarter to leave the support of non-free software
systems mostly to those actually using the system, to the degree that
they are able to contribute to this support (even if it means just
digging up information, user interaction guidelines, preparing a good
plan of what they would need implemented, writing documentation for it
and so on).

-- 
David Kastrup

Re: Carbon port and multi-tty

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 08 May 2008 10:56:32 +0200
> 
> So it may be smarter to leave the support of non-free software
> systems mostly to those actually using the system, to the degree that
> they are able to contribute to this support (even if it means just
> digging up information, user interaction guidelines, preparing a good
> plan of what they would need implemented, writing documentation for it
> and so on).

I agree, but that's not what I was talking about.  I'm not naive
enough to ask someone who doesn't use a platform to develop code for
it.  I'm asking for a _minimal_ effort not to _break_ it.  This
minimal effort, IMO, is confined to these guidelines:

 . When considering changes, take into consideration their effect on
   other platforms (ask the experts, if needed), and avoid making
   changes that will affect those other platforms badly.

 . When implementing changes, if you don't know enough to implement
   them correctly on other platforms, make them conditionally compiled
   only on those you do know, and provide enough info and heads-up for
   the other platforms' specialists to finish implementation on their
   platforms.

Re: Carbon port and multi-tty

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Thu, 08 May 2008 10:56:32 +0200
>> 
>> So it may be smarter to leave the support of non-free software
>> systems mostly to those actually using the system, to the degree that
>> they are able to contribute to this support (even if it means just
>> digging up information, user interaction guidelines, preparing a good
>> plan of what they would need implemented, writing documentation for it
>> and so on).
>
> I agree, but that's not what I was talking about.  I'm not naive
> enough to ask someone who doesn't use a platform to develop code for
> it.  I'm asking for a _minimal_ effort not to _break_ it.  This
> minimal effort, IMO, is confined to these guidelines:
>
>  . When considering changes, take into consideration their effect on
>    other platforms (ask the experts, if needed), and avoid making
>    changes that will affect those other platforms badly.

I don't think that developers here have the habit of breaking things
gratuitously.

-- 
David Kastrup

Re: Carbon port and multi-tty

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: dak@gnu.org, emacs-devel@gnu.org
> Date: Thu, 08 May 2008 04:44:06 -0400
> 
>     Because you want to be better then they are?
> 
> Spending time to support a non-free system is not, in general, a
> virtue, and is not a particularly effective way to become a better
> person.

Well, you and I both know for a long time that we disagree on that.  I
tend to think about people whom I'm helping, not the proprietors of
their platforms (which couldn't care less about the existence of
myself and the users I'm helping).

Btw, current GNU/Linux systems can hardly be called "free", either,
due to gobs of proprietary software they come with.  Which doesn't
surprise me: as soon as software gets out of hands of volunteers into
the hands of businessmen, this is IMO inevitable in the world in which
we live.

Re: Carbon port and multi-tty

[Richard M Stallman]

The primary mission of GNU is freedom and social solidarity.  We seek
to help computer users by giving them software that respects their
freedom and their community, so as to put an end to the practice of
using proprietary software, which tramples both.

Along the way we also have chances to help users in more directly
practical ways, and it is good that we do this, as long as it does not
distract our attention from the real goal.

    Btw, current GNU/Linux systems can hardly be called "free", either,
    due to gobs of proprietary software they come with.

This is why gnu.org has a list of free distros.

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

I'd really really like to stop.  Just one thing.

>>>>> On Wed, 07 May 2008 10:42:15 +0200, David Kastrup <dak@gnu.org> said:

> Large amounts of work for some programs go into supporting things
> like compatibility with Windows or XEmacs or similar where the
> developers themselves are not actually using the platform in
> question.

I really respect such efforts, and I think I understand that to some
extent because I've been supporting several older versions of OSes or
configurations that I don't usually use.

Again, I'm saying about mixing unrelated changes, not about the
breakage on a particular platform that I'm working on.

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

Re: Carbon port and multi-tty

[David Kastrup]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> I'd really really like to stop.  Just one thing.
>
>>>>>> On Wed, 07 May 2008 10:42:15 +0200, David Kastrup <dak@gnu.org> said:
>
>> Large amounts of work for some programs go into supporting things
>> like compatibility with Windows or XEmacs or similar where the
>> developers themselves are not actually using the platform in
>> question.
>
> I really respect such efforts, and I think I understand that to some
> extent because I've been supporting several older versions of OSes or
> configurations that I don't usually use.
>
> Again, I'm saying about mixing unrelated changes, not about the
> breakage on a particular platform that I'm working on.

We are talking about CVS here, not git.  There is no good off-line way
to clean up and reorganize patch sets before committing.

And you have been foaming at your mouth for some dozen mails here in the
abstract before finally coming up with the information that all that
bile centered around a single line in a 1000+ line change.

I mean, get real.  That's an excellent ratio of problematic lines per
work done.  In particular when the developer does only have spurious
knowledge of the platform and limited testing possibilities.

-- 
David Kastrup

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 May 2008 12:16:50 +0200, David Kastrup <dak@gnu.org> said:

> We are talking about CVS here, not git.  There is no good off-line
> way to clean up and reorganize patch sets before committing.

Again, the Mac-specific part was not a part of the original multi-tty
"fork" at http://lorentey.hu/project/emacs.html.en .  It was created
by Dan probably by copying from the corresponding part of the W32
port, and I guess he couldn't rule out the irrelevant part for some
reason.

> And you have been foaming at your mouth for some dozen mails here in
> the abstract before finally coming up with the information that all
> that bile centered around a single line in a 1000+ line change.

Although the number of bugs/lines are not meaningful in the problem of
mixing unrelated changes, the "single-line bug" is only among the code
that is unrelated to multi-tty, which is estimated as < 50 lines.
There is another more crucial "unresponsiveness bug" in the whole
multi-tty Carbon changes.

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

Re: Carbon port and multi-tty

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Tue, 06 May 2008 22:55:12 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > >> The bug introduced by this change is mentioned here:
  > >> http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html
  > 
  > > OK, a 1 line change (in a ~1000 lines patch) that you seemed to have
  > > known about for a while.
  > 
  > 1-line change can introduce a nasty bug as actually seen in this case.
  > And this could be easily avoided by not changing the part that is
  > unrelated to multi-tty.

And it would have been easily fixed, like all other bugs in emacs, had
the platform not been declared unmaintained the moment the patch came
out.  Not saying that without the patch the code would not even
compile.  Not mentioning that you could have simply fixed it without
causing all this racket.

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 May 2008 00:15:52 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> >>>>> On Tue, 06 May 2008 22:55:12 -0700, Dan Nicolaescu
>> <dann@ics.uci.edu> said:
>> 
>> >> The bug introduced by this change is mentioned here: >>
>> http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html
>> 
>> > OK, a 1 line change (in a ~1000 lines patch) that you seemed to
>> have > known about for a while.
>> 
>> 1-line change can introduce a nasty bug as actually seen in this
>> case.  And this could be easily avoided by not changing the part
>> that is unrelated to multi-tty.

> And it would have been easily fixed, like all other bugs in emacs,
> had the platform not been declared unmaintained the moment the patch
> came out.  Not saying that without the patch the code would not even
> compile.  Not mentioning that you could have simply fixed it without
> causing all this racket.

Again, I'm saying about mixing unrelated changes, not this particular
single-line bug.  Please don't understate the problem.

And about this ChangeLog entry:

2008-05-07  Dan Nicolaescu  <dann@ics.uci.edu>

	* macfns.c (Fx_create_frame): Make a copy of frame parameters
	because the original parameters are in pure storage now.

The primary purpose of the copying is not for the parameters allocated
in the pure storage, but to prepare for frame parameter clearing in
x_get_arg.

Lisp_Object
x_get_arg (dpyinfo, alist, param, attribute, class, type)
     Display_Info *dpyinfo;
     Lisp_Object alist, param;
     char *attribute;
     char *class;
     enum resource_types type;
{
  register Lisp_Object tem;

  tem = Fassq (param, alist);

  if (!NILP (tem))
    {
      /* If we find this parm in ALIST, clear it out
	 so that it won't be "left over" at the end.  */
#ifndef WINDOWSNT /* w32fns.c has not yet been changed to cope with this.  */
      Lisp_Object tail;
      XSETCAR (tem, Qnil);
      /* In case the parameter appears more than once in the alist,
	 clear it out.  */
      for (tail = alist; CONSP (tail); tail = XCDR (tail))
	if (CONSP (XCAR (tail))
	    && EQ (XCAR (XCAR (tail)), param))
	  XSETCAR (XCAR (tail), Qnil);
#endif
    }

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

Re: Carbon port and multi-tty

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Wed, 07 May 2008 00:15:52 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > > YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
  > >> >>>>> On Tue, 06 May 2008 22:55:12 -0700, Dan Nicolaescu
  > >> <dann@ics.uci.edu> said:
  > >> 
  > >> >> The bug introduced by this change is mentioned here: >>
  > >> http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html
  > >> 
  > >> > OK, a 1 line change (in a ~1000 lines patch) that you seemed to
  > >> have > known about for a while.
  > >> 
  > >> 1-line change can introduce a nasty bug as actually seen in this
  > >> case.  And this could be easily avoided by not changing the part
  > >> that is unrelated to multi-tty.
  > 
  > > And it would have been easily fixed, like all other bugs in emacs,
  > > had the platform not been declared unmaintained the moment the patch
  > > came out.  Not saying that without the patch the code would not even
  > > compile.  Not mentioning that you could have simply fixed it without
  > > causing all this racket.
  > 
  > Again, I'm saying about mixing unrelated changes, not this particular
  > single-line bug.  Please don't understate the problem.

You keep repeating the same thing over and over.  We heard you the first
time, and nobody agreed.

We have all realized by now that you are making a mountain out of a mole hill.

This code has been in CVS for a year, you have made a choice to neither
undo it, nor move a single finger to make it completely functional.  
The fact that you have known about a one line bug for 4 months and chose
not to fix it, but instead create all this commotion did not win you any
friends.

You have already been told by the 2 head Emacs maintainers: "If you're disturbed by
the remaining problems on Carbon, please try working on a fix instead of
complaining." "If you can do better, show us.  Otherwise, please stop complaining"

PLEASE STOP WASTING OUR TIME.

  > And about this ChangeLog entry:
  > 
  > 2008-05-07  Dan Nicolaescu  <dann@ics.uci.edu>
  > 
  > 	* macfns.c (Fx_create_frame): Make a copy of frame parameters
  > 	because the original parameters are in pure storage now.
  > 
  > The primary purpose of the copying is not for the parameters allocated
  > in the pure storage, but to prepare for frame parameter clearing in
  > x_get_arg.

This is the same ChangeLog used by Martin Rudalics to fix a similar
problem that was discovered by Juanma Barranquero that manifested itself
by trying to write to pure storage.

Re: Carbon port and multi-tty

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 07 May 2008 18:03:40 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

>> Again, I'm saying about mixing unrelated changes, not this
>> particular single-line bug.  Please don't understate the problem.

> You keep repeating the same thing over and over.  We heard you the
> first time, and nobody agreed.

Maybe.  Of course I can't force you not to mix the unrelated changes.
I just hope that doesn't happen again.

Let's go to non-waste part.

>> And about this ChangeLog entry:
>> 
>> 2008-05-07 Dan Nicolaescu <dann@ics.uci.edu>
>> 
>> * macfns.c (Fx_create_frame): Make a copy of frame parameters
>> because the original parameters are in pure storage now.
>> 
>> The primary purpose of the copying is not for the parameters
>> allocated in the pure storage, but to prepare for frame parameter
>> clearing in x_get_arg.

> This is the same ChangeLog used by Martin Rudalics to fix a similar
> problem that was discovered by Juanma Barranquero that manifested
> itself by trying to write to pure storage.

It was I who found the cause of this problem.
http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01069.html

And for the W32 port, it is true that the only purpose of the copying
is to avoid writing to the pure storage.  But notice that some part of
the x_get_arg code I showed in the previous mail was enclosed with
"#ifndef WINDOWSNT", and the copying code in xfns.c and macfns.c had
existed before some frame parameter got allocated in the pure storage.

So, the primary purpose of copying is different between W32 and
X11/Mac.

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

Re: Carbon port and multi-tty

[Stefan Monnier]

> Again, I'm saying about mixing unrelated changes, not this particular
> single-line bug.  Please don't understate the problem.

Please stop the figer pointing and throwing dirt at each other.
Let's get back to coding and fixing bugs.
If you lack ideas, check out http://emacsbugs.donarmstrong.com/emacs
and help us bring down the number of open bugs.


        Stefan