lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV signal handling


From: Bela Lubkin
Subject: Re: LYNX-DEV signal handling
Date: Tue, 18 Feb 1997 23:53:13 -0800

Foteos Macrides wrote:

>       It's really too hairy to explain in words, or to remember without
> walking through it with a debugger a few times to refresh one's memory.
> It's basically the evolution over many years of different design principles,
> plus patches to make it actually work for one or another flavor, that may
> or may not still be necessary for those flavors.

... and I was hoping to simplify and regularize some of this hairy
evolution of different design principles.  Now I'm having strong doubts
about the viability of such simplification/regularization projects in
Lynx because not enough collective memory exists about why things are
the way they are.  Phooey.

>       Lou originally wrote Lynx to treat interrupts as forced exits,
> normally, and as cancels under some circumstances.  That struck me as
> too confusing for the average users (they can't be sure what the
> consequence will be at one time versus another), so for VMS I made
> interrupts a prompted "Do you really want to quit?" signal, and a
> cancel (if possible at that point in whatever Lynx is doing) if the
> user doesn' reply 'y'es.  Lou didn't want to make it work that way
> for Unix too, so that was the start of ifdefing for different design
> principles.  I suspect most Unix folks would prefer the VMS behavior
> (Larry has indicated that preference a number of times).  Then it got
> hairier when the XMosaic select-based interrupts were added to Lynx
> as it's 'z'ap command.  Plus there's hairy code for deciding whether
> to put up a "You found a bug." screen.  Plus there's hairiness to
> make sure it works whether or not the image was built with LY_FIND_LEAKS
> defined. ...

Well, if you ever get the whim to do so, please do re-combine this
behavior, making the Unix (and whatever else) version of Lynx behave the
same as the VMS.  You are right that the current Unix behavior is
confusing.

>Bela<
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]