libera/#clim - IRC Chatlog
Search
12:57:53
lukego
I wonder what's the best (default) behaviour for clime to show presentations from lisp/mcclim. should the repl automagically #'present results, as I guess the clim-listener does? or should the lisp side always explicitly say "present this in emacs"? and/or should the presentations be written inline in the repl or pop up in a buffer?
12:58:59
lukego
Emacs is equally happy for presentations to appear anywhere, you can even kill and yank them and they keep on working. original behaviour is that lisp code needs to explicitly ask for the presentation to appear in Emacs and it gets inlined into the repl.
13:01:05
lukego
maybe there should be separate integrations for repl/inspector/debugger/etc. maybe basic default should be to just pop to a buffer...?
13:01:53
jackdaniel
the name 'clime' is quite confusing to me, because each time I see it I think "clim-extensions package".. that aside slime already returns a presentation (not clim presentation mind that) in repl, so returning it below the prompt seems only natural
13:02:16
jackdaniel
as of presenting things at different parts of the screen - I'd have that available via direct calls to present
13:03:07
jackdaniel
I'm not sure whether you've seen that, but I wrote a short blog post that implements a visual repl with presentations in clim: http://turtleware.eu/posts/Implementing-a-simpleminded-REPL-from-scratch.html (it is not clim-listener, much simpler)
13:05:23
jackdaniel
being able to draw and present on a separate buffer from repl also sounds like a good idea (i.e depending on the stream argument)
13:06:11
lukego
I saw selwynning's comment re: "clime" and I'm keeping that local to the emacs lisp code. I think it's mostly confusing in the context of common lisp code and mcclim developers but the target user for this is just lisp randos.
13:07:22
jackdaniel
I anticipate that it would make lisp randos confused when they approach it at some point because there would be two entirely different things with the same name
13:08:34
lukego
yeah sorry I like the name and I don't think it's pulling its weight as a nickname for clim-extensions package :)
13:09:36
lukego
that ^ is a mcclim clim extension. there is no CL package called "clime" in the stuff I'm working on. the name is only used in emacs lisp code
13:10:45
lukego
also there are already two separate "competing" implementations of the Emacs code, the original one based on SLIME and the new port based on SLY, so maybe someone can write a third one that's not called CLIME and the problem will be resolved :)
13:11:18
lukego
(I'd considered dropping the name CLIME with the port to SLY, since the SLIME connection is not there anymore, but decided that "CLIM for Emacs" works too)
13:13:11
lukego
jackdaniel: supposing we start with the repl displaying the presentations in Emacs, the question is when should it display such a presentation: for every lisp result that CLIM is able to present; for lisp results that happen to be CLIM presentations; or only for values explicitly passed to e.g. mcclim-emacs:present-to-emacs
13:13:15
jackdaniel
I'm personally surprised that it is a problem in the first place; there are so many interesting problems but this one is not. either way the backend naming convention in mcclim codebase is mcclim-foo (with an exception for clim-postscript as it is specified)
13:14:06
lukego
of course if anyone has a better name for the emacs side, which will be the user visible face, then now would be a great time to propose it. but I think "clime" is hard to beat :)
13:14:08
jackdaniel
I think that the PRINT function in REPL should call (present results 'repl-results :stream 'repl-stream :view 'repl-view)
13:15:23
lukego
so in practice does that mean that (format t "~s" obj) would insert a presentation into the repl whereas simply (identity obj) would not because there is only a return value and no output?
13:16:28
lukego
oh, right, PRINT as in REPL. So the default behaviour for displaying result values. Yeah that sounds like a good thing to start with and then see if people hate it.
13:16:49
jackdaniel
of course that requires handling multiple values too, that's why I've mentioned my blog post
13:17:30
lukego
likely need convenient commands to toggle this mode on/off and to easily see the "normal" lisp representation of the object e.g. via right click or something.
13:18:30
jackdaniel
lukego: assuming that the buffer is represented as sa stream, then customizing stream-view would be a good place to do that
13:21:36
jackdaniel
the presentation method present may be specialized on the type, the object, the stream and the view
13:23:29
lukego
interesting. could alternatively drive the whole thing from the Emacs side, with Emacs directly invoking PRESENT in Lisp when it wants a graphical representation of something
13:24:44
lukego
I heard a rumour that SLY dropped presentations but clicking on REPL results seems to open them in the inspector so I guess in some form Emacs can reference lisp objects.
13:25:25
lukego
maybe shift-click could toggle between the clim / text representation of an object and default state could be a user setting
13:26:02
lukego
(maybe a good default would be to show only the most recent repl result in all its CLIM glory and to toggle off the potentially large graphical representations of older results)
13:26:37
jackdaniel
it is just that the link between the text on the screen and the object is preserved
13:27:31
lukego
that's the bit that I think of as "supporting presentations" i.e. remembering which object the text refers to. but I'm probably forgetting how it really works in slime's presentations.
13:27:32
jackdaniel
so you can i.e reference stuff like #<abra kadabra> without actually reading it (and erroring misreably)
13:30:51
lukego
(btw I see that I lied above about naming and there is a package called slynk-clime on the Lisp side but that's internal plumbing in SLY and not part of the clim code.)
13:37:20
lukego
aside - I also find that I just have a really hard time understanding clim abstractions and thinking in those terms. I think that if I try to do things Right form the CLIM perspective there's a high risk I get stuck. so that's probably a point in favor of doing something "emacs'ey" and working that can be iterated upon.
13:38:00
lukego
I think I could easily lose the rest of the day trying to appreciate what STREAM-DEFAULT-VIEW is all about for example.
13:38:39
jackdaniel
when you present something on the stream and you do not explicitly provide a view, then the view is supplemented by the value of stream-default-view
13:39:34
lukego
I don't really have "swapped in" even basic ideas like what a view is, and I'm not sure if I've ever really understood how FORMAT interacts with CLIM. could be that I am a bit too "MTV generation" for these details and have to work within my limitations :)
13:40:33
lukego
okay less blah blah from me. let's try to get SVGs rendering in a convenient way so that I don't end up giving up and doing something I will regret with revealjs/javascript or blender/python :)
13:41:07
jackdaniel
a view is a an object that may have twofold use - to specialize the appearance, i.e (present *student* :view +list-of-students-view+)
13:42:19
jackdaniel
and the other is to retain some state of the presentation, i.e in +list-of-students-view+ instance you could have a slot TYPE with possible values :SHORT-VIEW or :DETAILED-VIEW
13:43:11
jackdaniel
the latter use (that is retaining some view-specific state) is rarely used as far as I can tell
13:44:01
jackdaniel
format just prints characters to the stream. clim-stream-pane implements gray stream protocol and remembers printed characters so they can be repainted etc, as well as honors the current dynamic context (i.e the current drawing ink)
13:44:55
lukego
thanks for your exertions but I have been failing to construct a solid mental model of these concepts for over 20 years now and I think it's time to admit defeat and try to cooperate with others who can compensate for my limitations :)
13:54:29
lukego
(I find everybody frustrating to communicate with on IRC, but much easier on other media, so I usually try to stay away but didn't know where else to connect with mcclim-emacs interested parties in a timely fashion)
14:24:22
selwynning
regarding the naming dispute: i don't think it is unfair for clim-extensions to take the nickname, as it was there first and eliminating the nickname would lead to a very great deal of work in renaming things
14:25:19
selwynning
on the other hand, calling the backend mcclim-emacs is consistent with the package names of other backends
14:26:13
selwynning
however, it doesn't seem unreasonable that the backend with package 'mcclim-emacs' can be referred to as clime in casual conversation, or even elisp
16:01:18
selwynning
while transform-glyphs is t, and using with-scaling to try and fix it doesn't seem to have an effect
16:05:03
jackdaniel
if you can make a small test case and put an issue on the tracker then I'll take a look at it tomorrow
16:06:05
lukego
thanks again for the help today jackdaniel. I am conscious of my debt to you in patient tutoring.
16:06:57
jackdaniel
you're welcome, if you happen to be at els this year then you may buy me a beer ,)
16:07:52
lukego
(I guess it's time to make travel arrangements at this point... last time I was rudely surprised by how long it takes to get to and from Porto and the city where I live these days.)
16:19:34
jackdaniel
indeed, if beers are as expensive as housing in amsterdam then I'll save two housings this year ;)