GNU bug report logs -
#12450
Remove configure's --without-sync-input option.
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Sat, 15 Sep 2012 07:57:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
Message #77 received at 12450 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 16 Sep 2012 02:33:45 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: Paul Eggert <eggert <at> cs.ucla.edu>, lekktu <at> gmail.com,
> 12450 <at> 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).
This bug report was last modified 12 years and 249 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.