From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Wed, 14 Jul 2010 11:32:23 +0900 Message-ID: <87y6dehjyg.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4C3B6A8A.80105@gmx.de> <87wrt0e81n.fsf@telefonica.net> <83lj9fspjq.fsf@gnu.org> <87tyo3c8k5.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1279076760 16754 80.91.229.12 (14 Jul 2010 03:06:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 14 Jul 2010 03:06:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 14 05:05:59 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OYsII-0001Ee-H7 for ged-emacs-devel@m.gmane.org; Wed, 14 Jul 2010 05:05:59 +0200 Original-Received: from localhost ([127.0.0.1]:36856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYsIH-0000LR-PZ for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 23:05:57 -0400 Original-Received: from [140.186.70.92] (port=59875 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYsIB-0000LA-4J for emacs-devel@gnu.org; Tue, 13 Jul 2010 23:05:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYsI9-0003CB-Jk for emacs-devel@gnu.org; Tue, 13 Jul 2010 23:05:50 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:59354) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYsI9-0003Bs-1d for emacs-devel@gnu.org; Tue, 13 Jul 2010 23:05:49 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id AC5DE1535AE; Wed, 14 Jul 2010 11:38:40 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 46CBD1A2691; Wed, 14 Jul 2010 11:32:23 +0900 (JST) In-Reply-To: <87tyo3c8k5.fsf@telefonica.net> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127243 Archived-At: =D3scar 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: >=20 > * 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. >=20 > 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.