libera/#clim - IRC Chatlog
Search
7:22:11
jackdaniel
looking at comments here: https://news.ycombinator.com/item?id=28825307 -- "how do you tell the rust programmer from other people?" - "he will tell you."
8:13:32
jackdaniel
scymtym: I was contemplating w-r-f-g and I came to the conclusion that the interpretation I've proposed is wrong (and that having the origin at the cursor position is the desired state of affairs) -- w-r-f-g is specified in "mixing text and graphics" so it is expected to inline graphics (inline vs block element in html terms)
8:36:35
jackdaniel
however to have that we should probably position the origin at the baseline, currently the cursor position is at the text line top
8:38:30
jackdaniel
(the cursor position is determined correctly, it is expected to be at the top of the line)
8:59:03
jackdaniel
I've submitted my doubts in a form of an issue; I'm not going to pursue correcting the implementation of this macro at the moment
9:51:27
scymtym
jackdaniel: i'm not sure i understand. for graphics to be positioned in-line, wouldn't the new cursor position be something like (max-x,0) instead of (0,0), both in the local coordinate system of the first-quadrant case?
9:55:49
jackdaniel
yes (when :move-cursor is t of course); the phrasing is a little ambigous -- "If the boolean move-cursor is true (the default), then after the graphic output is completed, the cursor is positioned past (immediately below) this origin"
9:56:05
jackdaniel
had the part in parens be (*and* immedietely below) then it would be clear I think
9:57:16
jackdaniel
because "past" would mean - /after/ the output horizontally (and /the same/ vertically)
9:58:15
jackdaniel
i.e similar to how loke explained in the issue https://github.com/McCLIM/McCLIM/issues/722
10:04:23
scymtym
i'm not sure what they meant. "immediately below", assuming "past" is vertically, could also mean that the start of the /next/ line should line up (same x1) with the left edge of the graphics (that would be some kind of "block" display, i guess)
10:07:13
scymtym
the behavior loke describes is useful irregardless of what W-R-F-G is supposed to do
10:15:27
jackdaniel
scymtym: I think that an important clue to the interpretation for this macro is its location: it is under "15.4.1 Mixing Text and Graphics" and before the specification we have "The following macro provides a convenient way to mix text and graphics on the same output stream."; but it is not conclusive
10:18:54
jackdaniel
clim-tos does "almost" what I've suggested as the correct implementation (that is, "inline"), except for that it doesn't concern itself with the baseline (i.e the record is not really part of the text stream nor does it influence the line height)
10:20:13
scymtym
seems like a sensible default. it is easy to add FRESH-LINE/TERPRI to get from inline to block, but the other way is more difficult for the user
10:21:01
scymtym
either way, i'm glad we have the cursor, output record and bounding rectangle protocols since they allow implementing any desired behavior if push comes to shove
10:22:56
jackdaniel
although confining the graphics to the baseline will be more tricly (because the baseline may change with some text "after" graphics)
10:32:08
scymtym
right, would require keeping track of elements of the current "open" line until it is "closed". but i assume we already do something like that for chunks of text
10:34:25
jackdaniel
yes, that would be fitting the output record in a wrapper that plays nicely with text output records