2 ms·

Typically, it's not a good idea to argue with RMS. The pragmatic approach would be to just write the plugin for GCC, and keep it separate. GNU can certainly c

Typically, it's not a good idea to argue with RMS. The pragmatic approach would be to just write the plugin for GCC, and keep it separate. GNU can certainly control what is mainlined, but the GPL is not violated simply by creating a GPL plugin that provides a useful output target. If Emacs were enhanced to support a standardized file format which contains the relevant information, then it could accept this format from any tool. The GCC plugin could output this format, as could Clang/LLVM. Because the format is universal, it likely would be mainlined. Then, it's up to the user. If the user wants to integrate the two, the user can apply the appropriate patch to GCC to incorporate this independent plugin. Likely, many downstream package maintainers would add this as a standard option if demand were high enough. This is the very freedom that RMS has advocated for. It can be done without poking the bear.

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.)

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.)