Re: [PATCH] Add prettify symbols to python-mode

[Eli Zaretskii]

> Date: Wed, 23 Sep 2015 22:12:30 +0800
> From: Xue Fuqiao <address@hidden>
> Cc: Achim Gratz <address@hidden>, Emacs-devel <address@hidden>
> 
> On Wed, Sep 23, 2015 at 3:13 PM, Eli Zaretskii <address@hidden> wrote:
> 
> > One of the gravest problems I see for the future of Emacs development
> > is that we slowly but steadily lose old-timers who know a lot about
> > the Emacs internals and have lots of experience hacking them, whereas
> > the (welcome) newcomers mostly prefer working on application-level
> > code in Lisp.  If this tendency continues, we will soon lose the
> > ability to make deep infrastructure changes, i.e. will be unable to
> > add new features that need non-trivial changes on the C level.
> 
> Yes, this is also what I see.  As a "newcomer" (in comparison with most
> Emacs hackers on this list, who have been contributing to Emacs for much
> longer than me, and have a deeper understanding of the system as a
> whole), some possible causes for this problem are:
> 
> * Hacking on the C level is inherently more difficult than the Lisp
>   (application) level.

I don't see why.  C is not a complicated language, and a large part of
the Emacs source code never touches its relatively more problematic
parts, like memory allocation.

> * Perhaps our effort on (info "(elisp) GNU Emacs Internals") is not
>   enough.  (Although it's almost impossible to document the ins and outs
>   of the Emacs Lisp interpreter, the redisplay code, and other C
>   infrastructure in Emacs, let alone having them updated.)

This is a red herring: the C-level internals are extensively
documented in comments to the respective source files.  Many source
files have large commentaries at their beginning describing their
design and implementation.  Having those in Texinfo will not change
anything.

If someone comes up with a list of specific design aspects that are in
their opinion under-documented, post them.  I'd be surprised to see
there anything that someone active here can tell which isn't already
in the comments, but who knows.

> * There is a deeper going split between the core developers and the rest
>   of the community (this one is not specific to C/Lisp, and has many
>   technical and non-technical reasons).

So not really relevant to the issue at hand.

> * Many times, discussions on emacs-devel are defensive rather than
>   constructive (not specific to C either).

Likewise.

> * Emacs runs on all versions of Windows from Windows 98 and Windows NT
>   4.0 through to Windows 10, and even MS-DOS (although msdos.c is pretty
>   easy to read).  I'm not sure whether the maintenance burden is worthy.

No one needs to hack on code specific to these platforms if they don't
feel like it.  Our problem is falling behind on Posix platforms, not
on the rest of them.  Most of the Emacs internals are
platform-independent anyway.  Just pretend that this issue doesn't
exist.

> Currently, I don't have any concrete proposal to figuring out a
> practical solution, but I'll do my bit and try to improve Emacs's
> condition.

There's no other practical solution except volunteering and getting
your hands dirty.  Knowledge and experience will come with time.