Re: `~/.xemacs/{init,.options}.el' (Was: Re: [XEmacs] New Maintainer, soonish.)
Please don't take this as a flame. It's not intended that way. You
do good work. I just disagree with you here and I hope have some
reasonable arguments. Take this as IMO, FWIW.
Also, bear in mind that I've been dealing with a debian emacsen for a
while and I have at least some idea of how much trouble aggravating
the existing emacs user base can get you in :>
Finally, I know this is not a black and white issue. If nothing else
it would be good to come to some sort of concensus about this issue.
karlheg@cathcart.sysc.pdx.edu (Karl M. Hegbloom) writes:
> I disagree, and will ship the package with the modification. Don't
> bother filing a bug about it... This is a minor change, not a hairy
> major code fork. It's not a meaningful political act, just part of
> the job I'm doing.
You've probably heard this before, but this makes me uncomfortable. I
feel you're changing XEmacs default behavior in *highly* user visible
ways that will only apply on Debian systems. This really feels like
something that the upstream XEmacs developers should implement (or
accept as a patch from you) rather than a decision you make for them.
What if the user has an NFS shared home directory among Debian and
non-Debian systems? Here on the campus machines, we do. Sometimes
when they launch xemacs, it'll do one thing, and sometimes another.
I'm not saying this is the likely case, but there's a whole raft of
possiblities that you may never have considered that could make your
changes at best annoying, and at worst dangerous. You're taking on a
lot of responsibility by shipping your personal modifications to
thousands of Debian users.
Of course, it's a fine line, that between what's an OK modification
for packaging and what's upstream "meddling". We have to make changes
to bring a package into conformance with Debian's structure all the
time, but I think it's best to be fairly conservative about this.
Perhaps the more visible the change (especially to the user), the more
conservative we should be.
In the end it's your package, and unless a *lot* of other developers
disagree with you, you can do what you want, but since you haven't
maintained an emacsen before, I'd suggest that changes like this may
elicit you substantial grief, and also consider carefully the
possibility that some non-standard changes can hurt Debian's public
reputation if/when upstream maintainers start getting problem reports
from users who are running a non-standard version of their program.
It's important to try to avoid usurping the upstream authors'
authority. However, if after weighing all that, you still think you
need to make that change, then so be it.
> GNU Emacs and (by default) XEmacs will write `customize' options
> into the .emacs file. The two editors are not completely
> compatible, and some people will install both versions. It's not
> difficult to source your old ~/.emacs from init.el if you like.
> The `custom-file' can be changed if you like, also.
I'd tend to say that this is something for the emacs and xemacs
development teams to work out upstream if they wish. The furthest I'd
be likely to go (thinking out loud here) would be to perhaps add a
/usr/doc/emacsen-common/README.make-emacs-xemacs-play-nice.gz which
details the conflicts and suggests what the user can do about them.
We can also send this file to the emacs/xemacs developers so they can
resolve the issues if they want to.
> I will, after developing something that works and looks good, submit
> patches "upstream", for certain. They will be reviewed, and perhaps
> will become part of XEmacs 21.2 or 21.3, depending upon timeing and
> whatever-it-takes. It's not a strange new idea.
The key here is *perhaps*.
I agree that this is what you should do, but then you should wait
until/unless your changes are accepted upstream before cramming them
into the Debian version. Even if you just wait for a "OK, we're
putting that into the current CVS tree". What if the upstream people
reject them and announce in no uncertain terms that they don't want
their program to work that way? What if most of the existing user
base agrees with them? Now you'd have a fork.
> I've also decided to put the Debian swirl into the splash screen,
> superimposed over the standard XEmacs logo, and quantized to our
> standard color map. (The blue XEmacs doesn't look quite as nice;
> it's a brighter blue now, but at least it won't eat as many colors
> as it did, for people with hand-me-down PC's that only do 8bpp.)
> I've also set the `gc-pointer-glyph' to the swirl. (It's a nice
> enough looking recycle sign.) You will still be able to override
> the gc-pointer with an X resource or code in your init.el, of
> course.
It's your package, but I can see how some developers might call this
cart-leading-the-horse downstream re-programming. It's free-software,
so you can do what you want, but I think out of respect for the
authors, you should strongly consider going through their channels to
get your improvements accepted when they're substantial behavior
changes.
As a user, I don't think I'd actually want any of the changes you've
suggested made to emacs (unless they became the upstream standard
first), but I don't use or maintain xemacs, so it's not an issue I
have to confront.
At the very most, I'd want the Debian logo to only appear if I
installed a debian-xemacs-startup-logo package or something. Note
that we don't even put the penguin/swirl on the boot up screen unless
someone installs debian-logo. Should every program have the swirl on
their startup screen? Even Windows doesn't do that...
Perhaps I'm just being a curmudgeon.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: