Re: Be prepared for "code clean-up" in CVS head

Re: Be prepared for "code clean-up" in CVS head

[Juanma Barranquero]

On 04 Mar 2003 17:11:47 +0100, storm@cua.dk (Kim F. Storm) wrote:

> I think it is about
> time that some of the (extensive) code-duplication between the X, W32,
> and MAC ports is cleaned up.

Cool.

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

[...]

> WDYT?

IMHO, the "cross-GUI hybrid" would be difficult to implement right,
difficult to maintain and only marginally useful. I fear if we tried to
make it work we'd be hunting redisplay bugs for years to come. If
renouncing to it *helps* simplicity and cleanliness, more power to us.


                                                           /L/e/k/t/u

Be prepared for "code clean-up" in CVS head

[Kim F. Storm]

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?

Re: Be prepared for "code clean-up" in CVS head

[Jan D.]

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

There is a lot of duplication between macmenu.c, w32menu.c and xmenu.c
There are many functions in all three that deals with taking apart
a menu specification, allocating menu entries and walking through
Lisp structures that are line by line identical.  There is not a
line of GUI code in them.

> 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 think this might be a lot of work, and it is of course harder to
maintain each port independently.

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

Just getting rid of duplication of non-GUI related code would be
a major step forward.

About code cleanup, how about removing the pure X (i.e. not Xt, not GTK)
parts?  That would not reduce the duplication but would remove a lot
of #ifdef:s.  Is there a configuration that has X but not Xt?

	Jan D.

Re: Be prepared for "code clean-up" in CVS head

[Richard Stallman]

Your plans all sound good to me.

    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, 

This could only be useful on non-free platforms like Windows.  We
should not hold back major cleaning up and improving Emacs just to
cater to Windows better.  Windows support is ok, but that should not
get in the way of other things.

Re: Be prepared for "code clean-up" in CVS head

[Richard Stallman]

    About code cleanup, how about removing the pure X (i.e. not Xt, not GTK)
    parts?  That would not reduce the duplication but would remove a lot
    of #ifdef:s.  Is there a configuration that has X but not Xt?

It's not clear that the only reason for the non-toolkit version is to
support configurations that don't have Xt.  (I don't think there ever
were any such.)  There might be users who prefer the non-toolkit
version.

However, they are probably few, and maybe it is ok to delete the
non-toolkit code.  I am not saying I am sure we need to keep it, only
that we shouldn't look at it purely as a question of whether Xt is
available.

Re: Be prepared for "code clean-up" in CVS head

[Luc Teirlinck]

Richard Stallman wrote:

       About code cleanup, how about removing the pure X (i.e. not Xt, not GTK)
       parts?  That would not reduce the duplication but would remove a lot
       of #ifdef:s.  Is there a configuration that has X but not Xt?

   It's not clear that the only reason for the non-toolkit version is to
   support configurations that don't have Xt.  (I don't think there ever
   were any such.)  There might be users who prefer the non-toolkit
   version.

   However, they are probably few, and maybe it is ok to delete the
   non-toolkit code.  I am not saying I am sure we need to keep it, only
   that we shouldn't look at it purely as a question of whether Xt is
   available.

The main reason I know of to want non-toolkit scroll-bars (but just
scroll bars, i.e. configuring using 
./configure --without-toolkit-scroll-bars) is to be able to split
windows using C-mouse-2.  It is unclear to me whether this would be
affected by the proposed changes.  (If not, then of course this remark
is irrelevant.)

Sincerely,

Luc.

Re: Be prepared for "code clean-up" in CVS head

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 05 Mar 2003 15:47:30 -0500
> 
>     About code cleanup, how about removing the pure X (i.e. not Xt, not GTK)
>     parts?  That would not reduce the duplication but would remove a lot
>     of #ifdef:s.  Is there a configuration that has X but not Xt?
> 
> It's not clear that the only reason for the non-toolkit version is to
> support configurations that don't have Xt.  (I don't think there ever
> were any such.)  There might be users who prefer the non-toolkit
> version.

The DJGPP (a.k.a. DOS) port of Emacs uses the non-toolkit part of the
xmenu.c code.

Re: Be prepared for "code clean-up" in CVS head

[Richard Stallman]

    The main reason I know of to want non-toolkit scroll-bars (but just
    scroll bars, i.e. configuring using 
    ./configure --without-toolkit-scroll-bars) is to be able to split
    windows using C-mouse-2.  It is unclear to me whether this would be
    affected by the proposed changes.

It would be nice if we could make Emacs handle scroll bar clicks
that the scroll bar itself does not have a meaning for.  Is there any way
of doing that?

Re: Be prepared for "code clean-up" in CVS head

[Stefan Monnier]

> > 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.
> 
> There is a lot of duplication between macmenu.c, w32menu.c and xmenu.c
> There are many functions in all three that deals with taking apart
> a menu specification, allocating menu entries and walking through
> Lisp structures that are line by line identical.  There is not a
> line of GUI code in them.

Yes, we need to kill that duplicated code.

> > 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 think this might be a lot of work, and it is of course harder to
> maintain each port independently.

I don't think merging all the duplicated code will make it harder
to eventually get multi-GUI support.  It might even make it easier
in some places.  And the real problems will be the same anyway.

> About code cleanup, how about removing the pure X (i.e. not Xt, not GTK)
> parts?  That would not reduce the duplication but would remove a lot
> of #ifdef:s.  Is there a configuration that has X but not Xt?

--with-x-toolkit=no will give you that.
I don't know how many people use such a config, tho.


	Stefan

Re: Be prepared for "code clean-up" in CVS head

[chad Brown]

For what it's worth, I always use --without-toolkit-scroll-bars; I 
vastly prefer the results. *shrug*

chad


On Wednesday, Mar 5, 2003, at 23:27 US/Eastern, Eli Zaretskii wrote:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Wed, 05 Mar 2003 15:47:30 -0500
>>
>>     About code cleanup, how about removing the pure X (i.e. not Xt, 
>> not GTK)
>>     parts?  That would not reduce the duplication but would remove a 
>> lot
>>     of #ifdef:s.  Is there a configuration that has X but not Xt?
>>
>> It's not clear that the only reason for the non-toolkit version is to
>> support configurations that don't have Xt.  (I don't think there ever
>> were any such.)  There might be users who prefer the non-toolkit
>> version.
>
> The DJGPP (a.k.a. DOS) port of Emacs uses the non-toolkit part of the
> xmenu.c code.
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
>