* Sebastian Freundt <hroptatyr@xxxxxxxxxxx> writes:
> Steve Youngs <steve@xxxxxxxxxxx> writes:
>> o All of the Texinfo docs (including the FAQ) available online at
>> www.sxemacs.org
> Hm, neat idea, though what do you want to see there?
Um, HTML versions of everything you see in ./info/ of course. :-)
> The site itself is version-controlled and I really hate it to `M-x
> xetla-add' generated files.
Me too, which is why I thought I handle it in a similar way I handle
http://www.sxemacs.org/changes/ChangeLog
That file is _not_ version-controlled. It is simply...
tla changelog --untagged > /var/www/SXEmacs/changes/ChangeLog
...from my tla commit hooks. :-)
What I need (I think) would be:
1) Add a "html" target to man/Makefile to build html versions of the
info docs.
2) Add a "html-install" target to man/Makefile that allows me to
specify the base dir to install to.
3) Add some magic to my tla commit hooks to run `make html' and if
that rebuilds anything, run `make DIR=siteroot/docs html-install'.
BTW, I'm talking about the tla commit hooks for my SXEmacs source
repo, and _NOT_ my SXEmacs web repo.
> Maybe we should come up with a tricky autoconf/automake combination to
> setup the website.
> This would be a great gift for all who planned to mirror www.sxemacs.org,
> too!
Erm, why wouldn't these mirror sites simply rsync the site from me to
get it and keep it up to date?
> I'm amongst the (many, many) volunteers for this :)
Cool. Should I point www.de.sxemacs.org to sxemacs.hroptatyr.server
now? :-)
>> o report-sxemacs-bug needs to be a hell of a lot smarter. It needs
>> to pick up backtrace and gdb buffers automatically. And it should
>> really be an elisp front to issues.sxemacs.org.
> Hehe, looks like a quick glance into my eyes, doesn't it? As discussed
> before, I want to see a generic postgresql API (on top of the pgsql
> bindings we have) first; I'm working on something I named cipe for
> this. In a second step, on top of this API we could start thinking about
> an interface to issue.sxemacs.org; and finally (and maybe optionally) on
> top of this, the necessary hacks in issue-tracker.el.
Hmm, seems a fair distance away. :-( I want to make it as easy as we
can with what we have now for people to submit good bug reports. For
now, I'd be happy with `report-sxemacs-bug' doing...
1) Explain to the user that all bug reports must be submitted at
SXEmacs Issue Tracker and that `report-sxemacs-bug' will collect
info that they can attach to their report at the Tracker.
2) Collect info. stuff like Installation file, backtrace and gdb
buffers. And dump that into separate files in ~/.sxemacs/ (for
want of a better place).
3) Tell the user where the files are and direct them to
issues.sxemacs.org to finish.
It doesn't need to talk to our bug db at all or have any kind of
interface to it... yet. But, eventually it _SHOULD_.
Eventually, users and admins, should be able to interact with our
Issue Tracker completely from within SXEmacs.
>> o A decent file/open dialog. The default is crap. It's fucking
>> horrible, and downright embarrassing. GTK/SXEmacs has a half
>> decent dialog box, surely we can code up something nice for normal
>> SXEmacs.
>>
>> o Mule on by default. There's really no reason to not use a
>> Mule-enabled SXEmacs anymore.
> That's an easy issue. We could start tomorrow with it.
Is there any chance that this comment is referring also to "A decent
file/open dialog"? Pleeeeeeeeaaaaaaasssssee. :-)
>> o Server sockets. I hear that GNU/Emacs has em, and the Eicq team
>> will love you forever when SXEmacs has them too.
> What do you intend to do with them in eicq? A simple listening
> socket is very easy to code.
Well, for Eicq's purposes, a simple listening socket is probably all
that would be needed. But don't restrict yourself to keeping only the
Eicq team happy. :-)
Nelson Ferreira <njsf@xxxxxxxxxxx> (njsf on IRC) was looking into this
for me a while back, so coordinate with him if you want to play around
with this.
>> o Begin work on GTK2 to replace GTK 1.2
> Hm, controversal topic. How about to just prepare for other toolkits. If
> we start coding to dedicatedly support GTK2, the code will look as ugly as
> it does now for the various X toolkits (loads of switch()-{case}s, loads
> of #ifdefs).
Good point. I agree. Although I wonder how you're going to cope with
multiple toolkits without using loads of switch()'s, #ifdef's and
friends?
> Personally I prefer to support Qt.
Now I wonder about something... Qt generally means C++ doesn't it? At
least most Qt shit I've seen has been C++. Well, umm, we just dropped
supporting building SXEmacs with a C++ compiler.
There's no real problem here is there? Surely you can code Qt toolkit
crap in C, can't you?
>> o Motif should _NOT_ be the default. Fuck, Motif has more bugs in
>> it than my rotting dead grandmother's corpse. It should NOT be
>> the default. I suggest Athena.
> ACK.
Cool. I'll look into it.
>> o Gutters. The current implementation is pretty horrible and
>> hackish (sorry, Andy P). Using gutter tabs for anything other
>> than buffer tabs is a nightmare. The ordering always gets
>> screwed. And I want to be able to specify fonts/colours etc on a
>> per-tab basis rather than the current per-gutter basis. Also,
>> only top/bottom gutters work... left/right don't. This is another
>> thing that the Eicq team will love you for. :-)
> I dig into them.
Excellent! Evgeny was thinking of doing the same, so team up with
him. :-)
>> o Profiling and mem testing. It would be very helpful to find where
>> the bottlenecks are and where the hell all my RAM is going. Check
>> this out...
>>
>> 21323 steve 16 0 566m 553m 7564 R 17.5 27.3 310:11.16 sxemacs
>>
>> That's a line from top(1). My current SXEmacs session is using
>> more than half a Gigabyte of memory!!
>>
>> (uptime)
>> => Uptime: 2 days, 0 hours, 19 minutes, 18 seconds
>>
>> (uptime 'usr)
>> => User: 18387.37, System: 239.42, Real: 173949.740090
>>
>> Kinda beats the crap out of the old "eight megabytes and
>> constantly swapping", don't it? :-P
> Nothing's wrong with your mem. Welcome to the new century, I'd say. My
> RAM-load looks like yours for ages. Typically my coding sessions eat up
> ~700 Megs.
That session ended up breaking the Gigabyte barrier. I sat there in
absolute amazement. I've never seen a single app use so much mem.
Yeah, I've lived a sheltered life. :-P
>> Well those are the things off the top of my head. Now, lets hear
>> From _you_. What do _you_ want to see in 22.1.4--version-0? What
>> items on my list will _you_ take on?
> o PostgreSQL/Generic SQL API:
> Improve bindings to reflect the late issues of 7.4 and 8.x
Great, yes, do it!
> Possibly define a more generic wrapper around several RDBMS-APIs
> (sqlite, mysql, more?).
I don't think that this is such a good idea. Lets have SXEmacs core
concentrate on PostgreSQL, and let some other bugger write XE lisp
packages for the others.
> And: Let's put the final version of our ToDos on the webpage. Personally,
> I love to that way to see projects' futures.
I fear making promises and claims we don't live up to, especially if
we start predicting when these things will happen. But I do agree
with you, there should be something online that shows at least where
we'd like to go.
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| I am Dyslexic of Borg. |
| Fusistance is retile. Your arse will be laminated. |
|------------------------------------<steve@xxxxxxxxxxx>---|
pgpGCvDdjIBU4.pgp
Description: PGP signature
|