4 ms·
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
by 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.)