Re: [Mac-emacs-devel] Overcoming 256MB Limitation?

[Andrew C. <ak...@cs...>]

d p chang <dp...@qu...> writes:

> Andrew Choi <ak...@cs...> writes:
> 
> > However, many things cause events to be generated in X, which can
> > simply be picked up by the main event loop and handled.  The Carbon
> > active scroll bars use callback functions to perform the scrolling.
> > It's not so easy to adapt this model (Carbon) to one with an event
> > loop that expect to receive active scrolling events (Emacs).
> 
> is this what you mean by poll? the initial callback continues to call
> the emacs code w/ a 'mouse down' until it moved out of the control
> (for the arrow control things) or 'mouse up'.

IIRC, one can't call Emacs code within a Mac Toolbox callback
function.  I can't explain the exact reason very well.  But see the
comments at the being of xdisp.c.

Mouse events are handled in XTread_socket in macterm.c by keeping
track of whether the mouse is down or up, checking the position of the
mouse every time through the function, and generating the appropriate
event to pass back to Emacs in the input_event buffer.  That's input
by `polling' instead of `event-driven', right?

> > Some events are even absent.  
> 
> What are these? (if you can remember off the top of your head). Just
> grepping though the source hasn't made these obvious

Two types that I can think of that would be nice to have are mouse
movement (in general) and movement of scroll bar control handles.

Andrew.