unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Be prepared for "code clean-up" in CVS head
@ 2003-03-04 16:11 Kim F. Storm
  2003-03-04 16:06 ` Juanma Barranquero
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Kim F. Storm @ 2003-03-04 16:11 UTC (permalink / raw)



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?

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2003-03-17  5:49 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-04 16:11 Be prepared for "code clean-up" in CVS head Kim F. Storm
2003-03-04 16:06 ` Juanma Barranquero
2003-03-04 17:23 ` Jan D.
2003-03-05 20:47   ` Richard Stallman
2003-03-05 21:49     ` Luc Teirlinck
2003-03-07 19:41       ` Richard Stallman
2003-03-06  4:27     ` Eli Zaretskii
2003-03-17  5:49       ` chad Brown
2003-03-10 18:32   ` Stefan Monnier
2003-03-05 20:47 ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).