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

Annoying Mouse bug and fix.

Expand Messages
  • Mike Hopkirk(hops)
    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
    Message 1 of 4 , Nov 15 12:57 PM
      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
    • 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 2 of 4 , Nov 16 12:31 AM
        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 3 of 4 , Nov 16 5:50 PM
          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 4 of 4 , Nov 30 1:53 PM
            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.