From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12450: Remove configure's --without-sync-input option. Date: Sun, 16 Sep 2012 13:43:10 +0300 Message-ID: <83392is0xt.fsf@gnu.org> References: <50543449.1070306@cs.ucla.edu> <83k3vvtyw0.fsf@gnu.org> <50559CF9.1060605@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1347792240 4684 80.91.229.3 (16 Sep 2012 10:44:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Sep 2012 10:44:00 +0000 (UTC) Cc: lekktu@gmail.com, eggert@cs.ucla.edu, 12450@debbugs.gnu.org To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 16 12:44:03 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TDCKZ-0002dM-3s for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Sep 2012 12:44:03 +0200 Original-Received: from localhost ([::1]:38446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDCKV-0006ki-3h for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Sep 2012 06:43:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDCKS-0006kV-5w for bug-gnu-emacs@gnu.org; Sun, 16 Sep 2012 06:43:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TDCKQ-0000pQ-Te for bug-gnu-emacs@gnu.org; Sun, 16 Sep 2012 06:43:56 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TDCKQ-0000pG-Q6 for bug-gnu-emacs@gnu.org; Sun, 16 Sep 2012 06:43:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TDCLW-0000Wn-4t for bug-gnu-emacs@gnu.org; Sun, 16 Sep 2012 06:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Sep 2012 10:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12450 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12450-submit@debbugs.gnu.org id=B12450.13477922601973 (code B ref 12450); Sun, 16 Sep 2012 10:45:02 +0000 Original-Received: (at 12450) by debbugs.gnu.org; 16 Sep 2012 10:44:20 +0000 Original-Received: from localhost ([127.0.0.1]:36524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDCKp-0000Vl-NN for submit@debbugs.gnu.org; Sun, 16 Sep 2012 06:44:20 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:51982) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDCKm-0000Vb-2O for 12450@debbugs.gnu.org; Sun, 16 Sep 2012 06:44:17 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MAF00500US46C00@a-mtaout20.012.net.il> for 12450@debbugs.gnu.org; Sun, 16 Sep 2012 13:43:06 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAF004NKV3UJXO0@a-mtaout20.012.net.il>; Sun, 16 Sep 2012 13:43:06 +0300 (IDT) In-reply-to: <50559CF9.1060605@dancol.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64411 Archived-At: > Date: Sun, 16 Sep 2012 02:33:45 -0700 > From: Daniel Colascione > CC: Paul Eggert , 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).