[climacs-devel] Climacs development

[Robert Strandh]

Dear members of the climacs-devel mailing list,

I am overwhelmed by the positive response on the part of the community
with respect to this project.  A few days after its creation, this
mailing list now has more than a dozen members.  While I understand
that the majority is only interested in following what the developers
are doing, I would still like to give you all an overview of who is
working on what, and what still needs to be done. 

First, in case you have not seen it, the main reason for the creation
of this project was to serve as a CVS site for three student projects
that I have suggested, and that will be conducted starting end of
January and finishing around the end of April, I would guess.  You
might start to get commits from them sometime in March at the
earliest, I think, but there will no doubt be messages to this mailing
list.  It is then OK to answer questions, of course. 

The student projects cover the following areas, which I must then,
unfortunately discourage everyone from working on before the month of
May. 

    * The "real" buffer implementation, using a 2-3-tree of lines,
      each line being a Flexichain.

    * Undo.

    * Common Lisp syntax.

It is OK to suggest improvements to code committed by the students

The second purpose for the creation of this project was to obtain
something that could serve as a common base for Goatee and Portable
Hemlock.  I would like to see those two projects merged, if possible,
and I would like for them to have a sound basis, in the form of decent
protocols for fundamental things such as the buffer, undo, syntax
highlighting, and more.  By "sound", I mean ones that can be
implemented efficiently in a variety of ways, and that can be used
effectively by higher-level code. 

I am a little ambivalent about Climacs turning in to a fully-featured
Common Lisp Emacs, because that would mean that, instead of merging
Goatee and Portable Hemlock, we write a third one.  On the other hand,
it might turn out too difficult to replace the low-level protocols of
Portable Hemlock by something else, as they tend to permeate the rest
of the code (which is reasonable of course).  For that reason, I am
merely going to continue developing Climacs for now, and I am going to
encourage others to pitch in.  When we reach a level that is
sufficient for some functionality from Portable Hemlock to be
"grafted on top of the base" (to use Gilbert's words) it might be
preferable to do that instead of rewriting it.  One has to be careful
with licensing when this is done.  Importing compatible code (public
domain, or LGPL) is OK, of course.  Notice that Climacs is LGPL in
order to fit into McCLIM, and to encourage developers to contribute
their changes, while still allowing for very liberal use by commercial
products. 

Aside from the three student projects above, here is a list of what I
know to be worked on by someone on this list:

  * Kill ring implementation (Elliott Johnson).  

  * Using CLIM incremental redisplay (Alastair Bridgewater).  
    There is still a problem with the cursor disappearing, so if
    anyone wants to pitch in, that would be OK.

  * Performance improvements to file I/O (Me).  It turns out, the
    problem is that adding objects one by one is too slow.  We will
    need and upward-compatible addition to Flexichain
    (insert-sequence*). 

  * Adding commands to the Climacs command table so that they will be
    available through M-x (Alastair Bridgewater).  

  * Toggle character and words commands (Matthieu Villeneuve).

Aside from those medium to large tasks, I am unaware of any other
activity.  If you plan to work on some other aspects, please submit
your proposal here to avoid too many clashes.  If you would like to
work on something, there are tons of little and not-so-little things
that need to be done.  Here is a (partial) list:

  * Emacs has many, many commands at this point.  Adding the most
    important ones is a laborious, but nevertheless important task.
    Most such commands are fairly simple. 

  * We need to figure out what McCLIM wants in order to invoke
    redisplay when the size of the pane changes. 

  * We need to get McCLIM scroll bars for the buffer working. 

  * I would like to add a buffer syntax for text that recognizes not
    only words, but also sentences, paragraphs and perhaps pages.
    Contact me if you are interested in this.  It's a big task which
    involves writing an incremental parser for the syntax of such a
    document. Granted, it will be much simpler than the CL syntax.  It
    might be best to write a specification first. 

  * Buffer syntax for other languages, in particular C, C++, and Java,
    would be very interesting tasks for those who use those
    languages.  I am personally not going to work on this. 

  * User feedback and error handling must be improved.  Ringing the
    bell is not enough to inform the user what went wrong.  also, the
    user needs to know which, if any, file is in the buffer.

  * I can't seem to figure out how to capture the parse-error from the
    filename completion code.  Right now, it is therefore not possible
    to load a non-existing file.  This should be fixed, of course, and
    involves understanding conditions and McCLIM completion.

  * We need a spell-checker protocol.  A spell checker should not just
    return a boolean indicating whether a word exists in a dictionary,
    but also a value indicating that a sequence of characters is a
    valid prefix for some such word.  This might involve writing a
    word completer for McCLIM, and augmenting the completer with
    :near-misses or something like that, in order to suggest the right
    word.  Finally, to prepare for grammar checking, the spell
    checker should not just return a boolean, but a list of possible
    grammar categories.  Like in English, submitting "flies" should
    return (at least) two entries: 1. noun, plural and 2. verb,
    second-person singular.

  * It would be great if someone would maintain this to-do list in
    some document in the hierarchy, for instance in a file called
    TODO.  In fact, I am not very experienced with bug-tracking and
    the like, so that needs to be given some thought. 

  * Documentation.  While I am writing the text of the internals
    document, it still needs Texinfo structuring commands in it.  It
    also needs better indexing, cross-referencing, word markup, etc.
    At some point, we need a user manual, which should also be in
    Texinfo.  Documentation is boring to most people, but on the
    off-chance that someone likes to write it the way I do, please go
    ahead. 

Well, that's just what I can think of right now.  Please do not
hesitate adding to this list as you see fit.  Oh, and if you plan to
contribute, please get a common-lisp.net account so that you can
commit directly to CVS.  I will most likely not have time to review
patches anyway, so you might as well commit, and have other review
your commits after the fact. 

This message is already much longer than I intended, so I'll stop
here. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------