libera/#clim - IRC Chatlog
Search
6:51:44
lukego
I'd like to write a function "(PRESENT-FOR-EMACS object) => svg-string, metadata" that could be called on e.g. every REPL result to get a graphical CLIM representation e.g. to show as a tooltip on the ordinary textual value. Is this a sensible thing to do from the CLIM perspective? I'm thinking it's a bit funny not specifying a presentation type but PRESENTATION-TYPE-OF for DWIM should be reasonable in this context.
6:54:22
lukego
Maybe all I'm describing is PRESENT wrapped in a suitable stream like (CLIMI::WITH-OUTPUT-TO-DRAWING-STREAM (*standard-output* :svg nil) (PRESENT object)) which would basically give me what I want...?
6:56:38
lukego
I looked at the "simpleminded REPL from scratch" example but that doesn't seem to be doing automatic coercion of REPL results into CLIM presentations. So far I didn't identify any objects that actually do yield graphical representations in this way, which makes me wonder if PRESENTATION-TYPE-OF is really a thing in practice...??
6:58:25
lukego
and now when I say that out aloud I suspect that PRINT/FORMAT to a CLIM stream does the same job here and in that case maybe the minimal REPL would actually show rich graphical REPL results if there happened to be relevant PRESENTATION-TYPE-OF methods available for the repl result values...
7:00:20
lukego
though I'm obviously laboring within an incomplete mental model here because many objects do have PRESENTATION-TYPE-OF methods, e.g. 42 => INTEGER, but are maybe not shown graphically for other reasons e.g. lack of a method for rendering that presentation type on the relevant view/etc.
7:35:06
lukego
I notice in the "minimal repl" demo the value NIL is being printed as "NIL". I'd wondered if it should be "Null" to match the definition in standard-presentations.lisp and I _think_ that would be true except that PRESENTATION-TYPE-OF is classifying NIL as a SYMBOL and not a NULL. Or maybe none of those standard presentation methods apply in the minimal REPL demo for reasons that I'm failing to appreciate.
9:37:20
jackdaniel
lukego: note that present in the "simpleminded repl" is called with a second argument 'result -- that means that the object is presented with this presentation type
9:38:15
jackdaniel
if I find some time later today I'll give you a snippet how you can do more interesting things (i.e a tooltip with a nice graphic inspired by the object) without throwing away the 'result part
9:38:39
jackdaniel
note, that the command inspect-result is specialized to the argument of type result, that's why you may click objects to inspect them
9:39:23
jackdaniel
the "hook" to customize appearance of the object is not changing its presentation type (that's for specializing translators) but by supplying and specializing to a desired view
10:08:38
lukego
I'm now imagining a different basic way for Emacs to use CLIM. For each Lisp value Emacs would have a printed representation (as today) and a reference to the real Lisp object (as today) and (new, lazily-generated) SVG image representing a CLIM presentation. So the user expectation is that for any object they can click/hover/something to toggle/reveal its graphical representation. Then ACCEPT etc would also work on sub-presentations within.
10:09:36
lukego
This would require that Emacs can query Lisp/McCLIM for some "canonical" presentation of any value received from Lisp e.g. REPL results.
10:11:48
lukego
(This is in contrast to the first version of Emacs CLIM support where Lisp values like REPL results were not automatically CLIM'ified/ifiable but rather Lisp code had to write (WITH-OUTPUT-TO-EMACS ...clim...) to get graphics inserted into a default location e.g. as REPL output.
10:26:19
jackdaniel
here's a commented addition - basically I've added a "repl view" for specialization and two presentation methods present and highlight-presentation
10:27:10
jackdaniel
surely this could be improved upon, but that illustrates the concept how you could add a preview of some sort
10:28:00
jackdaniel
a noteworthy thing: you can present thing with its own presentation type from /inside/ of a more abstract presentation method present
10:31:38
lukego
thanks! can you share the code for that? I guess you wrote a PRESENT presentation method on some basic type like OBJECT (and specialized on this new view) to draw the pink rectangle? I'm curious about how the printing code looks i.e. for getting the string verses getting the visual clutter, is that same code but different view?
10:32:54
jackdaniel
I wrote the present method specialized to the type RESULT (which is presented by the repl) and the view REPL-VIEW
10:33:55
jackdaniel
(well, to be fair highlight does not specialize to the view - you may still access the view though with (stream-default-view stream) if you have some data there
10:35:45
lukego
It's still a bit surprising to me that CLIM presentation methods are so partitioned. I always expect them to be a bit more global e.g. for there to be a bunch of graphical standard presentations that I'd get access to via the REPL. If the presentation methods are specialized up the wazoo then it seems like the REPL won't benefit much from all the various presentations in other CLIM applications.
10:36:22
lukego
I guess the model is that applications are separate e.g. if the Listener wants to inspect objects then it opens the Inspector instead of borrowing its presentation types.
10:36:49
jackdaniel
currently we have only the textual-view (and gadget-view, but let's ignore that for the sake of argument)
10:36:53
lukego
(This is a major contrast to Emacs where a buffer is a buffer is a buffer and you expect functionality to be global by default.)
10:37:26
jackdaniel
I can imagine that someone implements a fancy-view and defines presentation methods for it, so all applications can utilize it
10:37:53
jackdaniel
it is the same with presentations - each application may have its own presentation types
10:38:02
lukego
splittist: I'm not sure what I expect to get for "42" especially but when I tried asking CLIM to turn that object into an SVG what I got was an empty 0x0 image as a result which was disappointing.
10:38:04
jackdaniel
but there are also (basic) presentation types shipped with mmclim that are shared
10:38:28
jackdaniel
nothing stands in a way to write a big ontology of "desktop" presentation types that could be shared by a group of applications
10:38:47
lukego
the basic presentation types seem to be all textual, right? judging by standard-presentations.lisp
10:40:09
lukego
I get that nothing stands in the way to creating a "desktop" ontology etc. Just that from an Emacs perspective I'm hoping that a little bit of glue code will allow me to tap into a whole bunch of existing functionality. but in practice it seems to give me a blank canvas where I'm invited to reinvent the stuff that listener, inspector, etc, are already doing privately.
10:41:02
lukego
but there are a lot of Emacs users so if the foundation is solid maybe all that functionality will grow organically.
10:41:09
jackdaniel
that's the way authors wrote these applications. creating something tailored is usually easier than making a general-purpose abstractions
10:41:34
lukego
could well also be that the Emacs backend will have peculiar quirks that make it incompatible with the way a lot of those applications were written.
10:42:25
jackdaniel
the last time we've talked you've said that you are interested only in presenting things (i.e not in allowing to show an application frame in an emacs buffer), so in this sense it will be incompatible
10:42:53
lukego
and maybe the next step in this discussion is to question whether it makes any sense to have a CLIM backend for Emacs in the first place if all it provides is a blank canvas which Emacs already had in the first place...
10:43:53
lukego
I'm only personally immediately interested in presenting things and not whole application frames (don't know how that would work.) but if I'd look at Listener or Clouseau etc demos then I'd be able to point at lots of things and say "I'd love to have that"
10:46:14
lukego
by a blank canvas I mean having some basic machinery (SVG-like drawing operations, image regions with presentation-type metadata, the ACCEPT API) but not a corpus of reusable code based on this (e.g. inspector-like presentations of objects like packages and symbols and so on)
10:46:19
jackdaniel
depending on how these applications are written possibly you could import (for example) listener-view and things could magically work (depending on how they are written)
10:48:25
lukego
I am held back by being a caveman at heart who really struggles with high-brow interfaces like CLIM.
10:51:09
lukego
I probably have to "think like a C++ programmer" and pick a subset that I'm comfortable working in, that others could potentially generalize in beneficial ways, and that actually buys me something over just using raw Emacs facilities directly.
10:52:23
jackdaniel
n.b this may be somewhat insightful regarding clim abstractions: http://turtleware.eu/posts/A-tale-of-two-abstractions.html
10:53:27
lukego
yeah. So I'm saying to my caveman brain, hey, it will be really cool to have a blank canvas where we can write methods to visalize arbitrarily Lisp objects and access those pervasively in Emacs. That is a good value proposition. My caveman brain though is answering okay, fine, but then what is mcclim bringing to the table over just generating SVG for Emacs's native support?
10:54:43
lukego
I wonder if your grammar of graphics code is a good candidate for browbeating into Emacs? that would potentially be a sufficient up-front win to make the whole enterprise worthwhile.
10:54:47
jackdaniel
if you are not interested in common lisp integration and you insist that emacs is the way - imo emacs is a reasonably sufficient toolkit then
10:55:44
jackdaniel
perhaps if I were a marketer I'd try to dissuade you here, but nobody pays me for this so I won't
10:56:49
jackdaniel
as of whether polyclot will work in emacs backend - that depends on how much it implements
10:57:22
jackdaniel
if you are interested only in svg image - that will work; if I add objects as presentations and translators and you'll want to benefit from that -then command processor will need to work with emacs
11:01:20
lukego
The original Emacs code supports both getting the SVG and also the set of "hot regions" where it contains presentations. If Lisp code calls ACCEPT then Emacs narrows those presentations to enable only the relevant types and lets the user click an object in Emacs to choose the return value to ACCEPT. Is that what you mean by "add objects as presentations" ?
11:02:47
jackdaniel
I mean: if I can say (with-output-as-presentation (emacs-stream point my-presentation-type) (draw-rectangle* ...))
11:02:49
lukego
So maybe the caveman would be persuaded that it's a big win for CLIM integration to provide polyclot charting in which (eventually) individual datapoints could be accessed as Lisp values by Emacs
11:03:12
jackdaniel
and then when I type (accept my-presentation-type :stream emacs-stream) and I can click on that point, then it should be fine
11:04:37
lukego
yeah that's existing functionality in the Emacs code. so if that were likely to be interoperable with polyclot then that would be very encouraging (offsetting the sad feeling of likely not being able to reuse any listener/inspector/etc functionality.)
11:05:27
jackdaniel
I don't know which functionality you are talking about so I can't address your point of remorse
11:07:10
lukego
okay let's learn how to clone a fossil-scm repository and see if polyclot is a more promising basis than standard-presentations.lisp for displaying eye catching things in emacs buffers.
11:08:14
lukego
There's also potential benefit in the opposite direction i.e. for users who write their own graphical presentations for Emacs from scratch to then be able to reuse those with other McCLIM backends. That would seem like a win for all concerned.
11:09:19
lukego
Maybe MCCLIM-EMACS would serve as an on-ramp for MCCLIM-CLX and other applications like the inspector and so on to give people an opportunity to step gently into the CLIM universe.
11:11:06
jackdaniel
ACTION takes a minute to appreciate how little work it was to introduce an ad-hoc tooltip to a clim application
11:13:36
lukego
I have regular coffee awareness briefings with my kids to emphasise that if something happens to my coffee, e.g. it is knocked over in an energetic game, then we will formally declare "game over" for planet earth and treat is as a functional apocalypse.
11:14:28
lukego
I have to be careful they don't see opportunity here to arrange a coffee accident and then have fun letting the dog loose, eating all the sugar, etc under apocalypse rules.
11:24:30
lukego
I wasted one cup this morning. Tried a hipster "one minute cold brew in aeropress" recipe that relies on agitation instead of time or heat for extraction. didn't work, still considering whether I dare try again with less-cold water and more-brisk stirring :)
11:29:42
lukego
understood. Just now I'd like to use it as a motivating existence proof that Emacs will be able to access some existing CLIM functionality. So I'll try to render some polyclot plots into SVGs without an application frame and show them in Emacs.
11:30:09
lukego
I don't immediately need a grammar of graphics but visually the polyclot charts are very similar to the kind of code that I want to write at the moment
11:31:30
jackdaniel
where did you learn that I'm working on it? did you read a-few-months-old logs of the channel or somewhere else?
11:36:12
jackdaniel
(note that clim also can do postscript, maybe that will be easier to embed in latex(?))
11:37:21
lukego
nifty I'm able to generate SVGs using quasi-emacs code like (climi::with-output-to-drawing-stream (s :svg nil) (polyclot *test1* s))
11:38:40
jackdaniel
(a semi-recent one at that, I wrote it along the svg backend, but it works with other backends too)
11:39:03
selwynning
anyway, clim was not to blame for this, prior to this the svgs looked great in the browser and every other viewer i tried
11:41:08
jackdaniel
http://turtleware.eu/posts/McCLIM-backends---Part-I-Medium-Output-Protocol.html has some examples (part II also)
11:41:42
selwynning
though one thing that annoys me a lot is the inconsistency with which different backends deal with transforming text
11:43:04
jackdaniel
duim spec clarifies a few things in a way that is impossible to guess reading clim spec
11:43:05
selwynning
although it is spec mandated that :transform-glyphs can be ignored, in practice the only way i can make text look the same across backends is to wrap calls to draw-text* in with-identity-transformation and try to apply any required transformations manually
11:44:19
jackdaniel
it is about whether glyphs should be transformed when they follow along the path dictated by toward-x and toward-y (in case of duim - arbitrary path)
11:44:58
lukego
Here's a wrinkle: the polyclot presentation methods are specialized on <polyclot-view>. This means that Emacs wouldn't pick them up by default. I wonder what's a reasonable solution to this? (Maybe some kind of funky <emacs-view> class that's (re)defined to mixin all the kinds of views that the user wants Emacs to use by default?)
11:44:59
jackdaniel
I want to unify the interpretation but I don't remember which behaves how, I'll get to that when I'll be integrating the framebuffer renderer to sdl2
11:45:41
jackdaniel
lukego: perhaps you could set a default-view of the emacs stream to <polyclot-view> ?
11:46:55
lukego
yeah that makes more sense. could provide some knobs/hooks for users to enable the view(s) they are interested in for emacs.
11:49:41
jackdaniel
(unless, of course, someone else makes a pull request with the necessary changes to unify the behavior)
12:04:03
jackdaniel
tomorrow I have a few hours stashed so I hope to finish new text gadgets and make a pull request
12:04:55
jackdaniel
they are already plenty capable but I want to have a nice api for annotations that I will be able to generalize later to input editing streams and after that to seos
12:56:21
lukego
jackdaniel: thanks for the help with "marketing" issues. I feel like there's a solid basis for the emacs-clim code being a win-win. emacs wins because significant functionality like polyclot will be accessible. clim wins because emacs extensions should also work with other backends. it seems like a superior approach than doing something ad-hoc.
13:07:03
lukego
on to the next technical problem: I'd like for Emacs to be able to automatically convert <polyclot> objects into graphical presentations but calling PRESENT directly doesn't seem to work. I suppose it's because those objects are usually presented by calling POLYCLOT which does extra "training" logic before calling PRESENT. I wonder if this is an unusual case or a sign that generic object->presentation conversion is going to be messy?
13:08:21
lukego
Superficially this would work better with the original design of the Emacs side where you explicitly/imperatively present objects from the lisp side e.g. (with-output-to-emacs (polyglot *test1*)) instead of just sorta (present *test1*)
13:09:11
lukego
Maybe I can just fudge it for now with a dedicated EMACS-VIEW that does the necessary incantations.
13:38:30
selwynning
lukego: will there be much overlap between your work on sly and what is currently on my fork
13:39:49
lukego
it's a bit up in the air now but I'm anticipating significant differences so it would be great to capture the state of what you have
13:40:45
lukego
could well be that I'm doing too much at once i.e. both porting to SLY and rethinking when/where/how Emacs displays presentations.
13:41:51
lukego
it would be interesting to compare notes on UI with you and splittist. I'm not sure how though, IRC seems kind of hopeless for that kind of discussion. I haven't really been satisfied with appending presentations into the REPL but I'm not sure if my new ideas are an improvement or not.
13:43:59
lukego
anyway I think it would be helpful to establish your code ahead of time if possible and then I can try to "sell" my "improvements" to see if they have merit
14:22:57
selwynning
the main issue i have - and the reason why i think merging now would be bad - is that drawing code is called twice
14:23:49
selwynning
once to generate the svg with the svg backend, and once to generate the presentations for emacs
14:24:39
selwynning
probably the best thing to do is to call it once on the svg backend, and replay the output records on the other backend
14:28:33
selwynning
one stream is a drawing stream that creates the svg and the other creates areas for presentations that are sent to emacs
14:30:10
selwynning
i don't know much about how they are presented, i never dipped into that part of the code
14:31:07
jackdaniel
why for crying out loud github intercepts C-f to introduce its own, slow, buggy and most notably unwanted search box?
14:33:32
selwynning
i can't remember the last time search was so useful but this is in large part because google has nerfed itself so much
14:34:08
jackdaniel
well, I'm leaving github first thing after making the next mcclim release, I just don't know where we should go yet - codeberg or gitlab.common-lisp.net
14:43:22
jackdaniel
selwynning: looking at this code I'm still not sure why you call the continuation on the emacs stream in the first place
14:47:55
jackdaniel
selwynning: take a look at this: http://turtleware.eu/static/paste/c3e4d09d-svg-bonanza.lisp
14:50:32
jackdaniel
if anyone is feeling like it then a pull request that makes invoke-with-otuput-to-drawing-stream return a second value as the stream output history (when applicable), just like open-window-stream - then that will be accepted as a useful thing
14:57:39
jackdaniel
above I've mentioned that github intercepted C-f (browser's search the page) with its own search box