Re: [Emacs-diffs] trunk r117464: Shrink Lisp_Sub_Char_Table by preferring C integers to Lisp_Objects.

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Date: Thu, 03 Jul 2014 14:01:30 +0900
> Cc: Stefan Monnier <address@hidden>, address@hidden
> 
> > Of course, an universal Eli-style "we don't need nano-improvements" argument
> > makes all of the above just a nonsense.
> 
> Eli's been a little cranky, but he does have a point.

Yes, cranky is my middle name, especially after reading too much stuff
that gets me irritated.  Too late to change that, so all I can say is
sorry, and try harder to keep my crankiness at bay.

> However, if you never have more than an hour to devote to Emacs at one
> time, and typically those hours are spread far enough apart that your
> short-term memory is guaranteed to time out, working on the ambiguous
> problems of extending functionality to new areas is going to be
> painful unless you're extremely good at picking up exactly where you
> left off.  Optimizing existing functionality may be a better use of
> your time.

There are simple devices to overcome those difficulties.  Like keeping
notes or recording easy-to-forget details in the commit logs of your
feature branch.  Having been there, I don't think this is such a big
problem, nor that it's the root cause for the proliferation of
"nano-improvements".

> Nevertheless, please consider Eli's line of argument carefully, and at
> least don't make fun of it.

Thank you.

I'm arguing that with the amount of developmental energy we have at
our disposal (an average of 250 commits per month lately, more than
4000 per last year!), I would expect the project to gain significant
new functionality much faster than what we see in etc/NEWS.  As a
simple thought experiment, I suggest to read etc/NEWS entries for the
last 2 or 3 releases and make a list of the important functionality
and usability changes you see there.  Then reflect on the number of
those changes.