Not sure how to contribute? Here's a grab-bag of stuff
Steve Youngs <steve <at> sxemacs.org>
2013-08-20 00:53:15 GMT
I'm sure some of you may be thinking that you would like to contribute
to SXEmacs, but just don't know where or how or what you can do. Well,
here is a random list of things where you could direct your energies.
They aren't in any particular order. Some won't require any technical
expertise, but others will.
1) Bugs we know about:
For your convenience I have set up some "shared saved searches" at
http://issues.sxemacs.org they are down the bottom in the
"SXEmacs-PreRelease" -- Bugs that prevent a release.
"SXEmacs-Open" -- All unresolved bugs.
"SXEmacs-FeatReq" -- All open feature requests.
So browse through these bugs and feature requests and see if you
can move any along toward resolution.
2) Bugs we don't know about:
Letting us know about bugs is also a good way to contribute. All
you have to do is use SXEmacs and if something goes wrong you let
us know. How hard is that?
BTW, if you add `(setq debug-on-error t)' to the top of your
init.el it will force you to sit up and take notice when things do
go wrong. Alternatively, if you'd rather not find yourself in the
debugger, you could add `(setq stack-trace-on-error t)' to your
SXEmacs and its internals are excellently documented for the most
part, but I'm sure that there are areas where it is lacking. If
you are up to the task we'd love contributions here.
Admittedly, writing documentation requires a deep and thorough
understanding of the thing you are writing about, so this won't be
for everyone. But spelling, punctuation, and grammar are all just
as important too. There are 1496 files in the SXEmacs repo and
pretty much all of them have doc strings. Don't know how to help
the SXEmacs project? Why not see how many typos you can find and
4) Elisp load order (file.elc vs file.el):
When there is a file.el and a file.elc SXEmacs will always load the
.elc, even if the .el is newer. I think that is wrong and the
default should be to load the newest file.
We need to make much more use of emodules and move what we can out
of the C core and into emods. The databases (PgSQL etc), and
multimedia (FFmpeg, SoX, PulseAudio etc) are a couple of areas that
are ripe for this.
We have some issues here right now. SoX is not rewinding streams
(we have a work-around, but the issue is not fixed). Also FFmpeg
is in a mess. I have a branch that updates our FFmpeg code and it
compiles clean, but it crashes HARD. I _think_ it has something to
do with incorrectly using one of their structs/contexts thingies.
Anyway, if you want to help out here make sure you have got my
ffmpeg branch to work from.
We need this. I started working on it and currently SXEmacs will
detect dbus at configure time and even build the emodule. That's
the good news, the bad news is that the emodule is pretty much
completely non-functioning. Plenty of work to be done here (like
the whole lot).
8) XDG related:
It's probably about time we had a decent set of icons to go in
Should SXEmacs look for the user's init.el in
At install time SXEmacs should register itself with as much of the
system's MIME voodoo as it can. Maybe not going as far as setting
it as the default app for everything, but at least being in there.
I think it would be nice also if we could give a user an easy way
to set SXEmacs as the default app for various MIMEtypes from within
9) gnuserv -> elisp:
This has been on our radar (and Nelson's todo) ever since we
implemented server sockets. So if you want to have a crack at this
it would pay you to check with Nelson in case he's got a partially
working prototype in his WD. Failing any takers on this, how 'bout
it Nelson? Lets get this one out the door, yeah?
Some people have had the audacity to say that SXEmacs isn't sexy
enough. Yeah I know right, philistines! But if toolkits and eye
candy are your thing, we'd love to see a ETK SXEmacs, or a Qt
SXEmacs, and as long as I never had to look at it, even a GTK3
SXEmacs. And if SXEmacs could be built with multiple toolkits
that are then selectable at runtime that would be so full of
awesome we'd probably explode.
While on the subject of UI, can we please have a real File/Open
It is about time this moved beyond the "pipe dream" stage. We
already have "worker threads" for things like #'curl:download&, and
#'play-media-stream&, which is very cool and works well. But I
dream of being able to do...
...and have Gnus running in its own thread.
I hear that this is the new kid on the block and is well on its way
to replacing X11. Does anyone know if we need to do anything to
support Wayland? I'm pretty certain that Wayland can and does let
you run "legacy" X applications, but I wonder if there is some sexy
voodoo that we could take advantage of?
13) Packages (elisp):
I'm working on a way to use #'curl:download for package retrieval
and allow fetching from HTTP package sites (my work is blocked at
the moment by Bug 159). I have already set up a mirror for XEmacs
packages, but I can't add it to `package-get-download-sites' until
that work is done because it is HTTP only.
Shouldn't we have some SXEmacs packages by now? We've all been
using SXEmacs long enough to have accumulated loads of hacks that
use all kinds of SXEmacs-only coolness. Why not put some of this
stuff together into packages.
Our website pretty much runs on autopilot, but if you have a
hankering to fix/add/improve anything there, go ahead...
git clone http://git.sxemacs.org/website
I put a lot of work into "modularising" the source to the site for
the express purposes of consistent look/feel throughout the site
and for ease of maintenance.
One possible addition to the site might be a "how to contribute"
page that outlined places where we're looking for help and how to
go about it.
OK, well there are probably lots and lots of other things that you could
get your hands dirty with, but I think that this list should give you a
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| SXEmacs - The only _______ you'll ever need. |
| Fill in the blank, yes, it's THAT good! |
|------------------------------------<steve <at> sxemacs.org>---|