Eli Zaretskii wrote:
> I've reviewed the changes you pushed to master for fixing this bug,
> and I must say that most of them look like purely stylistic changes,
> to make the code more to your personal liking.  The actual bugs were
> very few and minor, and didn't necessitate such thorough changes.

The changes were motivated by bug fixes, not style. Although the bugs were 
mostly minor (e.g., generating bogus NUL bytes due to miscounting) it's fine to 
fix minor bugs. I did change nearby style (indenting as per GNU style, switching 
some locals to C99-style decl-after-statement, etc.) but none of the changes 
were pervasive or were intended for the emacs-25 branch, and it's fine to make 
such changes in master.

One of the bugs was O(N**2) performance when reallocating a temporary buffer. 
While I was at it, I changed the code to allocate a small temp buffer on the 
stack to avoid a malloc/free in the usual case, which should be a small win. 
This accounts for many changes that a quick glance might give the mistaken 
impression of being stylistic.

> without any comments as to why we handle the input string as
> multibyte for the rest of the function, I think this will confuse
> someone down the road.

OK, I added some comments along those lines (see attached patch).

> I think the refactoring already introduced a
> regression.

This comment appears to be about changes made in May for Bug#23425, not about 
code changes I made recently. The May changes were not a regression; they were 
intended and are documented in etc/NEWS. Alan Mackenzie felt strongly that some 
changes were needed in this area. See commit 
433d366dc7b053048abf710d790ff62421dd1570.

> maybe we should just go to the original code, after fixing the
> immediate bugs, as I proposed in a patch yesterday?

No, the code in master should be uniformly better than what's in emacs-25.

It would be nice to have good tests for substitute-command-keys, of course. (We 
can all add this to our lists of things to do. :-)