* 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* Re: Be prepared for "code clean-up" in CVS head
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
2 siblings, 0 replies; 10+ messages in thread
From: Juanma Barranquero @ 2003-03-04 16:06 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Be prepared for "code clean-up" in CVS head
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-10 18:32 ` Stefan Monnier
2003-03-05 20:47 ` Richard Stallman
2 siblings, 2 replies; 10+ messages in thread
From: Jan D. @ 2003-03-04 17:23 UTC (permalink / raw)
Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Be prepared for "code clean-up" in CVS head
2003-03-04 17:23 ` Jan D.
@ 2003-03-05 20:47 ` Richard Stallman
2003-03-05 21:49 ` Luc Teirlinck
2003-03-06 4:27 ` Eli Zaretskii
2003-03-10 18:32 ` Stefan Monnier
1 sibling, 2 replies; 10+ messages in thread
From: Richard Stallman @ 2003-03-05 20:47 UTC (permalink / raw)
Cc: storm
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Be prepared for "code clean-up" in CVS head
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
1 sibling, 1 reply; 10+ messages in thread
From: Luc Teirlinck @ 2003-03-05 21:49 UTC (permalink / raw)
Cc: storm
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Be prepared for "code clean-up" in CVS head
2003-03-05 21:49 ` Luc Teirlinck
@ 2003-03-07 19:41 ` Richard Stallman
0 siblings, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2003-03-07 19:41 UTC (permalink / raw)
Cc: storm
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Be prepared for "code clean-up" in CVS head
2003-03-05 20:47 ` Richard Stallman
2003-03-05 21:49 ` Luc Teirlinck
@ 2003-03-06 4:27 ` Eli Zaretskii
2003-03-17 5:49 ` chad Brown
1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2003-03-06 4:27 UTC (permalink / raw)
Cc: jan.h.d
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Be prepared for "code clean-up" in CVS head
2003-03-06 4:27 ` Eli Zaretskii
@ 2003-03-17 5:49 ` chad Brown
0 siblings, 0 replies; 10+ messages in thread
From: chad Brown @ 2003-03-17 5:49 UTC (permalink / raw)
Cc: emacs-devel
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
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Be prepared for "code clean-up" in CVS head
2003-03-04 17:23 ` Jan D.
2003-03-05 20:47 ` Richard Stallman
@ 2003-03-10 18:32 ` Stefan Monnier
1 sibling, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2003-03-10 18:32 UTC (permalink / raw)
Cc: Kim F. Storm
> > 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Be prepared for "code clean-up" in CVS head
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
2 siblings, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2003-03-05 20:47 UTC (permalink / raw)
Cc: emacs-devel
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.
^ 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).