4:05 a.m.
So the mswindows problems with choice menus are caused by customize
generating menu descriptors like so:
["first" ("first") t]
Now accoridng to the popup-menu docs it seems this is obviously wrong - the
function is a list and so will be evaled with 'eval - "first" isn't a
function so we get failure.
Shouldn't customize actually generate:
["first" '(eval "first") t]?
Thanks
andy
8:50 a.m.
Andy Piper writes:
So the mswindows problems with choice menus are caused by customize
generating menu descriptors like so:
["first" ("first") t]
Now accoridng to the popup-menu docs it seems this is obviously wrong - the
function is a list and so will be evaled with 'eval - "first" isn't a
function so we get failure.
Shouldn't customize actually generate:
["first" '(eval "first") t]?
Wouldn't
["first" '(quote "first") t]?
do just as well? (untested, of course :)
Robert
--
10:35 a.m.
>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> Shouldn't customize actually generate:
Andy> ["first" '(eval "first") t]?
Assuming that the idea is to actually return the string "first", you
should lose the quote. I guess you're looking at about line 208 in
wid-edit.el like I am, and thinking it should be
(vector (car x) (list 'eval (car x)) t)))
or so? Actually, I think Robert Pluim's suggestion is appropriate
here since we know (stringp (car x)) in this context; use 'quote
instead of 'eval to make it a list, and convince get_gui_callback()
it's a real callback.
You give it a try on Windows native and Cygwin, Klaus gives it a try
in his environment, I'll give it a try on Linux. I don't think I want
to put it in to 21.4.6 but we'll see.
I have to say I can't see how the existing code can work on any
platform. This bears a closer look.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
11:06 a.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> You give it a try on Windows native and Cygwin, Klaus
Stephen> gives it a try in his environment, I'll give it a try on
Stephen> Linux. I don't think I want to put it in to 21.4.6 but
Stephen> we'll see.
Bletch.
Stephen> I have to say I can't see how the existing code can work
Stephen> on any platform. This bears a closer look.
I see how it works now. A hack, uncommented.
`widget-choose' uses 'get-popup-menu-response', which does _not_
execute the callback. Instead, it returns the callback as a pair (fn,
arg), and because the arg is a list = ("string"), fn <- 'eval, and arg
<- ("string"). `widget-choose' throws away fn, and grabs the car out
of arg.
So you're going to have to figure out how that thing is getting
executed, because it's not happenning in Lisp, and evidently it
doesn't happen on X.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
5:35 p.m.
Seems reasonable.
andy
At 09:50 AM 11/27/01 +0100, Robert Pluim wrote:
Andy Piper writes:
> So the mswindows problems with choice menus are caused by customize
> generating menu descriptors like so:
>
> ["first" ("first") t]
>
> Now accoridng to the popup-menu docs it seems this is obviously wrong
- the
> function is a list and so will be evaled with 'eval - "first"
isn't a
> function so we get failure.
>
> Shouldn't customize actually generate:
>
> ["first" '(eval "first") t]?
Wouldn't
["first" '(quote "first") t]?
do just as well? (untested, of course :)
Robert
--
5:44 p.m.
At 07:35 PM 11/27/01 +0900, Stephen J. Turnbull wrote:
or so? Actually, I think Robert Pluim's suggestion is
appropriate
here since we know (stringp (car x)) in this context; use 'quote
instead of 'eval to make it a list, and convince get_gui_callback()
it's a real callback.
Right. I have a vague recollection that the evaluation of msic_user_event's
allows for this sort of weirdness, however I think that in some
cicumstances (currently all under cygwin it seems) the evaluation gets done
much earlier and happens the "correct" way - hence the failure.
You give it a try on Windows native and Cygwin, Klaus gives it a try
in his environment, I'll give it a try on Linux. I don't think I want
to put it in to 21.4.6 but we'll see.
That's what the windows branch is for :) It also requires some extra code
to pull out the string correctly.
I have to say I can't see how the existing code can work on any
platform. This bears a closer look.
That's what I find weird, it obviously does work under UNIX.
andy
5:47 p.m.
At 08:06 PM 11/27/01 +0900, Stephen J. Turnbull wrote:
I see how it works now. A hack, uncommented.
`widget-choose' uses 'get-popup-menu-response', which does _not_
execute the callback. Instead, it returns the callback as a pair (fn,
arg), and because the arg is a list = ("string"), fn <- 'eval, and arg
<- ("string"). `widget-choose' throws away fn, and grabs the car out
of arg.
I still don't get it. get-popup-menu-response creates a popup menu when
when selected enqueues a misc ue with fn == eval and data == '("first"),
fn is applied to data all hell breaks loose. If I put debug code in
menubar-msw.c I can see this happening.
So you're going to have to figure out how that thing is getting
executed, because it's not happenning in Lisp, and evidently it
doesn't happen on X.
I still don't see why it doesn't happen on X. Also, whether it works under
X or not seems irrelevant, the implementation is relying on some
undocumented vagary of the runtime. Seems bogus to me.
andy
2:45 a.m.
Ben:
We have a problem on MS Windows where choice menus in Custom don't
work. What happens is that Custom constructs a menu of the form
("menu"
["first" ("first") t]
["second" ("second") t])
and calls `get-popup-menu-response' on it. Custom takes the event
returned, throws away the event-function (which is always `eval'),
grabs the car out of event-object, and returns it to the calling code.
In the MS Windows port under some circumstances this event is being
"executed", resulting in an attempt to funcall a string.
Andy thinks the idiom Custom is using requires unholy knowledge of the
implementation, I think it's a bit hackish, but is correct and should
be documented. I don't understand why MS Windows port barfs. Further
analysis follows.
Can you shed any light on this?
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> I still don't get it. get-popup-menu-response creates a
Andy> popup menu when when selected enqueues a misc ue with fn ==
Andy> eval and data == '("first"),
Not according to the docs:
------------------------------------------------------------------------
`get-popup-menu-response' is a compiled Lisp function
-- loaded from "/home/steve/Projects/XEmacs/Builds/21.4/lisp/menubar.elc"
(get-popup-menu-response MENU-DESC &optional EVENT)
Documentation:
Pop up the given menu and wait for a response.
This blocks until the response is received, and returns the misc-user
event that encapsulates the response. To execute it, you can do
(funcall (event-function response) (event-object response))
If no response was received, nil is returned.
MENU-DESC and EVENT are as in the call to `popup-menu'.
------------------------------------------------------------------------
Says nothing about "enqueue", and clearly implies that it won't be
enqueued by the comment about "you can". See also
`popup-menu-and-execute-in-window'.
Andy> fn is applied to data all hell breaks loose. If I put debug
Andy> code in menubar-msw.c I can see this happening.
Probably menubar-msw is being too helpful, and automatically
enqueuing.
> So you're going to have to figure out how that thing is
getting
> executed, because it's not happenning in Lisp, and evidently it
> doesn't happen on X.
Andy> I still don't see why it doesn't happen on X.
Because the API as documented above says (implies, that this is not
made clear is a bug) that it isn't supposed to.
Andy> Also, whether it works under X or not seems irrelevant, the
Andy> implementation is relying on some undocumented vagary of the
Andy> runtime. Seems bogus to me.
No, it's all documented, at least by implication and in context of
other functions available.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
6:13 a.m.
At 11:45 AM 11/28/01 +0900, Stephen J. Turnbull wrote:
Not according to the docs:
------------------------------------------------------------------------
`get-popup-menu-response' is a compiled Lisp function
-- loaded from "/home/steve/Projects/XEmacs/Builds/21.4/lisp/menubar.elc"
(get-popup-menu-response MENU-DESC &optional EVENT)
Documentation:
Pop up the given menu and wait for a response.
This blocks until the response is received, and returns the misc-user
event that encapsulates the response. To execute it, you can do
(funcall (event-function response) (event-object response))
If no response was received, nil is returned.
Right, but the way it acomplishes this is that the popup-menu enqueues the
event and then get-popup-menu-response dequeues the event from
unread-command-events relying on being able to get to it before the event
was processed. Unfortunately, I think some of the modal loop code (or
something) in mswindows can cause events to get processed in the meantime.
andy
8210
days inactive
8211
days old
9 comments
4 participants
participants (4)
-
Andy Piper -
Andy Piper -
Robert Pluim -
Stephen J. Turnbull