bug#74488: Why not modernize Emacs

[Eli Zaretskii]

> Cc: 74488@debbugs.gnu.org
> From: Raj Divecha <rjd1977tech@icloud.com>
> Date: Mon, 25 Nov 2024 17:58:44 +0000 (UTC)
> 
> I wish I could contribute but unfortunately I am stuck with my bread
> & butter job. I am a seasoned systems engineer and mostly work on
> C/C++/Python, validating features of various ICs that my company
> manufactures and I know if I want I can work on this non-trivial
> change but at the end of the day my bread & butter job takes
> priority over everything else. Just out of curiosity, what will it
> take to get this done? Is there a document I can review and get a
> feel for the amount of work? And approximately, how many engineers
> do you think are needed to work on this and the different expertise
> required?

That depends on what is the scope of the work.  This is not a single
monolith job that cannot be subdivided into smaller ones.  So the
first step towards answering your questions is to identify those
smaller parts and steps, and then prioritize them.  When that is
done, we could try estimating the effort required for the most
important parts.

> LISP is kind of dead and the users might need Python to
> customize their interface, thus, I believe both LISP and Python will
> have to be supported simultaneously.

That just makes the bar higher, IMO.  It is easy to extend Emacs by
writing Lisp programs; doing that in Python is currently impossible,
and will need a non-trivial development of the required
infrastructure.