freenode/#lisp - IRC Chatlog
Search
4:50:25
beach
For that kind of stuff, McCLIM is ideal, provided you want to program in Common Lisp of course.
4:51:28
beach
What are some of the characteristics of this editor? What kind of stuff will the user edit?
4:52:15
moon-child
beach: I recently started using emacs, and while I am impressed, I want to a) do better; b) make my own
4:52:50
moon-child
something that will work cross-platforms. If there are plans to add other backends 's probably fine
4:53:38
beach
There are plans for other backends. And you may want to consider writing one that you need. You will save time by implementing your editor in Common Lisp, and you will help others who need that backend.
4:54:17
moon-child
the editor was always going to be in cl, the question was just what the graphics backend would be
4:55:02
beach
When you start mixing languages where some have manual memory management, you are in for a debugging nightmare.
4:55:51
moon-child
believe me, I know it. I wrote an embedding thingy for perl6 and getting it to talk to c well was awful
4:56:21
beach
OK, then you should know that I have plans for an editor for Common Lisp code. I already wrote (first) Climacs, and I have a design for Second Climacs. And loke is working on one as well. So if you need advice, just ask.
4:57:50
beach
I do, but I don't remember by heart. You can look at Second Climacs, but I advise against trying it.
4:59:59
beach
moon-child: Because of item b above, I am not suggesting a collaboration. But I can give advice.
5:01:43
moon-child
probably don't want to collab anyway. I have different goals to emacs; what I want to make is a development of editors informed by my experience with emacs, but which is probably closer to vim in the end, which seems different from what y'all are making
5:02:18
moon-child
I saw cluffer, was thinking of using it. Also looking at the backend interface for clim to see how much work a w32 port would be
5:03:07
beach
The editor I am planning would not be designed around key bindings. The essential design would about parsing buffer contents incrementally and displaying information to the user. Key bindings is just a minor thing.
5:04:04
moon-child
with more granular levels of temporality than just permanent(-ish) config files and transient macros
9:05:26
_death
Xach: hmm now that akoana mentioned it I do remember something about static lib only.. maybe I compiled it on the server to get the dynamic library
13:58:36
phoe
but debian doesn't provide a .so, only an .a library - see https://packages.debian.org/sid/amd64/hspell/filelist
13:59:53
phoe
this means that either someone asks the debian maintainers to include a .so in the package or that the Lisp system will have to provide a .so on its own
14:04:02
dlowe
I really love the emacs daemon/client setup and if I were going to write an editor, it would have that design from the beginning