Re: Development Speed

[Stefan Monnier <monnier@iro.umontreal.ca>]

> In the same vein, my thought at least, it was more about making the code
> more standard compliant, predictable, rather than specific features.

I'd be surprised if the compliance (or not) of Emacs's C code with
specific versions of the C standard would make any difference to
a newcomer.

The difficulty in our C code comes from various aspects, none of which
have much to do with the C language itself:
- The use of macros to wrap accesses/definitions of Lisp data/functions.
  REmacs had a slightly better story there, but still with the same "this
  is not your vanilla Rust code" problem.
- The actual logic of the code.
- The cruft accumulated over the years.
- The impact of the (conservative) GC which implies that things aren't
  always what they appear to be (e.g. when our string compaction moves
  string data under the feet of unsuspecting C code).

Over the years, we've managed to reduce the use of macros (replaced by
inlinable functions) to some extent, partly thanks to improvement in
compilers, but it didn't change much to the code overall.

> I can't see how this is something to ask over small patches, as
> in a patch that says "Make these few lines of code C17 compliant"
> wouldn't mean much without a plan.

If you describe a concrete problem linked to being "not C17 compliant",
then maybe we can start thinking about a plan.  But so far all I've seen
is "compliance for its own sake".

I don't even know of any single place where we're not "C17 compliant".


        Stefan