2 ms·

You're ignoring that a lot more work needs to be done in GNU Emacs, and that's another program under RMS's stewardship, and one where he could be much more obst

by hga 12y ago

You're ignoring that a lot more work needs to be done in GNU Emacs, and that's another program under RMS's stewardship, and one where he could be much more obstructive. The only outstanding threat to fork that I know of is coming from a GNU Emacs maintainer, to I believe fork GNU Emacs. Again. Oh boy, again to support C++ development! How could I have forgotten that?!?!?!!! But you're right, arguing with RMS on this is likely to be completely unproductive. But it is morally necessary before potentially disastrous forking of GNU Emacs and maybe GCC.

nanolith 12y ago
Actually, I didn't ignore that in my original comment. I mentioned that the GNU Emacs work should make use of a file format which is independent of the plugin work. There is no reason why GNU would refuse to mainline such an enhancement if it had merits outside of the GCC dependency. RMS wishes to restrict possible proprietary use of the GCC front-end. That's his prerogative. However, he can't prevent the existence of such a tool. He can only prevent it from being mainlined. EDIT: Also, it may be easier to make a case for mainlining if the functionality is demonstrable. As I've learned throughout my career, it's often better to ask forgiveness than to ask permission. RMS excels in the idealistic and theoretical. If he has to consider the practical -- such as whether to mainline already existing functionality -- then he may find ways of suggesting changes to the plugin than ways of saying "no."
- hga 12y ago
  "There is no reason why GNU would refuse to mainline such an enhancement if it had merits outside of the GCC dependency" Except everyone who knows RMS well enough knows he'd be extremely obstructionist and indeed GNU would refuse to maintain/mainline such an GNU Emacs enhancement. That's one of the reasons I believe the GNU Emacs maintainer threatened to fork it, he obviously knows RMS well enough. (So do I in the 1979 to late '80s period, and he's not changed in this sort of thing. And he was reliably reported to be like this before I showed up on the scene, by among others one of the two initial ITS TECO EMACS beta-testers. And others I knew less well.)

by hga 12y ago

nanolith 12y ago

Actually, I didn't ignore that in my original comment. I mentioned that the GNU Emacs work should make use of a file format which is independent of the plugin work. There is no reason why GNU would refuse to mainline such an enhancement if it had merits outside of the GCC dependency. RMS wishes to restrict possible proprietary use of the GCC front-end. That's his prerogative. However, he can't prevent the existence of such a tool. He can only prevent it from being mainlined. EDIT: Also, it may be easier to make a case for mainlining if the functionality is demonstrable. As I've learned throughout my career, it's often better to ask forgiveness than to ask permission. RMS excels in the idealistic and theoretical. If he has to consider the practical -- such as whether to mainline already existing functionality -- then he may find ways of suggesting changes to the plugin than ways of saying "no."

hga 12y ago
"There is no reason why GNU would refuse to mainline such an enhancement if it had merits outside of the GCC dependency" Except everyone who knows RMS well enough knows he'd be extremely obstructionist and indeed GNU would refuse to maintain/mainline such an GNU Emacs enhancement. That's one of the reasons I believe the GNU Emacs maintainer threatened to fork it, he obviously knows RMS well enough. (So do I in the 1979 to late '80s period, and he's not changed in this sort of thing. And he was reliably reported to be like this before I showed up on the scene, by among others one of the two initial ITS TECO EMACS beta-testers. And others I knew less well.)