freenode/#clim - IRC Chatlog
Search
2:57:55
slyrus1
perhaps one day I'll go back to beirc and that crap won't happen, but beirc has its own (lack of) stability issues.
4:42:48
slyrus1
So back to what I was saying this morning... If I define a presentation-method on a presentation-type that does not have a corresponding CLOS class, we get the "Cannot find type for specializer" style-warnings. Is this something we should try to fix in define-presentation-method or should we fix all of our code such that there are CLOS classes for our presentation-types?
4:43:26
loke
slyrus1: I think that only happens if you define the presentation-type and use it in the same file
4:43:55
slyrus1
That could be -- but it doesn't happen if you have the corresponding CLOS clas, as far as I can tell.
4:49:29
slyrus1
Hmm... I've got a case here where it happens reliably without the defclass def'n and no error with the defclass defintion.
4:49:55
slyrus1
but, nevertheless, we should be able to define presentation types without the CLOS class, from what I gather the spec is saying.
4:58:53
slyrus1
I think the :compile-toplevel and :load-toplevel distinctions between record-presentation-type and %define-presentation-type are bogus.
5:04:06
jackdaniel
the gist of this behavior is this: we need to be able to attach to CLOS class of that name if it exists
5:04:46
slyrus1
OK, but the eval-when stuff should be handled under the covers by the define-presentation-type stuff, no?
5:04:55
jackdaniel
that's why we expand it differently. if it does not exist (what may be determined at load time), then we have presentation type without backing it class
5:06:05
jackdaniel
I'm just saying that it is not bogus, just a little tedious (like defconstant on ccl)
5:06:36
jackdaniel
https://github.com/McCLIM/McCLIM/commit/91d0279165ed7359393b0ad249cb6206d1d6e2b5#diff-9c90cd104f8f00c4e1074bb8b2d676cf
5:07:31
jackdaniel
I've added in a meantime climb:font-face, climb:font-size and climb:font-fixed-width
5:10:36
loke
jackdaniel: Is FONT-CHARACTER-WIDTH really necessary? A character is often not representable as a glyph (i.e. it doesn't have a “width” on its own). Usually, in Unicode, a smallest displayable unit is what is called a “grapheme cluster”
5:12:13
loke
jackdaniel: my argument against that one is the same, so can't that one simply map to FONT-STRING-WIDTH (with a single-character string)?
5:12:17
jackdaniel
also font-string-width goes after advance-width, while character-width takes left and right bearning
5:13:00
loke
jackdaniel: But that's very Latin-centric. In most other languages, things are much more complex.
5:13:33
jackdaniel
in non-latin language there is not such a thing as width of a standalone character?
5:13:55
loke
Most of the time, you can't talk about a single “character” as something that has a visual representation. The way it's displayed depends on the other unicode characters that surround it (or are attached to it)
5:14:43
jackdaniel
character width is meant for a standalone characters. if there isn't such a thing, then you just wont call font-character-width
5:14:58
loke
Or, they kanda do, but the “character” in such languages are not represented by a single Unicode codepoint.
5:15:36
jackdaniel
it is like complining, that you can't call (char string 1), becase some languages doesn't have characters (?)