libera/#clim - IRC Chatlog
Search
5:54:55
jackdaniel
i.e silica had a notion of "contracts" that roughly corresponds to protocols and protocol-classes (however that would be closer to scymtym attempt at "traits" I think)
5:56:39
jackdaniel
also, as you have probably noticed, silica is related only to the windowing substrate of CLIM II
5:58:53
jackdaniel
if you are interested in some parts of silica that were not included in clim ii, there is a commented out big chunk of the silica spec in Documentation/Specification/silica.tex, it contains a few classes and operators I think along with the description
8:11:47
jackdaniel
(with-input-editing (stream …) (read-gesture stream)) ; should this return after the successful gesture read, or only after encountering the activation gesture? ;(assuming no intervening rescans, i.e the gesture is not an input editing command)
8:12:24
jackdaniel
it seems that "our" implementation and the specification are not agreeing on what should happen
8:13:53
jackdaniel
the crux of the question: should the editor looping structure be implemented by the client code, or we should loop ourselves over the supplied body until the line is finished (i.e [enter] is pressed)
9:31:11
jackdaniel
OK, I think that I know what was the purpose of why it is specified to loop over the continuation
9:32:03
jackdaniel
even when the input is just fine for the continuation (i.e typed "Bar" is a desired command name), we don't want to return until the user confirms with the activation gesture - they may want to modify the line regardless
9:32:46
jackdaniel
so the body should implement the control loop to produce valid results, and we should additionally loop over that to allow modification even if parsing succeeds
13:57:39
jackdaniel
another interesting observation is that until now we were estabilishing new input editing streams for each recursive accept, and that explains why "backspacing" earlier than the currently typed argument was impossible