Remacs: Is there a policy for C/Elisp patches?

[Fuco1]

Say I want to fix a bug in C or Elisp, do you accept these patches or are they generally avoided?

For obvious reasons it would be much simpler to get them merged here than upstream :/

But if we decide to go that route it might eventually lead to bigger split from GNU Emacs than just "replacing C with Rust" as the features themselves would start to split.

[Wilfred]

My preference would certainly be to get them merged upstream. We do sync with upstream periodically, and C/elisp patches increase the chance of conflicts.

We do have some elisp patches, such as teaching Emacs to find definitions of primitive functions in Rust. We also have some C patches, to help interoperation (e.g. removing static from C functions to expose them to Rust.

If it's an unambiguous optimisation or bug fix, then we would preserve the property that Remacs is a drop-in replacement for GNU Emacs trunk. I suppose we could do that if we wanted.

I think C patches would be less problematic, because user lisp is less affected.

Did you have any specific patches on mind? Do you have copyright assignment sorted out?

[Fuco1]

I have the CA but so far I couldn't get anything into Emacs :D Of all the patches I submitted they never even shown up in the list, so I gave up.

I don't have anything in mind yet, but just philosophically I was thinking about it and how this project could/should/would evolve. There are people who might contribute quality features but are simply unwilling for their own reasons to work with FSF, and I was thinking what would happen if this project tried to accommodate them. Basically creating a less-bullshit contribution environment.

I suppose, what I'm saying is if there is a want to become XEmacs 2.0. So some light policy note somewhere wouldn't hurt.

[Wilfred]

If you have a patch, do open a PR, and we can discuss :)

(As an aside: In my experience, the best way to contribute to GNU Emacs is to ask for commit access. If you get access to GNU ELPA, you can commit to Emacs itself too.

For uncontroversial patches, just commit them directly to master. My understanding of the mailing list etiquette is that you post to the list, consider people's opinions wherever possible, and then commit. You don't (or often can't) have to make everyone happy.)