libera/#climacs - IRC Chatlog
Search
12:17:27
scymtym_
beach: we talked about extracting text editing functions from Second Climacs (but also potentially McCLIM) into a separate library. i have started to do this and "discovered" some abstractions that seem similar to vi's editing model. i'm just mentioning this to make sure you are not already working on it
12:21:31
scymtym_
the library just sits on top of cluffer for now. there are small extensions for finding a "primary" cursor of a buffer and all "user-level" cursors of a buffer
12:25:15
scymtym_
the main idea is funneling all operations through generic functions such as (perform target unit direction operation) and (apply-from-cursor continuation cursor unit direction). this allows, for example, performing an operation to the point cursor of a buffer or all cursors as well as applying things like delete, upcase, transpose to items, words, lines, paragraphs, etc without spelling out all combination
12:25:34
beach
I really want to suggest a VI-like user interface for Second Climacs one day. I think the VIM users suffer more than I (and the other Emacs users) do from insufficient programming tools.
12:29:26
beach
Maybe we could even abstract out the "kill ring". What Emacs does is not that great actually, and I have many times in the past tried to figure out something better.
12:29:45
scymtym_
i don't plan to use these building blocks to make a vi-like interface (although that could be possible). emacs-like behavior can be expressed just as well: (add-keybinding '(#\b :meta) 'move :word :backward) (add-keybinding '(#\f :control :meta) 'move :expression :forward)
12:30:34
scymtym_
right, something like the kill ring and maybe undo would probably fit the scope of an abstract editing library
12:49:31
beach
scymtym_: Speaking of which, I couldn't resist the temptation to write this library: https://github.com/robert-strandh/Clearcut
12:50:39
beach
And I don't quite know how to code DESTRUCTURING-BIND. I could use the s-expression-syntax library, but then I don't know whether I might introduce circular dependencies in the future.
12:51:08
beach
I didn't spend much time on this library, so if you tell me that it's the wrong abstraction, that's fine.
12:51:46
beach
On the other hand, if you think I am on the right track, then I would appreciate ideas on what operations to include.
12:54:26
scymtym_
for the s-expression-syntax library, i added operations as needed. the result is https://github.com/scymtym/s-expression-syntax/blob/builder-protocol/code/expression-grammar/protocol.lisp . to convert the s-expression-syntax to clearcut, those operations would be required. then again, providing a subset in clearcut and extensions in s-expression-syntax could also work
13:00:41
scymtym
it has been manageable but needs some cleanup. the names are bad and the "natural" concept needs more thought
13:05:44
scymtym
this is the editing library in a little text-based testbed: https://techfak.de/~jmoringe/editing-library-1.ogv (sorry for the flickering. i thought i jumped through the hoops to get rid of it)
13:16:58
beach
Speaking of which, what is a good way of creating an extension for a library like Clearcut. I know what I did for Clostrum. I :USEd it in a new package, reexported all operations, and then the new package because the extended library to use with the client.
13:17:44
beach
Speaking of which, what is a good way of creating an extension for a library like Clearcut. I know what I did for Clostrum? I :USEd it in a new package, reexported all operations, and then the new package became the extended library to use with the client.
13:19:45
beach
Actually, that's not quite what I did, but the effect is sort of the same. I also wanted to avoid some Clostrum symbols, so I imported the lot minus some exceptions.
13:21:29
beach
The issue here is that I don't want to add symbols to an external library, and I don't want client code to distinguish between library-provided symbols and symbols provided by the extension.
13:25:14
splittist
Why don't you want client code to distinguish between the base library and the extension library? (What if there are two orthogonal extensions?)
13:27:05
beach
My intuition is that I want to create a coherent protocol, using a single package. But if the library does not provide everything I need, perhaps because it is outside the scope, I think it is ugly to use two different package prefixes for what client code should think of as a single protocol.
13:28:06
beach
For Clostrum, the issue was that SICL needs stuff from a global environment protocol that not all Clostrum clients need.
13:29:07
splittist
It doesn't seem very future proof. Or perhaps it is. Things can move between the base and extension as long as they are the 'same' thing.
13:30:38
beach
Another way of seeing it, is that I did not want to litter client code with Clostrum-specific details, so I created a SICL-specific "module", except that I cheat by having that module secretly use Clostrum functionality for most of its operation.