libera/#clim - IRC Chatlog
Search
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
21:10:56
jackdaniel
basically join-line-internal first sets all cursors positions and only after that merges lines
21:11:25
jackdaniel
but it sets the position as if the lines were already joined, hence that gives attempt to access beyond the end of a line
21:12:04
jackdaniel
that doesn't usually bite because the edit cursor as at the end of the line, but if you have a cursor in the line that follows it all breaks with the error