unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Miles Bader <miles@lsi.nec.co.jp>
Cc: emacs-devel@gnu.org
Subject: Re: signal handling bogosities
Date: 20 Dec 2002 10:44:53 +0900	[thread overview]
Message-ID: <buo4r99a2ga.fsf@mcspd15.ucom.lsi.nec.co.jp> (raw)
In-Reply-To: <20021219140425.GB28566@gnu.org>

Gerd Moellmann <gerd.moellmann@t-online.de> writes:
> My feeling is that the cost of restructuring the code to use an event
> loop could be pretty high, but I've never investigated this very
> deeply because Richard thought the current way of doing things is
> good, and an event loop is an abomination :).  There were lots of
> other things to do anyway, so I didn't pursue this further.
> 
> Specifically for mouse-highlighting there may be a cheaper solution,
> though.  IIRC, I once talked with Stefan Monnier about generating
> mouse-highlight input events for mouse highlights instead of doing the
> display directly when handling the mouse movement event (analogous to
> help-echo, for example).
> 
> When that is done, normal redisplay could be used to draw the
> mouse-highlight, but it would have to be extended to use mouse-face
> for part of the text, which it currently doesn't.  Also, the logic
> determining which parts of a buffer/window are to be redisplayed would
> have to be extended somehow so that the highlighted region is
> displayed despite the fact that there have been no buffer changes.

Perhaps I'm confused, but why can't the existing code that runs from the
signal handler just be called from the event loop instead, at least as
an easy first-step?

For instance, if the signal handler currently looks like:

   void signal_handler (...)
   {
     if (some_test)
       do_mouse_stuff (mouse_info);
     else if (some_other_test)
       do_exposure_stuff (other info);
   }

change it to be like:

   void signal_handler (...)
   {
     if (some_test)
       queue_mouse_event (mouse_info);
     else if (some_other_test)
       queue_exposure_event (exposure_info);
   }

   void event_loop_function (...)
   {
      while (event in event loop)
        {
          ...
          if (event->type == mouse_event)
            do_mouse_stuff (event->mouse_info)
          else if (event->type == exposure_event)
            do_exposure_stuff (event->exposure_info)
          ...
        }
   }

In other words, re-use as much of the existing code as possible, but
change the place where it's called.

My (vague) reasoning is that if it currently can be called from a
_signal handler_, which is possibly the worst possible case, then the
code must be pretty safe to call from just about anywhere -- so why not
the event loop?

Thanks,

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

  reply	other threads:[~2002-12-20  1:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <buo3cou2qxx.fsf@mcspd15.ucom.lsi.nec.co.jp>
2002-12-19 14:04 ` signal handling bogosities Gerd Moellmann
2002-12-20  1:44   ` Miles Bader [this message]
2002-12-20 10:25     ` Gerd Moellmann
2002-12-20 11:40       ` Kim F. Storm
2002-12-20 11:29         ` Gerd Moellmann
2002-12-25 11:52       ` Michael Livshin
2002-12-26  7:49         ` Richard Stallman
2002-12-31 16:54           ` Jan D.
2003-01-02 18:38             ` Richard Stallman
2003-01-04 12:33               ` Jan D.
2002-12-18 14:25 Bold by moving pixels problem Robert J. Chassell
2002-12-19 10:15 ` signal handling bogosities Miles Bader
2002-12-20 17:12   ` Richard Stallman
2002-12-20 17:46     ` Eli Zaretskii
2002-12-20 18:35     ` Alex Schroeder
2002-12-20 22:06     ` Miles Bader
2002-12-21 20:26       ` Richard Stallman
2002-12-21 23:42         ` Alex Schroeder
2002-12-23 20:58           ` Richard Stallman
2002-12-22  2:02         ` Miles Bader
2002-12-22  2:27     ` Miles Bader
2002-12-23 20:58       ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=buo4r99a2ga.fsf@mcspd15.ucom.lsi.nec.co.jp \
    --to=miles@lsi.nec.co.jp \
    --cc=emacs-devel@gnu.org \
    --cc=miles@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).