Hello Jeff,
because of a lenghtier vacation I can only answer your questions now. I do not mind discussing those questions on the public mailing list, and also you could get opinions of the other list readers in addition to mine, so I will CC my reply there, I hope you don't mind.
- Does croatoan (in your humble opinion) have advantages over cl-charms?
At the time I started working on croatoan (quite a while now, time flies) with the goal of writing a terminal IRC client in Common Lisp after my first attempts in GNU Guile, cl-charms existed but was abandoned. Since at that time it was abandoned and I neither did not know how to contribute nor did it make sense to contribute to an unmaitained abandoned project, I forked it for myself and worked on it for a while. When quicklisp was first released, I applied to add croatoan and have been updating the code since then independently of cl-charms. cl-charms, on the other hand, was in the meantime taken over by other people who have been adding to it independently, so over time, the two codebases diverged.
"In my humble opinion" (TM), the main advantage of croatoan over cl-charms nowadays is that somebody is actively working on it (I and some other people) with the intent to keep working on it for years to come, because our own projects depend on it and we have an interest that they keep working with future ncurses releases. This is also its main disadvantage, because it means that code will necessarily break occasionally. Breaking is kept to a minimum, but can not be entirely avoided, since the library is simply not finished.
The second advantage and the main reason for me to work on it, is that croatoan has a slightly different goal that cl-charms. While cl-charms and cl-ncurses had the goal to "just" add FFI wrapper functions, instead of just calling unpleasent cryptic ncurses functions like "mvwaddnwstr", croatoans humble goal is to use CLOS for the user-facing interface and to keep it nice and easy to read. (Whether I will achieve that is another question).
Another advantage from your point of view might be that if you plan to you use ncurses directly, since the API is very low-level, you will start adding your own higher-level lispy wrappers anyway, so unless you want to add even another library, it is easier to just re-use what we have put together during the last years, if it suits your purpose of course.
- Can croatoan use the threaded/mutex'd version of ncurses? (https://invisible-island.net/ncurses/man/curs_threads.3x.html), or are there any plans to use it in the future?
You can already use ncurses with lisp threads as long as only the main thread makes the ncurses calls. For an example, see:
https://github.com/McParen/croatoan/blob/11d6e716431599d5fc89fee4163483d7ca5...
There is also a simple thread-safe queue class, contributed by an user, which allows worker threads to send ncurses calls to the main thread to execute, but I did not use that often myself:
https://github.com/McParen/croatoan/blob/master/src/queue.lisp
I intend to support all ncurses functionality in the long run, but since there is a lot of work remaining and since I like all of us just tend to work on the parts that I use myself, it could take years to get there, so I would not put too many hopes on that. You are of course welcome to contribute in any way you can and are able to. I hope you enjoy Lisp along the way.
Hope this helps, regards, Anton