freenode/#clim - IRC Chatlog
Search
9:46:52
lukego
I'd like to show tooltip (pointer documentation) for each presentation on the screen even when no command is in progress. Any tips on how to obtain suitable text?
9:48:10
lukego
thanks I'll check that out. This might be tricky because with Emacs I have a preference for a tooltip I can precompute and store inside Emacs rather than having to call into Lisp/CLIM as the mouse is dragged.
9:48:32
jackdaniel
/however/ I think that this should be implemented differently (I still need to think about it before commenting); a presentation type mixin and an :after presentation method seems more straightforward than inventing a separate protocol
9:50:48
lukego
ideally I'd just like a method i can call on a presentation that gives me back a string. maybe that's Fred's GET-TOOLTIP-TEXT.
9:51:22
lukego
Emacs already has tooltip support over image regions and ideally I'll reuse that but just populate it with reasonable data.
10:04:39
lukego
I could also just bite the bullet and send asynchronous mouse events directly from Emacs to Lisp if that makes more sense.
10:05:39
jackdaniel
and tooltips which are proposed as an extension (and a feature that was requested a few times in the past)
10:09:28
lukego
thanks, I'll dig a bit, also into what works from the Emacs side e.g. whether mousemove events are actually realistic.
11:34:56
lukego
for now I made tooltips based on generic function (clim-emacs:tooltip PRESENTATION) that defaults to text from cl:describe. looks like https://imgur.com/a/PjGomSs
11:47:29
lukego
Trick for ACCEPT now will be to selectively enable/disable presentations in Emacs after the image is created. time to dive into image.el ...
11:55:16
lukego
maybe I should just create fresh image objects all the time but I'd probably need to do that for the complete history of all images ever rendered that are still in the repl scrollback etc. maybe cheap if it's only a text representation. let's poke a bit ....
11:56:26
lukego
maybe that's even a solution for highlighting presentations when the mouse is over them i.e. hack the SVG data to add a rectangle around the highlighted selection and rerender that
12:02:56
lukego
Have to think about the interaction style a bit here too... when Lisp calls ACCEPT how does Emacs react? Potentially frustrating it SLIME grabs the whole UI, e.g. synchronously reading mouse events, if the user might be doing something else e.g. in another buffer. also if there are multiple slime sessions have to be careful not to mix up the presentations & to handle case where multiple lisps are asking at once
12:04:42
lukego
Maybe simplest to skip fine-grained mouse tracking and just say that clicking on a presentation sends a result to ACCEPT if Lisp is waiting for one
12:07:46
lukego
maybe done in two steps. First, define a keymap for the image that maps a mouse-click gesture onto a slime-clim-accept command. Second, define an input context that automatically searches the Emacs heap and updates all image objects containing clim presentations to update their hot areas. I wonder if this last bit can be done efficiently or lazily...
12:10:01
lukego
tempting to try and maintain a list of images buffers to avoid searching all the buffers but not clear how to do that since in Emacs you can kill/yank images as you please
12:17:34
lukego
quick benchmark suggests that searching all buffers in my current Emacs session for images takes approximately 2 microseconds. that sounds promising.
12:19:47
lukego
So maybe... On each image set a text property (clim-session . SOCKET) to identify a CLIM pane belonging to a specific SLIME; when ACCEPT is called send a new input context and search for all matches of that property; update the properties on each image to suppress the presentations that aren't enabled.
12:31:29
lukego
and then the input context itself... Maybe Lisp just sends Emacs a list of (ARG1 ARG2 .. ARGN) where each ARG is a list of acceptable presentations? and then Emacs sends back the list (7 8 42) saying which presentations were chosen? why not?
12:39:17
lukego
This is a horrible idea but maybe it would make state tracking easy if I just negate the geometry of every non-allowed presentation i.e. move its mouse-sensitive region "off screen." then after input is selects just abs() them all
12:51:06
lukego
hm have to also think about what happens if there are multiple ACCEPT requests from the same SLIME session e.g. due to multiple threads calling accept, or ACCEPT being called recursively inside the debugger, etc. maybe not to do anything fancy but to easily return to a sane state.
12:52:24
lukego
Or maybe do something nice e.g. make an input context that is the union of all acceptable presentation for all ACCEPT requests and then ask the user to disambiguate when needed
12:57:19
lukego
er hm maybe this becomes the whole event loop can of worms e.g. have to think about which thread is blocked on ACCEPT and who is running the SWANK backend..
13:01:44
lukego
but also maybe this is the same problem that e.g. Y-OR-N-P-IN-EMACS has to deal with, can refer to how that works
13:39:27
jackdaniel
there is also (wip?) backend for windows scymtym works on, and there is a broadway backend (gtk basically) also by him