GNU Emacs Developement Inefficiency (commentary)
Xah Lee
http://xahlee.org/emacs/GNU_Emacs_dev_inefficiency.html
essay; commentary. Plain text version follows.
--------------------------------------------------
GNU Emacs Developement Inefficiency
Xah Lee, 2010-07-15
Posted a bug about a problem in minor modes. bug#6611 However, it got
closed, WRONGLY! (For detail about the tech issue, see: How to Turn a
Minor Mode on/off/toggle?)
It got closed right away i suppose partly has to do with my
unforgiving nature of criticizing and run-in with some GNU emacs
developers in gnu.emacs.help and comp.emacs in the past 5 or so years.
It's quite frustrating trying to contribute to GNU Emacs. In the past
3 years, i've submitted some 50 bug reports i think by now... without
looking at the records, i think at lesat 10 or so are hard bugs that
got fixed. Some of my outspoken criticisms, had their effects, and i
suppose some emacs 23's UI changes are influenced by my criticisms.
(e.g. line-move-visual, text selection highligh by default, and i
noticed yesterday that emacs 23.2.1's doc now removed the phrase “real-
time display editor”, which was a item i criticized in Problems of
Emacs's Manual.)
I've also written to Richard Stallman a few times in private in about
2008 or 2009, about documentation improvements. With extreme
politeness and respect on my part. Without going into detail, i'm just
disenchanted by his reaction. In short, it appears to me he did not
pay much attention, and basically in the end asked me to submit
changes to him. Yeah right. The whole shebang seems to be very well
described by Ben Wing. (See: GNU Emacs and Xemacs Schism, by Ben
Wing.) (Richard Stallman's emails are pretty short, just a couple
terse sentences; but he does, however, whenever he got a chance, tell
his correspondents to use the term GNU/Linux, and ask them to
contribute.)
Re-writing the whole doc in a modern perspective might take me one
month full time. (e.g. 160 hours) But if it were to be done in a
public way, or submit to him, the time it takes to communicate, email,
write justifications, create diffs, etc, can easily take half a year
full time (960 hours). In the end, i'm not even sure half of the text
in the new doc would be accepted.
The GNU Emacs's bug database sucks majorly. I have problem finding all
bugs posted by me. (it's using Debbugs.) Hard to find any bug by its
search feature. They did not have a bug database, only in around 2008.
Most commercial software have a bug database system in 1990s, and most
large open source projects have one by early 2000s. (I wrote a bug
tracker in 1998, 4k lines of Perl (with CGI, MySQL), in about 2 weeks,
for a startup brainpower.com.)
Am pretty sure there are several good “FSF Free” bug databases. (see:
Comparison of issue-tracking systems) Few years ago, some may have
problem to be politically qualified to be “Free” for FSF to adopt.
However, these days there are many that FSF officially sactions as
“Free”. However, when you look at FSF, you see that even when a
software became free, they usually are still picky with lots qualms,
and typically always ends up using their OWN ones (i.e. from GNU
project), even though it is clear that it is inferior. (the GNU emacs
dev's revision control system was CVS up to ~2008. CVS has been phased
out by 2000 in vast majority of software orgs or projects. I think GNU
emacs now using SVN, while most bleeding edge orgs have switched to
git, mercurial, distributed systems. (e.g. FireFox, Google))
These are consequence of old and large orgs, with its old policies and
beaucracies. See: “Free” Software Morality, Richard Stallman, and
Paperwork Bureaucracy.
Who are the main developers of FSF software these days? Mostly, they
are either paid as FSF employee, or students still trying to break out
their craft in programing, or 40/50 years old semi-retired programers
who otherwise isn't doing anything. Those willing and able, spend time
and get decent salary in commercial corps, or went to start their own
projects or business that'd be far more rewarding financially or not
than being another name in FSF's list of contributors.
These days, FSF and Richard Stallman more serves as a figure-head and
political leader in open source movement. FSF's software, largely are
old and outdated (e.g. unix command line utils), with the exception of
perhaps GCC and GPG. If we go by actual impact of open source software
in society, i think Google's role, and other commercial orgs (such as
Apache, Perl, Python, PHP, various langs on JVM, and other project
hosters hosting any odd-end single-man projects), exceeded FSF by
~2000.
Xah
∑ http://xahlee.org/
☄
Uday S Reddy
Uday S Reddy
>
> It got closed right away i suppose partly has to do with my
> unforgiving nature of criticizing and run-in with some GNU emacs
> developers in gnu.emacs.help and comp.emacs in the past 5 or so years.
I think "criticizing" is an understatement for what you do. Insulting and
abusing might be closer to the truth. You do write a lot of sense, but you
also go off on rants occasionally writing stuff that has no place in civil
conversation. I am sure that the emacs developers try to be as professional as
they can, but they would only be human if they undervalue your input because of
your writing style.
>
> Re-writing the whole doc in a modern perspective might take me one
> month full time. (e.g. 160 hours) But if it were to be done in a
> public way, or submit to him, the time it takes to communicate, email,
> write justifications, create diffs, etc, can easily take half a year
> full time (960 hours). In the end, i'm not even sure half of the text
> in the new doc would be accepted.
If you can rewrite it in a month's time, then what are you waiting for? You
can write it and publish it on your own, calling it a "Modernized Emacs
Manual". If people find it valuable and it is accurate, then I am sure Gnu
will distribute it.
> The GNU Emacs's bug database sucks majorly. I have problem finding all
> bugs posted by me. (it's using Debbugs.) Hard to find any bug by its
> search feature. They did not have a bug database, only in around 2008.
> Most commercial software have a bug database system in 1990s, and most
> large open source projects have one by early 2000s. (I wrote a bug
> tracker in 1998, 4k lines of Perl (with CGI, MySQL), in about 2 weeks,
> for a startup brainpower.com.)
I go to gmane.emacs.bugs and view it in Thunderbird. I have no problem finding
my bug reports or any one else's.
Cheers,
Uday
David Kastrup
> If you can rewrite it in a month's time, then what are you waiting
> for? You can write it and publish it on your own, calling it a
> "Modernized Emacs Manual". If people find it valuable and it is
> accurate, then I am sure Gnu will distribute it.
I am not. For some core products (and this includes Emacs), the FSF
requires copyright assignments in order to consider distributing them.
For something that would better be within the Emacs distribution proper,
I doubt that the FSF will consider separate distribution needed for
works not assigned to the FSF.
That does not mean that others won't distribute it (depending on its
license).
--
David Kastrup
Alan Mackenzie
> --------------------------------------------------
> GNU Emacs Developement Inefficiency
> Xah Lee, 2010-07-15
> It [a bug report] got closed right away i suppose partly has to do with
> my unforgiving nature of criticizing and run-in with some GNU emacs
> developers in gnu.emacs.help and comp.emacs in the past 5 or so years.
It has to be said that that criticism has sometimes involved the use of
curse words.
> It's quite frustrating trying to contribute to GNU Emacs.
I don't find it a problem most of the time, though it does get
frustrating occasionally.
> In the past 3 years, i've submitted some 50 bug reports i think by
> now... without looking at the records, i think at lesat 10 or so are
> hard bugs that got fixed. Some of my outspoken criticisms, had their
> effects, and i suppose some emacs 23's UI changes are influenced by my
> criticisms. (e.g. line-move-visual, text selection highligh by
> default, and i noticed yesterday that emacs 23.2.1's doc now removed
> the phrase ?real- time display editor?, which was a item i criticized
> in Problems of Emacs's Manual.)
So if your bug reports are getting things moved, what's so frustrating?
> I've also written to Richard Stallman a few times in private in about
> 2008 or 2009, about documentation improvements. With extreme
> politeness and respect on my part. Without going into detail, i'm just
> disenchanted by his reaction. In short, it appears to me he did not
> pay much attention, and basically in the end asked me to submit
> changes to him. Yeah right.
Understand that RMS answers vast numbers of emails every day, and thus
can't spend more than a few seconds each on the vast majority. At least
when you email RMS you get a reply, and that reply is from him, not some
underling.
> The whole shebang seems to be very well described by Ben Wing. (See:
> GNU Emacs and Xemacs Schism, by Ben Wing.) (Richard Stallman's emails
> are pretty short, just a couple terse sentences; but he does, however,
> whenever he got a chance, tell his correspondents to use the term
> GNU/Linux, and ask them to contribute.)
Yes.
> Re-writing the whole doc in a modern perspective might take me one
> month full time. (e.g. 160 hours)
I think it would take you a great deal longer than that. But it would be
easy enough to experiment on. Chose some chapter from the Emacs or Elisp
manual, fire away and see how long it takes you.
> But if it were to be done in a public way, or submit to him, the time
> it takes to communicate, email, write justifications, create diffs,
> etc, can easily take half a year full time (960 hours). In the end, i'm
> not even sure half of the text in the new doc would be accepted.
I think your changes would not be accepted as such. Quite bluntly, your
English isn't good enough, so somebody would have to go through your
version eliminating solecisms. There's a vast gap between being able to
use English adequately to transmit your meaning and being able to write
stylish and correct English. Your English belongs to the former
category. As a matter of interest, what is your native language?
> (the GNU emacs dev's revision control system was CVS up to ~2008. CVS
> has been phased out by 2000 in vast majority of software orgs or
> projects. I think GNU emacs now using SVN, while most bleeding edge
> orgs have switched to git, mercurial, distributed systems. (e.g.
> FireFox, Google))
What's your source for "the vast majority" of projects no longer using
CVS, again as a matter of interest? Emacs uses BZR, not SVN, and has
done since the beginning of 2010.
> These are consequence of old and large orgs, with its old policies and
> beaucracies. See: ?Free? Software Morality, Richard Stallman, and
> Paperwork Bureaucracy.
Emacs uses a bug database (even if not the best) and a distributed VCS.
If the project were that old and stodgy, these two things wouldn't have
happened.
> Xah
> http://xahlee.org/
--
Alan Mackenzie (Nuremberg, Germany).
Xah Lee
> It [a bug report] got closed right away i suppose partly has to do with
> my unforgiving nature of criticizing and run-in with some GNU emacs
> developers in gnu.emacs.help and comp.emacs in the past 5 or so years.
On Jul 16, 9:25 am, Alan Mackenzie <a...@muc.de> wrote:
> It has to be said that that criticism has sometimes involved the use of
> curse words.
i admit that's true.
> So if your bug reports are getting things moved, what's so frustrating?
couldn've been better.
> > Re-writing the whole doc in a modern perspective might take me one
> > month full time. (e.g. 160 hours)
>
> I think it would take you a great deal longer than that. But it would be
> easy enough to experiment on. Chose some chapter from the Emacs or Elisp
> manual, fire away and see how long it takes you.
btw, i don't think elisp manual needs to be re-worked, or at least not
critical... but i think it's much critical that the emacs manual be.
> I think your changes would not be accepted as such. Quite bluntly, your
> English isn't good enough, so somebody would have to go through your
> version eliminating solecisms. There's a vast gap between being able to
> use English adequately to transmit your meaning and being able to write
> stylish and correct English. Your English belongs to the former
> category. As a matter of interest, what is your native language?
Haha, that's a good one.
i disconcur. See:
• The Writing Style on XahLee.org
http://xahlee.org/Periodic_dosage_dir/bangu/xah_style.html
> > (the GNU emacs dev's revision control system was CVS up to ~2008. CVS
> > has been phased out by 2000 in vast majority of software orgs or
> > projects. I think GNU emacs now using SVN, while most bleeding edge
> > orgs have switched to git, mercurial, distributed systems. (e.g.
> > FireFox, Google))
>
> What's your source for "the vast majority" of projects no longer using
> CVS, again as a matter of interest?
sloppy exaggeration. Though, i would say “majority”, from experience.
e.g. look at google and other large orgs commercial or open source,
and look at the revision system supported by large project hosters
such as google code, SourceForge, github...
> Emacs uses BZR, not SVN, and has
> done since the beginning of 2010.
Thanks for your correction. Updated my site.
(also thanks to Uday S Reddy & David Kastrup for comment.)
Xah
∑ http://xahlee.org/
☄
Emmy Noether
> On 7/16/2010 12:23 AM, Xah Lee wrote:
>
>
>
> > It got closed right away i suppose partly has to do with my
> > unforgiving nature of criticizing and run-in with some GNU emacs
> > developers in gnu.emacs.help and comp.emacs in the past 5 or so years.
>
> I think "criticizing" is an understatement for what you do. Insulting and
> abusing might be closer to the truth. You do write a lot of sense, but you
> also go off on rants occasionally writing stuff that has no place in civil
> conversation. I am sure that the emacs developers try to be as professional as
> they can, but they would only be human if they undervalue your input because of
> your writing style.
Well, there is a lot of resistance from the emacs community in sharing
information. Richard Stallman is a true STALLER of progress. He has
held the whole process hostage by not sharing information. He has
RENEGED on his promise to make it truly open by suppressing
documentation of his softwares.
> > Re-writing the whole doc in a modern perspective might take me one
> > month full time. (e.g. 160 hours) But if it were to be done in a
> > public way, or submit to him, the time it takes to communicate, email,
> > write justifications, create diffs, etc, can easily take half a year
> > full time (960 hours). In the end, i'm not even sure half of the text
> > in the new doc would be accepted.
>
> If you can rewrite it in a month's time, then what are you waiting for? You
> can write it and publish it on your own, calling it a "Modernized Emacs
> Manual". If people find it valuable and it is accurate, then I am sure Gnu
> will distribute it.
The one who has the key can open the lock in a jiffy.
The one who does not have the key will take lots of labor to do it esp
if he has never opened the lock before.
All Richard Stallman has to do is to hand draw the data-structures and
architecture of the various programs. Give references to the places
where he got the ideas.
He does not even have to type. He can write with pencil and scan and
thats all. This way he can make marvelously elaborate diagrams. He can
even make audios or videos.
He has plenty of time to make POLITICAL videos. He has plenty of time
to to write that elaborate manual on LISP MACHINE PROPOSAL on the
internet.
Its less about bugs and more about releasing the details and tricks of
the softwares he has written.
Yes, he can do in one month because he has the key.
Will he do it only after he is anointed as a king in the temple of
Solomon ?
> > The GNU Emacs's bug database sucks majorly. I have problem finding all
> > bugs posted by me. (it's using Debbugs.) Hard to find any bug by its
> > search feature. They did not have a bug database, only in around 2008.
> > Most commercial software have a bug database system in 1990s, and most
> > large open source projects have one by early 2000s. (I wrote a bug
> > tracker in 1998, 4k lines of Perl (with CGI, MySQL), in about 2 weeks,
> > for a startup brainpower.com.)
>
> I go to gmane.emacs.bugs and view it in Thunderbird. I have no problem finding
> my bug reports or any one else's.
The FSF people have intentionally erected lots of barriers for others.
FSF plays a crooked game and this will be discussed in detail.
In this video, Stall man makes 4 promises to public but stalls on 2nd
of them.
http://www.youtube.com/watch?v=2BfCJq_zIdk&feature=fvsr
1/ Freedom to Run to the Program
2/ Freedom to study the source code, you control it <------ Software
is a puzzle and it must be explained to be able to do that, its like a
lock
3/ Freedom to help your neightbors, share with them
4/ Freedom to contribute to your community
Software is a puzzle and it must be explained to be able to do that,
its like a lock
"to MAKE SURE you get the four freedoms"
He is WRONG !!! He has not made sure. He has not taken the first
steps.
Software architecture must be documented. A model minimal release must
be given. If it takes too long to document the program by writing in
Latex, then he can write by hand or make an video with camera on the
paper and he can talk.
Emmy Noether
> In comp.emacs Xah Lee <xah...@gmail.com> wrote:
>
> > GNU Emacs Developement Inefficiency
> > It [a bug report] got closed right away i suppose partly has to do with
> > my unforgiving nature of criticizing and run-in with some GNU emacs
> > developers in gnu.emacs.help and comp.emacs in the past 5 or so years.
>
> On Jul 16, 9:25 am, Alan Mackenzie <a...@muc.de> wrote:
>
> > It has to be said that that criticism has sometimes involved the use of
> > curse words.
>
> i admit that's true.
Didnt you say that you wrote several polite emails and it did not
work ??? Have some spine and say the truth !!!
> > So if your bug reports are getting things moved, what's so frustrating?
>
> couldn've been better.
You meant "could've"
> > > Re-writing the whole doc in a modern perspective might take me one
> > > month full time. (e.g. 160 hours)
>
> > I think it would take you a great deal longer than that. But it would be
> > easy enough to experiment on. Chose some chapter from the Emacs or Elisp
> > manual, fire away and see how long it takes you.
>
> btw, i don't think elisp manual needs to be re-worked, or at least not
> critical... but i think it's much critical that the emacs manual be.
What he needs is to give a clear and concise explanation of the data-
structures and algorithms of the software. If he used ideas from
others, he need to give reference to them so others can find it and
get into depth. There is no need to make professional diagrams using
xfig etc if it takes too much time. He only needs a scanner, pencil ,
eraser and a ruler.
Others who worked for him and learnt the hard way can also do it , but
I suspect he extracted such a price that they wont be able to give
freely. The XEMACs people deserve some commendation .
> > I think your changes would not be accepted as such. Quite bluntly, your
> > English isn't good enough, so somebody would have to go through your
> > version eliminating solecisms. There's a vast gap between being able to
> > use English adequately to transmit your meaning and being able to write
> > stylish and correct English. Your English belongs to the former
> > category. As a matter of interest, what is your native language?
>
> Haha, that's a good one.
This is why they brought indians to checkmate the chinese. They can
put this accusation of english as they used to do on the asians and
japanese throughout the 90s by Japanese Bashing. I remember very well
that George Bush senior vomited on the face of Toshiki Kaifu to insult
him intentionally in Japan. This is just a false excuse to give proper
space to you. I think you write excellently.
> i disconcur. See:
>
> • The Writing Style on XahLee.org
> http://xahlee.org/Periodic_dosage_dir/bangu/xah_style.html
>
> > > (the GNU emacs dev's revision control system was CVS up to ~2008. CVS
> > > has been phased out by 2000 in vast majority of software orgs or
> > > projects. I think GNU emacs now using SVN, while most bleeding edge
> > > orgs have switched to git, mercurial, distributed systems. (e.g.
> > > FireFox, Google))
>
> > What's your source for "the vast majority" of projects no longer using
> > CVS, again as a matter of interest?
>
> sloppy exaggeration. Though, i would say “majority”, from experience.
> e.g. look at google and other large orgs commercial or open source,
> and look at the revision system supported by large project hosters
> such as google code, SourceForge, github...
Mackenzie, bring a properly written documentation by FSF for example
on emacs of gcc. I want to see where RMS got his ideas ? Did he invent
all of them himself ? Is he giving proper references to the sources of
the ideas ? Is that plagiarism ?
I am sick of such jews/zionists like RMS, Roman Polansky, Bernard
Madoff, Larry Ellison (he had to pay 100K in court to a chinese girl
he screwed), Stephen Wolfram, Albert Einstein spreading anti-semitism
by their flagrant unethical behaviour.
If you use someone else's ideas, give reference. Dont try to portray
yourself falsely as a genius by hiding sources and weaving rosy false
pictures of being a victim or born out of wedlock. you went to school
and got good education. you got insights from your community and good
mentorship from other jews in aggressive networking in the jews like
other communities dont have.
These are facts. Thats why these people dont stand to scrutiny and
questioning.
> > Emacs uses BZR, not SVN, and has
> > done since the beginning of 2010.
>
> Thanks for your correction. Updated my site.
Write a good documentation using pencil and scan that helps newbies
enter the field.
If it is not there, you will be subject of perpetual criticism and no
thanks.
Emmy Noether
> • GNU Emacs Developement Inefficiency
> http://xahlee.org/emacs/GNU_Emacs_dev_inefficiency.html
>
> essay; commentary. Plain text version follows.
>
> --------------------------------------------------
> GNU Emacs Developement Inefficiency
>
> Xah Lee, 2010-07-15
>
> I've also written to Richard Stallman a few times in private in about
> 2008 or 2009, about documentation improvements. With extreme
> politeness and respect on my part.
You took good precaution to deny him any excuse to fend you off ... so
that we can all know the true reality of the situation. Its long said
by others that this idea of freedom is a bait. Still, I want to give
him / FSF a chance to prove their sincerity in enabling others in
reading the code and learning from it ...
Keith Thompson
[98 lines deleted]
The parent article was posted to comp.emacs and comp.lang.lisp. Why
did you cross-post your followup to comp.lang.c, comp.lang.python,
and comp.lang.scheme?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Cor Gest
Some entity, AKA Emmy Noether <emmyno...@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> You took good precaution to deny him any excuse to fend you off ... so
You got the stuff, so .. just get to it.
> that we can all know the true reality of the situation. Its long said
> by others that this idea of freedom is a bait.
> him / FSF a chance to prove their sincerity in enabling others in
> reading the code and learning from it ...
If you are to stupid to learn from the source code and//or to cheap to
buy the reference-manuals you will never understand anything.
Cor
--
Join us and live in peace or face obliteration
If you hate to see my gun consider a non criminal line of work
I never threathen but merely state the consequences of your choice
Geavanceerde politieke correctheid is niet te onderscheiden van sarcasme
Tom Lord
> Well, there is a lot of resistance from the emacs community in sharing
> information. Richard Stallman is a true STALLER of progress. He has
> held the whole process hostage by not sharing information. He has
> RENEGED on his promise to make it truly open by suppressing
> documentation of his softwares.
I used to think similarly but differently. In my case
I thought of him as a "STALLER" for not more aggressively
changing Emacs to keep up with GUIs, with better languages
than elisp, with better ways to implement text buffers,
and so forth.
One day I woke up and realized: hey, I've been using this same
damn program for 15 years (and now, today, more than 20). I
use it every day. I'm annoyed on systems that lack it. It
satisfies me, as a user, in ways that almost no other program
I've used for a long time does.
Aha - I realized. He must be doing something right.
And it became way more interesting to try to understand
what he's doing right than to focus exclusively on what he's
doing wrong.
On the documentation thing ... well:
Stallman's code (and code descended from Stallman's code)
tends to annoy me with its sparcity of good commenting,
its long, convoluted functions, its sometimes wacky choices
of how to structure module dependencies, its horrific approach
to portability.....
Problem is, though, than when I've had to actually work
on any of that code? Yeah, it takes some hours or days
of study to puzzle it out - weeks even - but then once
you've "got it" you've got it. It's actually fairly lucid
in spite of the style.
One of the things he does right is not overly documenting
the code. First, it's a lot of work. Second, the folks
that wind up contributing the most to it learn a lot and learn
it well by puzzling it out a bit first on their own.
Yes, really. I'm not suggesting weak internals documentation
and all the other aspects as a general style that everyone
should adapt. I do think it slows some things down.
Yet in some cases, like Emacs, .... well, it's hard to argue
with success, ain't it?
> All Richard Stallman has to do is to hand draw the data-structures and
> architecture of the various programs. Give references to the places
> where he got the ideas.
Isn't that (the drawing) something you could do?
As for where he got the ideas: a lot of Emacs architecture is
based on common knowledge ideas, some on the order of 40 years
old. There's not a lot that isn't original in the core
architecture that one would normally want cites about.