On 9/15/12 2:32 AM, Eli Zaretskii wrote:
> In what ways does the current SYNC_INPUT code get in the way of
> improving Emacs, and what kinds of improvement will significantly
> benefit from the proposed changes?

> It reminds me of the sorry state of roads in my country, which are 
> permanently in a state of being "maintained for future
> improvements", causing closure of some of the lanes and generally
> making the traffic more jammed than it needs to be.

Working on the the Emacs core is like doing road work in an old city
filled with catacombs, unmapped utility lines, and ancient Roman
sewers under the streets. Work is slow and fraught become nobody
really understands what's going on, and nobody really understands
what's going on because nobody works on it.

Paul's doing a great job reducing a lot of the low-level complication
in the code. In particular, his work would have simplified my patches
yet-unmerged for launching children via posix_spawn and having Emacs
not poll every few seconds while blocked and waiting for input. Both
are good user-level features.

> As we no longer have on board people who
> really understand the Emacs event handling
> on MS-Windows, such an investigation will
> take a lot of time and effort

I've done some work on that code for my cygw32 patchset, an updated
version of which I'll post shortly (as soon as I sit down and write
the myriad Changelog entries I need).

The MS-Windows support in Emacs, by the way, is a microcosm of the
problem I mentioned above. We really need to stop support for Windows
9x and non-UNICODE systems if we're to simplify the code enough to fix
nagging problems, like persistent flickering on tooltip updates. I'm
also much less motivated to add features (like rich copy-and-paste
support) when I have to go dig up Windows 95 documentation and
translate it from the ancient Sumerian in order to figure out whether
the code I'm writing might break when the Museum of Computing tries to
run a modern Emacs on one of its exhibits.