freenode/#clim - IRC Chatlog
Search
12:49:02
loke[m]
I'm confused again. If I want to provide some initial content in a call to ACCEPT, how do I do that?
12:49:23
loke[m]
:DEFAULT is not the right way, as that specifies what value should be returned if the input was empty.
12:52:55
scymtym
loke[m]: in clouseau, i was confused about that as well. a combination of :DEFAULT and :INSERT-DEFAULT did what i wanted. not sure what you want to achieve
12:53:55
scymtym
oh, ACCEPT. i used the above in the argument clause of a command definition. not sure whether ACCEPT also works like that
12:54:23
loke[m]
scymtym: I see. I tried that, I still have problems. I may have misattibuted the issue.
12:55:24
loke[m]
(clim:accept 'maxima-native-expr :stream ... :prompt ... :default X :insert-default t)
12:55:44
loke[m]
Here's the thing, X is either NIL (if the input is empty), or the previous expression.
12:56:46
loke[m]
However, if :DEFAULT is not nil, then no matter what I do, the call to ACCEPT always returns the default value. Even if I change it.
12:57:33
loke[m]
Now, everything works correctly when inputting numbers or strings or whatnot. The issue only happens with MAXIMA-NATIVE-EXPR, which is a class that wraps the internal Maxima representation of an equation.
15:55:53
loke[m]
scymtym: I have built a test case, would you have time to take a look at it and tell me if you know what I'm doing wrong?
15:56:38
scymtym
loke[m]: i can have a quick look, but no promises. if we can't work something out, maybe file a bug with the "question" tag
15:56:53
loke[m]
The two commands at the end of the file are identical with only a single difference: One of them has a default, and the other one don't.
15:57:12
loke[m]
However, in the default case, no matter what I type, it always returns the default.
16:02:48
loke[m]
scymtym: You mean without :DEFAULT? Yes. Then it reads the input, and correctly returns a BAR instance with the typed text.
16:03:56
scymtym
loke[m]: what i mean is i changed the second command (...-VALUES-WITH-DEFAULT) to not use ACCEPTING-VALUES and just call ACCEPT
16:04:08
loke[m]
However, if I use :DEFAULT, then it always returns whatever I passed into default, and doesn't care what I typed. The interesting thing is that if I put a (BREAK) here: https://github.com/lokedhs/clim-test/blob/master/command-input.lisp#L73
16:04:30
scymtym
then submitting the command returned the default value while editing and then submitting returned the edited value
16:04:46
loke[m]
Then that break never triggers. It exits using some kind of non-local exit, but for the life of me I can't find out how it's done. I added a HANDLER-BIND to catch any non-local exits, but it never hits.
16:06:55
scymtym
it encapsulates the stream into a special stream and creates special editing stream for the "input fields"
16:07:34
scymtym
those still ultimately call ACCEPT, but the scanning and re-scanning logic is very different
17:57:16
loke[m]
I created a video showing the animation: https://peertube.mastodon.host/videos/watch/3113d341-006d-4d35-b4c0-3cebdbdd77ae
18:57:02
jackdaniel
scymtym: it would be problematic, because we need to return the blank area presentation as a fallback in functions that doesn't have any contextual information
18:57:39
jackdaniel
i.e find-innermost-sheet (in tracking-pointer) and in map-applicable-translators
18:58:20
jackdaniel
in the latter case we have access to the context, in the former we'd have to rely on a dynamic context (which is kind of available though, because *input-context* should be bound)
19:05:26
scymtym
jackdaniel: i don't understand the problem. if we had a more general blank area presentation type and a more specific blank area presentation type, the latter including the pointer position, wouldn't the specialized presentation type also be suitable for contexts that expect the general one?
19:07:11
jackdaniel
you suggest, that we should /always/ return presentation of that subtype of a blank-area, not that we should *conditionally* return it depending on the input context?
19:07:26
scymtym
i suggested adding a presentation type roughly like (define-presentation-type blank-area-with-pointer-position (x y) :inherit-from (blank-area))
19:09:21
jackdaniel
also, what would be a practical purpose of adding "extra" presentation type instead of providing additional information in the blank-area presentation object?
19:10:19
scymtym
the idea was that it would appear to the client program as if a presentation created with (present ... `(blank-area-with-pointer-position ,x ,y)) had been clicked
19:11:37
jackdaniel
yes, but what is an advantage over appearing to the client program as if a presentation created with (present … `(blank-area ,x ,y)) had been clicked?
19:11:41
scymtym
it would also allow making translators for blank area with and without pointer position, unless i'm missing something
19:12:35
scymtym
one advantage is not having to invent a protocol to get the pointer position out of a special object
19:14:03
jackdaniel
this still may be encapsulated in a blank-area presentation, ie like (define-presentation-type blank-area (&key sheet x y)), that said how would you query x and y in the translator?
19:18:06
scymtym
yeah, i didn't implement it or anything. i just assumed there would be a way to get at the parameters in the relevant contexts
19:20:38
jackdaniel
I still don't think that there is a need to have a separate presentation type, especially that we'll always return one kind of object
19:21:34
jackdaniel
presentation-object could be fixed to a single value if we encode everything in the presentation type (I think)
19:21:34
scymtym
clients that optionally use the position can extract the parameters and check for NIL
19:22:36
jackdaniel
only *null-presentation* object will have nil,nil,nil (system won't return it though)
19:25:26
scymtym
i will have to look at that more. i just mentioned immediate ideas without much investigation
19:27:29
scymtym
"If frame-input-context-button-press-handler is called when the pointer is not over any applicable presentation, throw-highlighted-presentation must be called with a presentation of *null-presentation*" probably allows EQ-based tests. so we can't use it there?
19:28:46
jackdaniel
if we stick to the spec with this regard, then afaik we can't incorporate position into the blank-area
19:29:03
scymtym
we can make *NULL-PRESENTATION* a symbol-macro that disables the feature when used :)
19:29:07
jackdaniel
(we could modify slots in the "null object", but that won't work for translators that have source and destination as blank area)
19:31:07
scymtym
i'm mostly fine with violating/changing the spec in that regard since 1) relying on the object identity seems odd 2) this looks like something that was done based on performance considerations that may no longer apply
19:31:58
scymtym
if consing becomes an issue, we can cache and destructively update one or two objects of this kind
19:33:48
jackdaniel
right. I think that it is a nice-to-have feature and I came up with it because I needed to select regions on streams (for copy-area), but I don't have a dire need to have it in master; backend-manual branches are piling though :) will you find time to review the first pr upcoming week?
19:37:41
scymtym
yes, i think i was also embarrassed by the inability to do "drag rectangle to select" in that way. i think did blank-area-click -> command-with-tracking-pointer -> actual command as a workaround