From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Be prepared for "code clean-up" in CVS head Date: 04 Mar 2003 17:11:47 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5x3cm3p0vw.fsf@kfs2.cua.dk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1046791010 6764 80.91.224.249 (4 Mar 2003 15:16:50 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 4 Mar 2003 15:16:50 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Mar 04 16:16:48 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18qE9C-0001i2-00 for ; Tue, 04 Mar 2003 16:16:02 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18qESb-0001ra-00 for ; Tue, 04 Mar 2003 16:36:05 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18qE89-0008As-01 for emacs-devel@quimby.gnus.org; Tue, 04 Mar 2003 10:14:57 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18qE7Y-0007m8-00 for emacs-devel@gnu.org; Tue, 04 Mar 2003 10:14:20 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18qE7N-0007Pz-00 for emacs-devel@gnu.org; Tue, 04 Mar 2003 10:14:09 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18qE68-0006V5-00 for emacs-devel@gnu.org; Tue, 04 Mar 2003 10:12:52 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id CA0F77C012 for ; Tue, 4 Mar 2003 16:12:47 +0100 (CET) Original-To: emacs-devel@gnu.org Original-Lines: 57 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:12091 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12091 I've finally found some time to look into two of my to-do list items: 1) making the fringes configurable on a per-window basis, rather than just on a per-frame basis. 2) moving the fringe from "outside display margin" to "between display margin and text area". While working on item 1), I'm looking into making the scroll-bar configurable on a per-window basis too (that is pretty much already working for me here under X). As an added bonus (and proof of concept), I plan to make a new "auto-show-scroll-bars" mode which will make the scroll bar visible only when the window needs it. Now, since I can foresee that I need to make many practically identical changes to the X, W32 and MAC ports, I think it is about time that some of the (extensive) code-duplication between the X, W32, and MAC ports is cleaned up. We discussed this some time ago, and it was put on hold, as it was envisioned that the GTK toolkit efforts would somehow obsolete that work. Since GTK support is now installed -- but as an X-specific option -- the original task still remains. I don't intend to make a lot of changes to identify and merge duplicate code, but I will at least merge the code and definitions that are related to the changes I'm going to make to facilitate the "fringe/margin swap" and the per-window configurations. As far as I can see, most of the changes will be related to the *term.c, *term.h, *fns.c, and frame.h files. For merged code, I plan to move it into frame.c or xdisp.c, but I may decide to add comfns.c and comterm.c files and move some code into those if the amount of common code is significant. On a closely related matter, it seems that some corners of the code _could_ work with multiple GUI output devices, e.g. W32 and X, but many parts of the code definitely does not support that, particularly much of the code ported to W32 and MAC uses the X-specific names of both functions and #defines, and they also defines structs and types to match the X-specific names... So it is hard for me to see how they can co-exist without a really MAJOR cleanup. If we decide that we DO NOT want to support such cross-GUI hybrids, a lot more of the duplicate code could be cleaned up. I don't really care whether such cross-GUI hybrids is possible, but I do care about making emacs easier to maintain -- and the current code duplication is a major hazzle in that respect. So if we decide not to support the cross-GUI hybrids, I think I can cleanup a good deal more of (almost) duplicated code. WDYT?