bug#12450: Remove configure's --without-sync-input option.

[Eli Zaretskii]

> Date: Sun, 16 Sep 2012 02:33:45 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: Paul Eggert <eggert@cs.ucla.edu>, lekktu@gmail.com, 
>  12450@debbugs.gnu.org
> 
> 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.

That's an exaggeration.  Just a year ago I finished working on a major
change in the display engine.  I do understand the code I changed.

I'm quite sure that Stefan has similar, if not better, understanding
of the parts he changed to introduce lexical binding.

> Paul's doing a great job reducing a lot of the low-level complication
> in the code.

I agree.  But where the code we change is not understood well, let
alone related to platforms Paul doesn't use and doesn't care about,
peer review and commentary are in order.  I see nothing in this
process that is extraordinary; do you?

> 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.

That's good to hear.  However, simplification of the code is not a
goal in itself.  The simplified code should be correct, first and
foremost.  That is what this discussion is about, at least as far as
I'm concerned

> 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 don't see any relation between non-Unicode APIs and flickering.  If
you can explain how they are related, please do.

> 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.

I already suggested a way of dealing with that: introduce new features
conditioned on a run-time test of a variable, which will only be
non-zero on the latest versions of Windows.  There's no requirement to
have every new feature work on Windows 9X; the only requirement is to
try not to break existing features that already work there (and even
that requirement is not non-negotiable).