Loading ...
Sorry, an error occurred while loading the content.

RE: [jasspa] Annoying Mouse bug and fix.

Expand Messages
  • Steven Phillips
    Hops, Thanks for the submitted fix, its always good to get some help on maintaining ME (it also means that someone is using this enough to get really annoyed
    Message 1 of 4 , Nov 16, 2001
    • 0 Attachment
      Hops,

      Thanks for the submitted fix, its always good to get some help on
      maintaining ME (it also means that someone is using this enough to get
      really annoyed at a bug which in a perverse way is also nice to know :-).

      As Jon mentioned, I had found this bug and come up with a fix, see below,
      the mouse driver is very fiddly and has taken years to find all the bug, I'm
      hopeful that this is the last. Assuming we are fixing the same problem, the
      issue is more general than just the drag-region functions, can you please
      check my fix and confirm this fixes your issue as well, thanks.

      W.R.T. Hash tables I have spent considerable effort trying to make ME run as
      fast as possible, the main area where performance is an issue is in macro
      execution (who can type faster than ME can update?). One main area of this
      is the command-name to function look-up and for this a hash table is used
      (see efunc.h (horrid)). When using a hash table you either have a horrid
      burnt in table like the one found in efunc.h or you create one at start-up
      increasing the start-up time every time. The key-binding look-up is only
      used when typing, the performance is not so critical and given the horrid
      nature of hash table initialization this has remained a list (as have
      variables, functions (&add etc) and derivatives (!abort etc)). If
      significant benefit could be realised from the use of a hash table I would
      certainly consider the change.

      Steve

      *** mouse.emf.old Sun Aug 05 01:24:00 2001
      --- mouse.emf Mon Oct 15 08:09:01 2001
      ***************
      *** 562,570 ****
      --- 565,577 ----
      ; work out the mouse mask
      set-variable .mode $mouse-pos
      set-variable .mask &cat &cat &lef #l1 #l0 "%s" &rig #l1 &add #l0 4
      + set-variable .state 1
      + !elif ¬ .state
      + !return
      !elif &set #l0 &sin "-drop" #l1
      !force set-cursor-to-mouse
      set-variable #l1 &spr .mask "drop"
      + set-variable .state 0
      !else
      !return
      !endif

      > -----Original Message-----
      > From: Mike Hopkirk(hops) [mailto:hops@...]
      > Sent: 15 November 2001 21:58
      > To: jasspa@yahoogroups.com
      > Subject: [jasspa] Annoying Mouse bug and fix.
      >
      >
      > Running Jasspa-me Aug-2001 on linux RHat 6.2 ( built from source)
      >
      > - pressing MB1 in editor pane moves cursor to pressed place but
      > thereafter
      > refuses to action any keyboard input and only takes
      > additional mouse cursor movement (no mouse popup or selection)
      >
      > Applied two fixes - one in src and one in mouse.emf macro file
      > (.00 versions are original source)
      > main.c - execFunc code incorrect wrt comment
      >
      > *** main.c.00 Tue Aug 7 06:14:36 2001
      > --- main.c Tue Nov 13 16:39:36 2001
      > ***************
      > *** 277,290 ****
      > * so many hoops I've changed to input support so the
      > macros can fail
      > * in such a way as to indicate that they have not handled
      > this input,
      > * this allows them to pick and choose.
      > ! * The method chosen was to check the command variable
      > status if it aborted, if
      > ! * defined to "0" then its not handled the input
      > */
      > if((ii=curbp->inputFunc) >= 0)
      > {
      > uint8 *ss ;
      > if(((cmdstatus = (execFunc(ii,f,n) == TRUE))) ||
      > ! ((ss=getUsrLclCmdVar((uint8
      > *)"status",&(cmdTable[ii]->varList))) == errorm) || meAtoi(ss))
      > return cmdstatus ;
      > }
      > if(index >= 0)
      > --- 277,292 ----
      > * so many hoops I've changed to input support so the
      > macros can fail
      > * in such a way as to indicate that they have not handled
      > this input,
      > * this allows them to pick and choose.
      > ! * The method chosen was to check the command variable status if the
      > ! * macro aborted, if defined to "0" then its not handled the input
      > */
      > if((ii=curbp->inputFunc) >= 0)
      > {
      > uint8 *ss ;
      > if(((cmdstatus = (execFunc(ii,f,n) == TRUE))) ||
      > ! (((ss= getUsrLclCmdVar((uint8 *)"status",
      > ! &(cmdTable[ii]->varList))) == errorm)
      > ! && meAtoi(ss)))
      > return cmdstatus ;
      > }
      > if(index >= 0)
      >
      > In mouse.emf macro mouse-drop-t1 is setting up a buffer-input macro
      > (presumably for callback handling) but never clearing it
      > - above src change fixes problem but key action execution thereafter
      > is always doing buffer-input macro when doesn't need to.
      >
      > Liberally Added code to clear buffer-input macro - this probably
      > is overkill
      > but if fixes the redundant execution.
      >
      > *** mouse.emf.00 Tue Nov 13 15:53:58 2001
      > --- mouse.emf Tue Nov 13 16:36:10 2001
      > ***************
      > *** 227,232 ****
      > --- 227,233 ----
      > !elif &seq @cck "callback"
      > !if ¬ &seq @cc "mouse-drop-t1"
      > execute-named-command @cc
      > + set-variable $buffer-input ""
      > !return
      > !endif
      > !endif
      > ***************
      > *** 244,249 ****
      > --- 245,251 ----
      > -1 create-callback mouse-drop-t1
      > execute-line :mouse-word-select
      > !endif
      > + set-variable $buffer-input ""
      > !return
      > !endif
      > !endif
      > ***************
      > *** 272,286 ****
      > --- 274,291 ----
      > !elif &seq .drop @cck
      > show-region
      > 300 create-callback mouse-drop-t1
      > + set-variable $buffer-input ""
      > !return
      > !endif
      > set-variable $buffer-input .input
      > -1 create-callback mouse-drop-t1
      > !if &and &equ #l0 $window-line &equ #l1 $window-col
      > !if &seq @cck "callback"
      > + set-variable $buffer-input ""
      > !return
      > !endif
      > ; abort to tell ME to handle the actual input
      > + set-variable $buffer-input ""
      > set-variable .status "0"
      > !abort
      > !endif
      > ***************
      > *** 289,294 ****
      > --- 294,300 ----
      > !if &seq @cck "callback"
      > show-region
      > msshift
      > + set-variable $buffer-input ""
      > !return
      > !endif
      > copy-region
      > ***************
      > *** 302,307 ****
      > --- 308,314 ----
      > ; reset the last command to the copy-region
      > set-variable @cl copy-region
      > !if &seq @cck "callback"
      > + set-variable $buffer-input ""
      > !return
      > !endif
      > ; abort to tell ME to handle the actual input
      >
      > ... No job is finished until cleanup is done ...
      >
      >
      > Is there any particular reason for the binary search for matching
      > key bindings to function-names and function-names to code execution
      > rather than a hash table setup as later version of MicroEmacs (4.00) do ?
      >
      >
      > --
      > - hops
      > Everything disclaimed (including disclaimer)
      > ----<hops@...>-------------------------------------------
      > ----------
      > Mike Hopkirk (hops) | Whenever possible steal code
      > InterSAN Inc | -- Tom Duff. (ex) Bell Labs
      >
      >
      > __________________________________________________________________________
      >
      > This is an unmoderated list. JASSPA is not responsible for the content of
      > any material posted to this list.
      >
      > To unsubscribe, send a mail message to
      >
      > mailto:jasspa-unsubscribe@yahoogroups.com
      >
      > or visit http://groups.yahoo.com/group/jasspa and
      > modify your account settings manually.
      >
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Mike Hopkirk(hops)
      ... Interesting, what was once impossible to avoid is now impossible to find. I reverted my source and macros in an effort to get back to a broken case and the
      Message 2 of 4 , Nov 16, 2001
      • 0 Attachment
        On Fri Nov 16,2001 (09:31:19AM +0100), sphillips@...(Steven Phillips) wrote:
        > Hops,
        > ...

        > As Jon mentioned, I had found this bug and come up with a fix, see below,
        > the mouse driver is very fiddly and has taken years to find all the bug, I'm
        > hopeful that this is the last. Assuming we are fixing the same problem, the
        > issue is more general than just the drag-region functions, can you please
        > check my fix and confirm this fixes your issue as well, thanks.

        Interesting, what was once impossible to avoid is now impossible to find.

        I reverted my source and macros in an effort to get back to a broken
        case and the bug is now *not* showing up on either platform I use.
        Annoying since I eventually hit it every time I was using the editor
        till i fixed it...

        So I can't tell up front if your change fixed it as well or not...

        I'll apply your mods to an unchanged mouse.emf and revert to using
        a clean source build for a while - let you know if the bug shows up again
        Give me a week or so ...


        > W.R.T. Hash tables I have spent considerable effort trying to make ME run as
        > fast as possible, the main area where performance is an issue is in macro
        > execution (who can type faster than ME can update?). One main area of this
        > is the command-name to function look-up and for this a hash table is used
        > (see efunc.h (horrid)). When using a hash table you either have a horrid
        > burnt in table like the one found in efunc.h or you create one at start-up
        > increasing the start-up time every time.

        Other option is to provide a tool that takes a simple description ( like a
        list in source code) processes it into a preinitted hash table datastructure
        as part of the build process.
        Gives best of both, simple understandable table of items and
        fast access of hash without having to hand maintain it.

        > The key-binding look-up is only
        > used when typing, the performance is not so critical and given the horrid
        > nature of hash table initialization this has remained a list (as have
        > variables, functions (&add etc) and derivatives (!abort etc)). If
        > significant benefit could be realised from the use of a hash table I would
        > certainly consider the change.

        I'd think you'd get something speeding up macro execution
        from hashing the other things in macro files - variables, functions and !things.

        Still I guess it'd need proving.

        --
        - hops
        Everything disclaimed (including disclaimer)
        ----<hops@...>-----------------------------------------------------
        Mike Hopkirk (hops) | Whenever possible steal code
        InterSAN Inc | -- Tom Duff. (ex) Bell Labs
      • Mike Hopkirk(hops)
        ... I ve been using this for a coupla weeks now and I havent seen the mouse problem resurface so I d give it a provisional OK . -- - hops Everything
        Message 3 of 4 , Nov 30, 2001
        • 0 Attachment
          On Fri Nov 16,2001 (05:50:03PM -0800), hops@...(Mike Hopkirk(hops)) wrote:
          > On Fri Nov 16,2001 (09:31:19AM +0100), sphillips@...(Steven Phillips) wrote:

          > I'll apply your mods to an unchanged mouse.emf and revert to using
          > a clean source build for a while - let you know if the bug shows up again
          > Give me a week or so ...

          I've been using this for a coupla weeks now and I havent seen the mouse
          problem resurface so I'd give it a 'provisional OK'.


          --
          - hops
          Everything disclaimed (including disclaimer)
          ----<hops@...>-----------------------------------------------------
          Mike Hopkirk (hops) | Whenever possible steal code
          InterSAN Inc | -- Tom Duff. (ex) Bell Labs
        Your message has been successfully submitted and would be delivered to recipients shortly.