GNU bug report logs - #6689
24.0.50; No primary selection

Previous Next

Full log

Message #35 received at 6689 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 6689 <at> debbugs.gnu.org
Subject: RE: bug#6689: 24.0.50; No primary selection
Date: Fri, 23 Jul 2010 09:14:07 -0700

> > I gave concise, clear descriptions - see the original bug 
> > reports.  Do you want me to repeat the recipes?
> 
> There's no need.  Are these two bug reports the only ones that
> consider the behavior on Windows that changed because of this?

Dunno.  They are the only two that I submitted.

> > I am relieved to hear people such as yourself agree that 
> > this changed behavior represents a bug and not an
> > intentional change.
> 
> IMO, it is definitely a bug on Windows.
> 
> > That was *not* obvious, given some of the rationalization and
> > discussion of needed "improvements" in this area.
> 
> The intended improvements are on Posix platforms, which support both
> the clipboard and the primary/secondary selections.

That wasn't clear to me.  I must have missed that.
But I still don't know what the intended improvements are.

> > That was one of the points I made: there was no clear 
> > proposal for a specified change, followed by discussion
> > and agreement.  Just some half-discussion and
> > then some code changes.
> 
> People who use Posix platforms are acutely aware of the difference
> between how Emacs used the clipboard and the selections, and how other
> applications do that.  That's why they didn't see any reason to
> discuss the changes before making them.

OK, they understand the problem.  And do they all understand and agree on the
solution?  And what about those who are not acquainted with the problem?

I still think a clear proposal that everyone can understand is important,
regardless of what those in-the-know might know (or think they know).  A spec
helps everyone, even those who think they understand it all.

> > The dev process is itself broken in this regard, IMO.  We should see
> > a clear proposal, discuss it, and agree on it, before an attempt is
> > made to implement it.
> 
> That's not how the Emacs development works.  Core developers don't
> need any approval for installing changes; they are trusted to not
> break Emacs for others except in rare cases and then by mistake.  How
> much they want to discuss before installing, is up to them.

Yes, of course they "don't need any approval" and "how much they want to
discuss...is up to them".  They are under no obligation to do or not do
anything.  That does not mean that it wouldn't be helpful to the community as a
whole for proposals to be made and discussion to follow proposals.

"Core developers" are under no obligation, but they live in an Emacs ecosystem,
and they take advantage of that ecosystem.  Users and other, non-"core"
developers can be useful, and their input can help.  There is no _obligation_
not to keep them in the dark and treat them like mushrooms.  But that is in no
one's interest, IMO.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.