Re: Emacs learning curve

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Well, call them by some other name, but the maintainers I'm thinking of
 > are those with the power of making controversial decisions against the
 > opinion of other prominent Emacs contributors. Currently they are Chong
 > and Stefan, AFAIK.

And Richard.  Note that Stefan and Yidong are *officially* maintainers,
anointed by the GNU Project, IIRC.  However, for the present purposes
they are more like a Supreme Court than they are like an Environmental
Protection Agency.

But it's also true that any committer can make such a decision
(outside of the UI).  I can't recall a thread off-hand, but basically
what happens is that other committers think "Well, on your head be it,
then," and somebody who commits against substantial opposition is
staking their credibility.  Knowing most of the people involved, I
would bet you don't even have to be right.  Rather, if you recognize
that your idea is going south and revert it before somebody else does,
you get credit for bold but objective thinking.

 > Well, I was thinking on that plan, because I'm working on a project that
 > is tangential to this, so I was even considering to write an sketch and
 > submit it here just in case there is something on it that is unaceptable
 > or someone proposes an improved strategy. Guess what? there was no need
 > for it: was smashed a few post above.

If there is a policy rule that smashes it, then why mention it?  The
only thing that needs to be said in that case is "we newer
contributors need an explicit list of policy rules."  (And I don't
mean scattered through historical documents like the GNU Manifesto.)

If it's merely the weight of developer opinion that smashed it, maybe
you really ought to make the proposal formally.  If not accepted (and
you're right, few are) but none of the criticism convinces you
otherwise, make a branch.  What's your big hurry?

Think, how long has Miles's lexbind branch been around?  That's a
great idea with a consensus behind it, but since it changes everything
it needs substantial testing.  I gather that there is almost consensus
for integrating it "soon" (ie within a couple of release cycles).  I
think a good demo of "something better" that's more superficial than
changing the default semantics of binding (wow, what a concept) would
take far less time to be embraced.  But you need to show people that
it's better with a demo; words rarely are enough unless you have a
track record of introducing significant improvements.

 > It seems that a workable plan here must meet the following conditions:
 > 
 > * Follow the GNU guidelines wrt the programming language.

True.  That's policy, and a good one.  (Not the particular choice of
C, but some specific choice.)

 > * When there is a GNU package for doing something, use it instead of a
 >   non-GNU one.

True.  That's policy, arbitrary but with great support in the core
developer group.  Live with it.

 >   It doesn't help much that the non-GNU package is compatible with
 >   the GPL.

Of course it does.  You can make a friendly fork that uses it.  It
some cases (Windows OS, Mac GUI) it doesn't even have to be
GPL-compatible.  Then bombard the relevant GNU package with bug
reports and screenshots. :-)

 > * Unless it is something accessory that does not conflict with existing
 >   code, the plan must be technically acceptable for an overwhelming
 >   majority of the key Emacs hackers.

No.  You need Stefan and Yidong behind the proposal, and Richard's
silence at least.  I haven't seen Yidong make a decision for a change
against the majority opinion, but I'm sure he's capable, and I have
seen Stefan do so.

It is true that Stefan and Yidong typically seem to follow the
consensus of the key hackers, but that's only because they tend to
speak last.  Really they're leading it. :-)

You do, of course, have to show them that your plan actually can work,
but even performance issues can be postponed in the trunk.

 >   For a plan that introduces significant changes, this happens with
 >   less frequency than the alignment of the four outer planets of
 >   the Solar System.

Not true.  The internals of Emacs have changed dramatically several
times in the last decade (I know that's true because the attendant,
relatively small, changes in API and/or UI are a massive pain in my
ass).  I can only imagine that other, smaller, internal changes happen
quite frequently.

 > * Ditto for the UI changes included in the plan.

That depends.  My sketch of a proposal for a thorough addition of
iconic vocabulary in the UI (a) does not conflict with existing usage,
(b) can be implemented with existing features of the API, and (c) can
be done incrementally over many years.  (That doesn't mean it's
*right*, but it's do-able, and if a committer were to "Just Do It,"
they might be criticized but I doubt it would be forcibly reverted
unless there's some horrible aspect I haven't foreseen.)

 > > and there's nothing like a workable plan to attract followers.  If
 > > there's anything clear from this confused thread, it's that we sorely
 > > need some kind of unified "vision" and specific goals.  Throwing
 > > random ideas and critique will get us nowhere.
 > 
 > I completely agree, but it is in contradiction with what you wrote above
 > about every developer scratching it itch.

No, Eli's saying that some developers have momentary itches, and other
developers have the ten-year itch.  He's looking for someone with a
ten-year itch. :-)

Find a copy of the TV drama "Numbers", I think it's the second show.
The protagonist goes into a game arcade and tells his mentor that he's
totally mentally blocked.  His mentor says, "*You* are?  Ah, I see:
you're trying to deal with human beings, right?" and he nods.  His
mentor then advises him, "When humans are in the equation, things get
messy and paradoxical" or something like that.  Great scene.