Re: A real database for Emacs
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org:
SL Baur <steve(a)beopen.com> writes:
> I've now spent the better part of this week porting my code from 21.1
> to 21.2. The internal interface to XEmacs is way too much of a moving
> target for me to consider making this code available primarily as a
> module at this time.
Note that I was not thinking about making it an independent module
(i.e. not part of an XEmacs release). Frankly I think that is
unlikely happen soon, because much of the improvement is currently
(and in the foreseeable future) in the lowevel stuff.
O.K.
However what I have a mind (as a first step) is that a normal
"make/make install" can compile and copy parts of XEmacs as
modules. I think your database support would be a good candidate
for that.
It is. It is also prototypical of what I want to see a lot more of in
a future XEmacs. Someone mentioned that we can hardly support all the
different relational databases as independent interfaces. I think we
*can* if the right infrastructure exists.
I am a believer in The Editor is the Operating System ... think of
this as (yet) another device driver.
I've had good experience in the past from prototyping tools, but the
experience I've had during the last week beats anything I've seen in
the past. XEmacs Lisp is *good* and an XEmacs Lisp Interaction buffer
makes an excellent tool for trying things out. I would like to see the
day when have many, many different programming libraries with Lisp
interfaces. I lost count many years ago of the number of different
computer languages I've been required to code in. I also lost count of
the number of different libraries I've had to learn. I can't remember
learning anything as fast as libpq, even though I had to write and
debug an XEmacs interface to it at the same time.
In case the point isn't clear, SQL in a Lisp Interaction buffer
*really* rocks, and so would many other things, I strongly suspect ...
One the makefile hackery for that is in place I don't really see
that
much difference in maintaining it as a part of XEmacs than be compiled
as a module and as one that has to be linked in at "make time".
O.K.
IMO. We need at least one major release with modules at this level
before we can think about more loosely coupled stuff.
We'll never have people making binary-only modules for XEmacs. There
are too many compile time options for that. However, it would be
useful on a CD ROM against a single, base binary.