A day in the life of emacs
First and foremost, it should be said that the emacs developers are, indeed, active. Whenever the project gets around to making a new release, emacs users will be surprised at how much as been done - more on that shortly. It was surprising to see that Richard Stallman, the creator of GNU emacs, remains very active in its development. He may not produce as much code as he used to, but he is active in the discussions, and still functions very much as the final decision maker on patches. When RMS makes a decree, things happen that way.
A reading of Richard's postings indicate a real concern for the utility of emacs and the creation of a useful user interface. Emacs detractors may differ, but the fact is that quite a bit of thought is going into how emacs works.
Development is not the only issue to be found on a list like this, of course. Back in December Ben Wing requested permission to use parts of the GNU emacs manual in the XEmacs manual. This sort of reuse would seem to be just the sort of freedom that the GNU project is working for; XEmacs is free software, and its manual is licensed under the GPL. Unfortunately, since the GNU emacs manual is licensed under the GFDL, it is not possible to reuse portions of it in the XEmacs manual. Mr. Stallman's responses indicate that he has no problem with this state of affairs:
The XEmacs developers would appear to have gone away empty-handed.
Shortly thereafter, Steve Youngs showed up with an announcement of a brand new emacs fork called SXEmacs. It appears to be a new version of XEmacs with different coding conventions, Windows support removed, and various other changes planned. Not much discussion resulted, but Mr. Youngs is still working on SXEmacs.
At the end of January, Per Abrahamsen proposed that emacs go into a "regression fixes only" freeze so that a release could actually happen. Nobody even responded.
On February 7, Richard Stallman noted that
he had rushed out version 21.4, which adds a single security fix to 21.3.
This move surprised a number of developers who had been telling people
about the great new features 21.4 would have. Richard suggested instead
that the next release should be version 22, since "It has plenty of
new features
". A plan to use
negative version numbers for test releases (e.g. 22.1.-998) was,
fortunately, turned down.
![[Emacs screenshot]](https://static.lwn.net/images/ns/emacs-22-sm.png)
So what will be in emacs 22.1, when it comes out? Your editor grabbed the
CVS version to play with, and found a few things:
- Many things are now bundled with the emacs source distribution;
these include Leim and the emacs Lisp manual.
- New systems supported include Cygwin, Linux on S/390, and Mac
OS X.
- A change that may surprise some users: clicking on a URL with the left
mouse button will now cause emacs to follow the link. The old
behavior (simply moving point to the indicated location) can be had by
holding the mouse button for half a second.
- The GTK+ toolkit is now supported.
- Many modes have seen major improvements; these include gnus, info,
SQL, MH-E, cc, and more.
- Drag-and-drop operation is now supported.
- Mouse wheel support is enabled by default. There appears to be some
logic in the new mouse wheel code which causes the number of lines
scrolled to increase if multiple wheel events come in a short time;
your editor found the experience to be somewhat disorienting.
- A number of new modes have been added, including conf-mode (configuration file editing), dns-mode (for bind master files), flymake (on-the-fly source code syntax checking), thumbs (image thumbnail display), and cua (which provides key bindings which will be more familiar to Windows users).
There are hundreds of other changes; the NEWS
file has all the detail anybody could want. As for when emacs users
will see all these changes: it's hard to say. Mr. Stallman has never been
willing to project release dates for software. In this case, back in
December, all he would commit to was:
"It isn't around the corner, but I hope we are getting closer to
it.
"
Posted Mar 3, 2005 2:14 UTC (Thu)
by dlang (guest, #313)
[Link] (13 responses)
Posted Mar 3, 2005 12:03 UTC (Thu)
by hummassa (subscriber, #307)
[Link] (12 responses)
Posted Mar 3, 2005 17:51 UTC (Thu)
by TxtEdMacs (guest, #5983)
[Link] (4 responses)
Freedom to RMS is more akin to his being dictator and definer of the work "freedom" and in this case not even being a benign dictator.
I still hold RMS in high regard for the essence of his work creating the FSF, but his disdain for all other avenues toward the same goal grates on me. [I am NOT including the "Open Source Software" as one of the parallel movements.]
Posted Mar 4, 2005 5:34 UTC (Fri)
by komarek (guest, #7295)
[Link] (3 responses)
That the fellow from XEmacs asked RMS to "reconsider" his enforcement or selection of this license is interesting, and gutsy. But the tone of that fellow's post was "maybe you can compromise, and hence mend some fences". This seems a bit unlikely:
1) RMS doesn't compromise on his projects. He decides. He seems to care little or nothing for convenience, and principal is everything.
2) Attempts to mend fences in the past have never made any headway. Unless the XEmacs team has something to offer (perhaps soliciting the approval of some XEmacs copyright holders, in order to adjust the licensing), then XEmacs has nothing.
3) And let's not forget: GNU Emacs was the first Emacs. Derivitive works of Emacs that hid their modifications are *the motivation* for the creation of the GPL. RMS discovered that not everyone believed in the golden rule, and some who did would still sign NDA's that prevented them from following it. After being taken advantage of, RMS found a way to defend himself and his work: copyleft. XEmacs is one of these derivatives, one with a long history.
As I understand it, licensing issues prevent XEmacs from contributing improvements back to Emacs. That XEmacs is open at all is nice, but that doesn't help the mother of XEmacs (which is Emacs, before GNU Emacs, iirc). RMS is upset that anyone would ever violate the golden rule, and treat their neighbors poorly. Maybe that's life, but that doesn't mean RMS has to accept the status quo.
I really don't understand the dictator argument. It seems similar to those arguments that compare Red Hat to Microsoft. RMS is not trying to take over the world. He isn't trying to take over anything. He is trying to defend his work, and the work entrusted to the FSF. He also tries to help those who share his priorities and morals (through FSF legal support, for example).
The GNU/Linux debacle is unfortunate. I wish RMS would have said "I will call it GNU/Linux, because it appears to me as the GNU system plus Linus Torvald's excellent kernel." But he didn't. And doesn't. In trying to make his point about the GNU project remaining relevant, and in trying to keep the name of GNU alive where GNU software is used, he has said some strange things. But his actions have *never* been dictatorial, as far as I recall. And his actions are worth far more than his words.
-Paul Komarek
Posted Mar 4, 2005 19:35 UTC (Fri)
by Ross (guest, #4065)
[Link] (1 responses)
But I don't see how _not_ "sharing the software" is really part of his
And to the best of my knowledge XEmacs is under the GPL just like Emacs.
Posted Mar 4, 2005 20:13 UTC (Fri)
by komarek (guest, #7295)
[Link]
Back to the original reason I posted, sp_ware's comment that RMS wants to be a dictator still seems wrong and ignorant. That he set up the FSF and GNU projects, and gave up his copyrights to the FSF, suggests strongly that he does not want to be a dictator. Any disdain he shows for competing Free software could easily come from disliking the waste of effort of duplication (that xemacs link above quotes him on this, w/r/t XEmacs).
Thank-you for pointing out my mistake.
-Paul Komarek
Posted Mar 4, 2005 20:45 UTC (Fri)
by TxtEdMacs (guest, #5983)
[Link]
I have NO problem with that, however, RMS has problems with other people making control decisions with software (and perhaps even documentation) which he was neither the creator nor the maintainer.
That smacks of a dictatorial temperament, regardless of the fact of whether he lacks the power of enforcement of his decrees.
I have instances in mind, but too many details can lead to a nasty tenor so it is better to cease here.
Posted Mar 4, 2005 0:16 UTC (Fri)
by dvdeug (guest, #10998)
[Link] (6 responses)
Posted Mar 5, 2005 18:46 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (5 responses)
When one assigns blame for a failure to cooperate, it's all about perception of fairness. RMS clearly believes that, over the past 10 years, FSF has contributed enough to the cooperation (the Emacs code and license, I presume) that it's only fair for Xemacs folks to contribute copyright assignments. Apparently he also believes that such copyright assignments would be fair exchange for the documentation license Xemacs is requesting now.
So refusing the documentation license isn't hypocritical; it's all part of the same failure to cooperate, and the fact that RMS isn't willing to contribute even more to the cooperation doesn't mean Xemacs is any less at fault for the lack of cooperation.
Posted Mar 7, 2005 6:19 UTC (Mon)
by dvdeug (guest, #10998)
[Link]
Xemacs pulled out because RMS wanted to be lead dictator in Emacs. Efforts at reconciliation have failed because RMS wants the successor to be 100% compatible with Emacs, even though it's not possible to be 100% compatible with both and XEmacs is better designed in some of those places. Copyright assignment is a pain in the ass, but there's no evidence that if FSF asked for something specific from XEmacs, like XEmacs people have done here, that they wouldn't assign the rights. The FSF certainly has the right to use the code without an assignment. Honestly, the FSF has provided code under the GPL, and so have the XEmacs people; why are the XEmacs people not cooperating because they aren't copyright assigning their work to the FSF, when the reverse isn't happening? the fact that RMS isn't willing to contribute even more to the cooperation doesn't mean Xemacs is any less at fault for the lack of cooperation. I find the concept that it's all XEmacs fault for not cooperating to be nonsense. The XEmacs people have a number of complaints about when RMS wouldn't cooperate.
Posted Mar 9, 2005 11:42 UTC (Wed)
by jschrod (subscriber, #1646)
[Link] (3 responses)
Speaking of him, if you want to read an additional (very strongly biased) view of the Emacs/XEmacs chism, you can also check out Jamie Zawinsky's Web Site http://www.jwz.org/doc/lemacs.html where you can even read the emails of RMS and of Richard Gabriel. IMHO it clearly shows that it's both sides faults.
Joachim
Posted Mar 10, 2005 7:13 UTC (Thu)
by giraffedata (guest, #1954)
[Link] (2 responses)
All I see is a statement by RMS that Xemacs refused to cooperate. As I pointed out above, that's a nonsense statement -- cooperation isn't something that one party does. So he's probably talking about fairness. But even then, it's a leap from believing the Xemacs people are being unfair to believing that they are 100% at fault for there being two versions of Emacs (assuming that's a fault at all).
Posted Mar 10, 2005 8:21 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (1 responses)
``any less at fault'' as an answer to ``all failures ... have been XEmacs's fault'' is quite clearly a position, isn't it? And I reacted exactly to that position.
Joachim
Posted Mar 10, 2005 21:23 UTC (Thu)
by giraffedata (guest, #1954)
[Link]
dvdeug said something else besides that he looks askance at this claim by RMS; he gave the reason -- that RMS is today doing the same thing he accuses Xemacs of doing in the past.
All I said is that the reason is wrong -- RMS's refusal to give the documentation license doesn't absolve Xemacs of any fault it might have.
dvdeug then added some different reasons to point the finger away from Xemacs and at RMS.
Posted Mar 3, 2005 2:28 UTC (Thu)
by tnoo (subscriber, #20427)
[Link]
Posted Mar 3, 2005 4:36 UTC (Thu)
by dhess (guest, #7827)
[Link] (1 responses)
This feature is useful if you have, say, a gnus session running at work on your X11 workstation, and you want to attach to it to read email from home over an ssh connection without forwarding X11.
The current release of emacs doesn't support this feature. I dug around on the mailing lists and saw something from one of the emacs developers to the tune of, "We can't do it because of the design of the emacs event loop."
XEmacs does support this feature, and it's the main reason I use XEmacs.
Posted Mar 3, 2005 8:04 UTC (Thu)
by dann (guest, #11621)
[Link]
Posted Mar 3, 2005 5:54 UTC (Thu)
by ncm (guest, #165)
[Link] (4 responses)
Essentially, in Viper mode Vi's insert mode is generic Emacs. The Vi command mode is like regular Vi command mode, but regular Emacs commands still work. There's practically no conflict. Emacs always lacked Vi's "dot" command, a serious omission; now it has it. IMHO viper-mode should be the default; then Vi would be just another subset of Emacs.
Posted Mar 3, 2005 17:30 UTC (Thu)
by mwh (guest, #582)
[Link]
(Mandatory flameproofing: I am not being entirely serious here)
Posted Mar 5, 2005 13:33 UTC (Sat)
by aglet (guest, #1334)
[Link]
Posted Mar 5, 2005 18:30 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (1 responses)
I think it's because so many people, including me, believe they cannot efficently maintain expertise in both. When I first started using Unix, I knew I couldn't afford to learn and keep up with more than one editor, so I looked around and picked the one that most closely met my needs.
Incidentally, it's the same reason I try not to use any program that has its own editor built in. One set of keystrokes is all I can handle.
Posted Mar 13, 2005 15:10 UTC (Sun)
by anton (subscriber, #25547)
[Link]
Well, expertise. I am an Emacs fan and have used it almost
As for learning, when I started with Emacs, I had had two months of
Posted Mar 3, 2005 10:43 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
XEmacs correctly distinguishes between the CLIPBOARD and the PRIMARY selection, but GNU Emacs seems, iirc, to ignore CLIPBOARD altogether, making it difficult to use in conjunction with modern apps that obey ICCCM and Freedesktop standards. I'm told that yet another M-blah-blah-blah option was added, but that's no substitute for simply doing the Right Thing™.
Posted Mar 3, 2005 11:30 UTC (Thu)
by cyd (guest, #4153)
[Link]
You can make killing and yanking consult the clipboard if you set x-select-enable-clipboard to t. The default is nil, except on MS Windows where there is no primary selection.
Posted Mar 3, 2005 12:02 UTC (Thu)
by rmstar (guest, #3672)
[Link] (3 responses)
Posted Mar 3, 2005 17:09 UTC (Thu)
by ncm (guest, #165)
[Link] (2 responses)
Posted Mar 4, 2005 4:46 UTC (Fri)
by flewellyn (subscriber, #5047)
[Link]
Posted Mar 4, 2005 9:17 UTC (Fri)
by larsbrinkhoff (guest, #4638)
[Link]
Posted Mar 6, 2005 20:45 UTC (Sun)
by jzb (editor, #7867)
[Link]
Posted Mar 10, 2005 10:24 UTC (Thu)
by leandro (guest, #1460)
[Link]
Seriously, they've been coming for quite a while now...
Posted Mar 10, 2005 10:28 UTC (Thu)
by forthy (guest, #1525)
[Link] (1 responses)
I'd like to remind RMS on that subject. Apparently he has forgotten
why.
Free Software is about sharing software, and being able to help. If I have
some ideas how to improve Emacs, and other people want them, too, I
must
have the right to change Emacs, and when RMS is not agreed with that, I'll
have to fork. That's what Richard Grabriel had to. If I'm forking a
project, and creating incompatible extensions (the main reason for
forking, isn't it?), then I also have to fork the documentation. Therefore, following the rule that free software needs free
documentation,
the documentation must allow forking the same way as the code. If
it's
not possible, the documentation license is not free. If the FSF requires
copyright assignments to take the forked code back, it's their fault. The
copyright assignments are there to protect the code with FSF's power, not
because it's legally necessary. So, FSF (and RMS): If someone refuses to
assign the copyright for some personal reasons, it's not your business to
complain. You still can use the code. I'm using GFDL for a few documents, too. I use a limited version of the
GFDL, without the non-free stuff - no invariant sections - (though I have
the FSF's back cover text, which is mandatory policy for my official FSF
project. I think it's foolish, because it's inaccurate as soon as someone
forks the project). My suggestion to the GFDL issue is that if you take material, you
either
have to take it *with* all the invariable sections and cover/back cover
texts, or *completely without*, and use a new cover title. That way, the
variable part would still be free. Otherwise, it would be quite
stupid. Cover: "This is the Emacs documentation" by Richard M. Stallman Backcover (mandatory texts): "The FSF prints this manual"
Posted Mar 13, 2005 15:27 UTC (Sun)
by anton (subscriber, #25547)
[Link]
The GFDL does. That's not the problem (as far as I understand it).
Linux will probably have a similar problem with GPLv2-only vs. GPLv3
anyone else find irony in RMS being adament about requiring the GFDL (prohibiting it's use by other projects) and Debian deciding that anything uder this license needs to be removed?A day in the life of emacs
prohibit the use of the docs by other projects. But, it *is* incompatible with otherwise-licensed documentation and, as such, cannot be merged with one of those. IMHO, RMS is right IRT the XEmacs project.GFDL does not...
I guess this is why I will continue to use xemacs and I will never sully the name of Linux with a "GNU" prefix.GFDL does not...
That Richard wants to maintain control over work for which he has the copyright, is not akin to being a dictator in general. The FSF policy is GFDL, and that is what covers the GNU Emacs manual.GFDL does not...
I'm fine with someone sticking to their principals above convenience. InPrincipals
fact, that's one of the best attributes of RMS.
principals. The GFDL is obviously not Free the same as the GPL. RMS has
said this is because documentation is different than software and the rights
which empower software users are not the same for documentation. I have
never found that to be a convincing argument.
The reason that GNU won't take patches from it is because they want copyright
assignments which is of course their perogative but it is unfair to act as
if XEmacs is withholding improvements from others.
I see that you are right about the GPL, and I agree then that the problem is probably copyright assignment. Now that it's not so late at night, I've taken the time to read http://www.xemacs.org/About/XEmacsVsGNUemacs.html, and this verifies the copyright assignment problem.Principals
quote: "... Richard wants to maintain control over [his] work ..."GFDL does not...
Somehow, the XEmacs people have a different story of the history between the two projects. Given that RMS is refusing to cooperate now, I tend to look askance on any claim that all failures to cooperate in the past have been XEmacs's fault.GFDL does not...
GFDL does not...
GFDL does not...
Those of you who want to read the ``other point of view'' to this biased opinion that it's all XEmacs' fault: Please have a look at http://www.xemacs.org/About/XEmacsVsGNUemacs.html. The author tries hard to give credit to both sides, much to the disdain of jwz.GFDL does not...
This is the second comment that has referred to a concept that "it's all Xemacs' fault," but I don't find that that position actually shows up anywhere in the article or the comments or the article's references.
GFDL does not...
You wrote: ``the fact that RMS isn't willing to contribute even more to the cooperation doesn't mean Xemacs is any less at fault for the lack of cooperation.'' (emphasis by me). This was the reaction to the point of
dvdeug who wrote ``I tend to look askance on any claim that all failures to cooperate in the past have been XEmacs's fault.'' With your statement, you made a contradiction to his scepsis and thus supported the concept that the chism is XEmacs's fault.GFDL does not...
"not any less at fault" is fundamentally different from "completely at fault" or even "somewhat at fault." In fact, I have reserved judgment on who, if anyone is at fault and how much.
GFDL does not...
As a user of CVS Emacs I stumbled over several bugs / inconveniences. RMS RMS is *very* active
was always incredibly fast (~hours) responding
with a working bug fix for his pet-project. And this also applies to some
other developers. I found this really impressive.
Tnoo
Does the CVS version of emacs support attaching a gnuclient/emacsclient from a tty to a gnuserver/emacsserver that was started by an X11 emacs? A day in the life of emacs
No, it does not, but the multi-tty branch does. A day in the life of emacs
See: http://lorentey.hu/project/emacs.html.en
That branch that tracks CVS head very closely supports multiple terminal
and X11 frames at the same time, even terminal frames on terminals
supporting only 8 colors at the same time with terminal frames on
256 color terminals. It works greak.
I don't know why anyone would see Emacs and Vi as opposed. I run Vi from within Emacs, in Viper mode ("M-x viper-mode"). Detailed editing is a lot less stressful and more efficient that way, but I still have easy access to all the Emacs bloat^Wfeatures.
Vi vs. Emacs?
Bet vi still starts up faster though!Vi vs. Emacs?
The fact that X?Emacs doesn't come with the very useful "dot" command is a bit annoying, however, you can get one: see for example http://www.esperi.demon.co.uk/nix/xemacs/site-wide/vi-dot...Vi vs. Emacs?
I don't know why anyone would see Emacs and Vi as opposed.
Vi vs. Emacs?
>[...] many people, including me, believe they cannot efficentlyVi vs. Emacs?
>maintain expertise in both. When I first started using Unix, I knew
>I couldn't afford to learn and keep up with more than one editor
>[...]
exclusively for 15 years, yet I am the person in our group people who
has the most vi expertise, and am second in Emacs expertise.
intensive vi use behind me (and missed some vi features in other
editors), yet I was a productive Emacs user (and fan) after one day or
so. My vi knowledge stays with me, though.
Does anyone (the LWN editor included) know whether GNU Emacs has correct behaviour concerning the X clipboard in this next version?CLIPBOARD vs PRIMARY
Short answer: yes, but it's not on by default.CLIPBOARD vs PRIMARY
Have you looked at climacs?
I find it quite interesting. It is not yet fully functional, but it is under active developement.
Another emacs relative
Is this the one started by the noted net.kook Erik Naggum?Another emacs relative
Naggum is known for being outspoken, but he's hardly a kook. I found his writings on various aspects of language design and computer use to be quite fascinating and insightful.Another emacs relative
No, it's not started by Erik Naggum.Another emacs relative
How about a day in the life of Vim?A day in the life of emacs
Where are my Debian emacs-snapshot packages?A day in the life of emacs
Free software needs free documentation
"No it isn't, it's the XEmacs documentation" by Richard Gabriel
"No it doesn't, because it's a derivative, and BTW: Richard M. Stallman is
an obnoxious guy - Richard Gabriel"
"I'm *not* an obnoxious guy - Richard M. Stallman"
"Yes, you are - Richard Gabriel"
>Therefore, following the rule that free software needs freeFree software needs free documentation
>documentation, the documentation must allow forking the same way as
>the code.
The problem is that the Xemacs manual is under the GPL and thus cannot
incorporate GFDL stuff. If the Xemacs people had assigned their
changes to a governing body (e.g., the FSF:-), changing the license to
a GFDL-compatible one would be easy, but since they have not, they
have to run after all their contributors, or instead get the FSF to
change the license of the text they want to incorporate; since the
latter approach has failed, they have to follow the former, or just
give up on using GNU Emacs text in the Xemacs manual.
licensing.