libera/#clim - IRC Chatlog
Search
7:42:54
jackdaniel
lisp123w: mind that there are some disrapencies with clim 2.0 (and while some are adopted in mcclim, the specification we follow is clim 2.0 with our own corrections)
8:17:47
lisp123w
jackdaniel: Thanks, yeah I noted that too. Just trying to read from different angles for now to understand things better, but not using it as a 'reference'
8:41:32
jackdaniel
mind that lispworks clim guide is also a good read with better separation between "programmer" abstractions and "if you really want to tinker with clim" chapters
8:42:18
jackdaniel
loke: I'm working on incremental redisplay and your issue reports (from 2018!) provide valuable test cases, thanks
10:18:03
moon-child
approximately. Some of them may have made their way there by mistake, and some of them I think I have already read
10:22:18
lisp123w
beach: It's not too bad, I'm 55 pages in on the Franz manual, so will probably finish in about 2-3 days (don't need to memorize all the generic functions listed, just understand the main topics). Then probably skim through the LW equivalent. Apart from that, I have one book on my list that will take some time and PAIP is sort of there, but I'm not really motivated to do that right now
10:24:48
lisp123w
One issue with Lisp is that its intellectually stimulating, so its easy to get into the trap of reading all the wonderful material out there
10:31:30
lisp123w
It's a bitt off-topic (but on-topic at the same time), but a McCLIM based Emacs, sans IDE, could be a big hit
10:32:21
lisp123w
Since McClim supports graphics and other advanced functionality, but has a lot of the core concepts from Emacs. I know that the IDE part is quite hard to do, but "McClim Org Mode" might prove valuable
10:34:01
lisp123w
I was thinking outside of the IDE, just basic text editing, markdown preview (as shown a few days ago), IRC, Web Browser
10:34:48
moon-child
not that something useful would be less effort than an IDE. Quite the opposite, in fact
10:36:04
beach
lisp123w: I don't think it is reasonable to have applications such as a web browser or an IRC client as part of the editor. It is done that way in Emacs because Emacs is also a Lisp system. But we have a better Lisp system, so the editor could be but one component.
10:37:03
lisp123w
I see, so better to do LispOS then McClim-Emacs (although LispOS will presumably use McClim)
10:37:36
beach
lisp123w: No need for a LispOS. Just a Common Lisp image running McCLIM and various applications.
10:38:35
lisp123w
Okay. I guess as long as there is a window manager (like moon-child noted), that's sort of the glue IMO that makes all the parts of Emacs work well together
10:38:49
jackdaniel
well, mcclim (and common lisp in fact) is a great device for big balls of mud, defining a separate irc client and a separate text editor doesn't make it unfeasible to adopt both in a single frame
10:41:53
jackdaniel
(ftr some people call these big balls of muds a "melleable software", but the former has a nice ring to it:)
12:23:47
scymtym_
i can't think of any way to automatically decide whether the gadget output record closes over "obsolete" variables
12:24:40
jackdaniel
well, imo gadget should be always replaced unless it is wrapped in with-updating-output :cache-value t
12:27:11
scymtym_
certainly more orthogonal since gadget output records and incremental redisplay wouldn't be conflated
12:30:34
scymtym_
i have one final™ question regarding the interaction of clipping regions and "formatting" output records like tables and graphs: should the clipping region that was established around the creation of the formatting output record affect 1) the internally stored geometry information (e.g. line endpoints) 2) the bounding region of the output record 3) the sensitive region 4) the graphics visible on the screen? i think clear are
12:40:13
jackdaniel
bounding rectangle is used to determine things like record overlapping and to test for sensitivity (at least initially, later it may be precised more)
12:43:00
jackdaniel
also, regarding "internally stored geometry information", I wonder whether if the output record falls outside of the clipping area it should be recorded or not
12:43:47
jackdaniel
(after a thought, 2) is indeed quite complex, i.e it may be outside of the clipping region, because its bounding rectangle influenced other records and that's why it was moved outside)
12:51:09
scymtym_
i said it should affect the sensitive region in my opinion, so that seems clear (and this already works since GS-CLIP-MIXIN restricts the sensitive region to the clipping region)
12:52:10
scymtym_
yeah, 2) is difficult because of the effects on the placement of other output records and the cursor position
12:55:04
scymtym_
i tend to think that not affecting the bounding region is more predictable, but i can be more difficult in terms of achieving a result desired by the user (for example, producing an excerpt from a larger graph without lots of space around it)
12:55:40
scymtym_
other output records do not clip the bounding region. for example, (with-drawing-options (s :clipping-region (make-rectangle* 50 50 100 100)) (draw-line* s 0 0 100 100)) creates an output record of size 100x100
12:56:30
jackdaniel
yes, I think that bounding region of the output record should be part of its internal state after all
12:58:46
scymtym_
something like (with-drawing-options (s :clipping-region …) (format-graph-from-roots …)) "take up" as much space as the unclipped graph in terms of the bounding region
12:59:44
scymtym_
so, for example, letting F-G-F-R move the cursor and outputting text might produce a "gap"
13:00:34
jackdaniel
if it is some arbitrary clipping region, then you could translate coordinates to match imaginary 0,0 insider with-room-for-graphics with specified height and width (can we specify width? we should certainly)
13:00:38
scymtym_
maybe you format the graph twice and capture the bounds of a certain node of interest in the first pass. it's just an example
13:01:03
jackdaniel
then I think that having it "bounding-rectangle-wise" stable would be actually less difficult for the user
13:02:32
scymtym_
sure, one can do the required record positioning and cursor movement manually. that's why i said "difficult" not "impossible"
13:02:40
jackdaniel
because if bounding rectangles change depending on the clipping region then offsets in the graph change as well