Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa01497;
          26 Dec 96 22:46 PST
To: jay@JIMI.CS.UNLV.EDU
Subject: bug-chimera apr 95
Date: Thu, 26 Dec 1996 22:46:49 -0800
From: Jay Nietling <jay@JIMI.CS.UNLV.EDU>


------- Forwarded Messages

Received: from deacon.cogsci.ed.ac.uk by JIMI.CS.UNLV.EDU id aa00989;
          1 Apr 95 8:28 PST
Received: from macbeth.cogsci.ed.ac.uk (macbeth.cogsci.ed.ac.uk [129.215.110.33]) by deacon.cogsci.ed.ac.uk (8.6.10/8.6.9) with SMTP id RAA17911 for <bug-chimera@cs.unlv.edu>; Sat, 1 Apr 1995 17:28:24 +0100
Date: Sat, 1 Apr 95 17:28:24 BST
Message-Id: <16332.9504011628@macbeth.cogsci.ed.ac.uk>
From: Tim Bradshaw <tfb@ed.ac.uk>
To: Chimera bug list <bug-chimera@cs.unlv.edu>
Subject: 1.65b13: forms widths?

I think that the widths of form fields are wrong (too wide) -- for
instance I have a field:

   <input name="name" size="52">

which comes out about 80 chars wide.  Mosaic gets it right, and older
chimeras (1.63, maybe previous 1.65 betas) did as well.

- --tim

------- Message 2

Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa10308;
          1 Apr 95 19:15 PST
To: Tim Bradshaw <tfb@ed.ac.uk>
cc: Chimera bug list <bug-chimera@cs.unlv.edu>
Subject: Re: 1.65b13: forms widths? 
In-reply-to: Your message of "Sat, 01 Apr 1995 17:28:24 -0000."
             <16332.9504011628@macbeth.cogsci.ed.ac.uk> 
Date: Sat, 01 Apr 1995 19:15:39 -0800
From: John Kilburg <john@cephas.ISRI.UNLV.EDU>

>I think that the widths of form fields are wrong (too wide) -- for
>instance I have a field:
>
>   <input name="name" size="52">
>
>which comes out about 80 chars wide.  Mosaic gets it right, and older
>chimeras (1.63, maybe previous 1.65 betas) did as well.

I will change it back.

I guess it doesn't really matter because of the use of the
scrolling text widget.

							-john

------- Message 3

Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa11046;
          1 Apr 95 20:14 PST
Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa11015;
          1 Apr 95 20:10 PST
To: chimera-announce@cephas.ISRI.UNLV.EDU
Subject: chimera 1.65
Date: Sat, 01 Apr 1995 20:10:05 -0800
From: John Kilburg <john@cephas.ISRI.UNLV.EDU>

I just released the real 1.65

ftp://ftp.cs.unlv.edu/pub/chimera/chimera-1.65.tar.gz

Yes, it is April 1st (at least in Las Vegas :).  No, this is not
a joke...depending on how you look at new releases of chimera.

							-john

------- Message 4

Received: from hydra.ae.utexas.edu by JIMI.CS.UNLV.EDU id aa27104;
          2 Apr 95 17:10 PDT
Received: by hydra.ae.utexas.edu; id AA13396; Sun, 2 Apr 1995 19:10:48 -0500
Date: Sun, 2 Apr 1995 19:10:48 -0500 (CDT)
From: Rob McMullen <rwmcm@hydra.ae.utexas.edu>
To: bug-chimera@cs.unlv.edu
Subject: URL display line for mouse pointer
Message-Id: <Pine.OSF.3.91.950402190929.13950A-100000@hydra.ae.utexas.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Not a bug, but a little mod that I wrote because I liked this feature in
Mosaic:  when the mouse pointer is on a hyperlink, the URL is displayed at
the bottom of the screen.  Diffs are for chimera 1.65.

diff -c src-orig/main.c src/main.c
*** src-orig/main.c	Sun Apr  2 18:50:01 1995
- --- src/main.c	Sun Apr  2 18:52:20 1995
***************
*** 1066,1071 ****
- --- 1066,1088 ----
    return;
  }
  
+ /* rwmcm */
+ /*
+  * AnchorURLDisplay
+  *
+  * Called when the mouse moves over an anchor
+  */
+ void
+ AnchorURLDisplay(w, c)
+ Widget w;
+ char *c;
+ {
+   Arg args[5];
+   
+   XtSetArg(args[0], XtNlabel, c);
+   XtSetValues(root.anchordisplay,args,1);
+ }
+ 
  /*
   * OpenDocument
   *
diff -c src-orig/widget.c src/widget.c
*** src-orig/widget.c	Sun Apr  2 18:50:01 1995
- --- src/widget.c	Sun Apr  2 18:50:39 1995
***************
*** 226,231 ****
- --- 226,242 ----
    XtAddCallback(r->w, WbNanchorCallback, Anchor, r);
  
    /*
+    * rwmcm: Sixth pane, the URL anchor display
+    */
+   XtSetArg(args[0], XtNjustify, XtJustifyLeft);
+   XtSetArg(args[1], XtNlabel, " ");
+   r->anchordisplay=XtCreateManagedWidget("anchordisplay",
+ 			  labelWidgetClass, paned,
+ 			  args, 2);
+   XtSetArg(args[0], WbNpointerMotionCallback, AnchorURLDisplay);
+   XtSetValues(r->w, args, 1);
+ 
+   /*
     * Set some callbacks for the HTML widget.
     */
    XtSetArg(args[0], WbNresolveImageFunction, ImageResolve);
diff -c src-orig/widget.h src/widget.h
*** src-orig/widget.h	Sun Apr  2 18:50:02 1995
- --- src/widget.h	Sun Apr  2 18:51:37 1995
***************
*** 89,94 ****
- --- 89,95 ----
    Widget search;
    Widget cancel;
    Widget quit;
+   Widget anchordisplay;	/* rwmcm */
    char *savestr;
    char *loadstr;
    char *printstr;
***************
*** 117,122 ****
- --- 118,124 ----
  void Quit();
  void OpenDocument();
  void Anchor();
+ void AnchorURLDisplay();
  void Home();
  void Back();
  void Help();


- -----
Rob McMullen              | Klein bottle for rent; inquire within.
rwmcm@orion.ae.utexas.edu | 


------- Message 5

Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa29736;
          2 Apr 95 20:29 PDT
To: bug-chimera@cephas.ISRI.UNLV.EDU
Subject: patch for 1.65
Date: Sun, 02 Apr 1995 20:29:38 -0700
From: John Kilburg <john@cephas.ISRI.UNLV.EDU>

*** http.c      Sun Apr  2 20:25:22 1995
- --- http.c.orig Sun Apr  2 20:28:44 1995
***************
*** 40,46 ****
  Document *d;
  int error_code;
  {
!   if (error_code >= 200 && error_code < 300)
    {
      if (error_code == 204) d->status = DS_NOTHING;
      else d->status = DS_OK;
- --- 40,46 ----
  Document *d;
  int error_code;
  {
!   if (error_code <= 200 && error_code < 300)
    {
      if (error_code == 204) d->status = DS_NOTHING;
      else d->status = DS_OK;


							-john

------- Message 6

Received: from convex.convex.com by JIMI.CS.UNLV.EDU id aa01138;
          2 Apr 95 22:01 PDT
Received: from mikey.convex.com by convex.convex.com (8.6.4.2/1.35)
	id AAA03866; Mon, 3 Apr 1995 00:01:07 -0500
Received: by mikey.convex.com (8.6.10/1.28)
	id AAA07230; Mon, 3 Apr 1995 00:01:06 -0500
From: David DeSimone <fox@mikey.convex.com>
Message-Id: <199504030501.AAA07230@mikey.convex.com>
Subject: Form widths (and heights)?
To: Chimera Bug List <bug-chimera@cs.unlv.edu>
Date: Mon, 3 Apr 1995 00:01:05 -0500 (CDT)
Reply-To: David DeSimone <fox@convex.convex.com>
X-Mailer: ELM [version 2.4 PL21]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1096      

Speaking of forms widths (and also heights), I've recently noticed
widgets have the wrong height set, or something.  For instance, the
following form:

    <FORM ACTION="whatever">
	<SELECT NAME="whatever" SIZE=4>
	    <OPTION> Text
	    <OPTION> More Text
	    <OPTION> Even More Text
	    <OPTION> Sheesh What a Lotta Text
	</SELECT>
    </FORM>

When this form is rendered by chimera, it always puts scrollbars (both
horizontal and vertical) on the scrolled list widget.  Judging by the
amount of scrolling, it would seem that the pixel calculation is just a
few shy of the mark.  Unfortunately I'm not much of an X programmer, so
I'm not sure where to look for this.

Then again, maybe it's due to some resource setting that I use.  All
I've done is change the major font resources to my liking; that could
have an effect, but I tried unsetting the resources and saw no change.

- -- 
David DeSimone    | "The doctrine of human equality reposes on this:
fox@convex.com    |  that there is no man really clever who has not
Convex Computers  |  found that he is stupid." -- Gilbert K. Chesterson

------- Message 7

Received: from snooky.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa02933;
          2 Apr 95 23:44 PDT
To: bug-chimera@cs.unlv.edu
Subject: Re: URL display line for mouse pointer 
In-reply-to: Your message of "Sun, 02 Apr 1995 19:10:48 CDT."
             <Pine.OSF.3.91.950402190929.13950A-100000@hydra.ae.utexas.edu> 
Date: Sun, 02 Apr 1995 23:44:50 -0700
From: "Steve E. Lumos" <slumos@snooky.CS.UNLV.EDU>

>Not a bug, but a little mod that I wrote because I liked this feature in
>Mosaic:  when the mouse pointer is on a hyperlink, the URL is displayed at
>the bottom of the screen.  Diffs are for chimera 1.65.

I would like to put my vote in for this as well.  I really don't
understand what the reluctance is.  People are acting like it's Not
The UNIX Way(tm), but isn't it the way of a good Internet citizen to
not go blazing across the intercontinental link during peek hours?
Even if not, I hate picking a link and having it take forever, THEN I
find out that it was in Japan or something (in which case I would've
either picked some other site with the same information, or waited
until later).

TTYL - Steve

------- Message 8

Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa18212; 3 Apr 95 11:43 PDT
Received: from [141.211.170.99] by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Mon, 03 Apr 95 12:57:54 -0400
From: Jim Rees <rees@umich.edu>
To: Chimera Lovers <bug-chimera@cs.unlv.edu>
Date: Mon, 03 Apr 1995 12:57:50 -0400
Subject: Re: URL display line for mouse pointer 
Sender: rees@citi.umich.edu
In-Reply-To: "Steve E. Lumos", Sun, 02 Apr 1995 23:44:50 PDT

  >Not a bug, but a little mod that I wrote because I liked this feature in
  >Mosaic:  when the mouse pointer is on a hyperlink, the URL is displayed at
  >the bottom of the screen.  Diffs are for chimera 1.65.
  
  I would like to put my vote in for this as well.  I really don't
  understand what the reluctance is.

Some of us really hate having things flicker at us when we drag the mouse
around.  I would suggest adding this feature, but making it configurable via
X resource.

------- Message 9

Received: from uni-sb.de by JIMI.CS.UNLV.EDU id aa19592; 3 Apr 95 12:30 PDT
Organization: Universitaet des Saarlandes
              D-66041 Saarbruecken, Germany
Received: from com-serv.dfki.uni-sb.de with SMTP
          by uni-sb.de (5.65++/UniSB-2.2/9502015)
          id AA03897; Mon, 3 Apr 95 21:25:09 +0200
Received: from wizard.dfki.uni-sb.de (wizard.dfki.uni-sb.de [134.96.188.95]) by com-serv.dfki.uni-sb.de (8.6.10/8.6.9) with ESMTP id VAA12605 for <bug-chimera@cs.unlv.edu>; Mon, 3 Apr 1995 21:25:12 +0200
Received: by wizard.dfki.uni-sb.de id VAA14327;
	Mon, 3 Apr 1995 21:24:05 +0200
From: Benjamin Lorenz <lorenz@dfki.uni-sb.de>
Message-Id: <199504031924.VAA14327@wizard.dfki.uni-sb.de>
Subject: Re: URL display line for mouse pointer
To: bug-chimera@cs.unlv.edu
Date: Mon, 3 Apr 1995 21:24:05 +0200 (MET DST)
In-Reply-To: <9504031916.AA25461@pfsparc01.phil15.uni-sb.de> from "Jim Rees" at Apr 3, 95 12:57:50 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 440       

> Some of us really hate having things flicker at us when we drag the mouse
> around.  I would suggest adding this feature, but making it configurable via
> X resource.

I like this idea, too.

Benni
- -- 
Benjamin Lorenz  )\._.,--....,'``.   lorenz@dfki.uni-sb.de
+49 681 372253  /,   _.. \   _\  (`._ ,.  +49 681 302-5333
Johannisstr. 15 `._.-(,_..'--(,_..'`-.;.' DFKI, D-66123 SB
D-66111 Saarbruecken           Universitaet des Saarlandes

------- Message 10

Received: from hydra.ae.utexas.edu by JIMI.CS.UNLV.EDU id aa28653;
          3 Apr 95 16:40 PDT
Received: by hydra.ae.utexas.edu; id AA14756; Mon, 3 Apr 1995 18:40:18 -0500
Date: Mon, 3 Apr 1995 18:40:17 -0500 (CDT)
From: Rob McMullen <rwmcm@hydra.ae.utexas.edu>
To: bug-chimera@cs.unlv.edu
Subject: Re: URL display line for mouse pointer
In-Reply-To: <199504031924.VAA14327@wizard.dfki.uni-sb.de>
Message-Id: <Pine.OSF.3.91.950403181032.14678A-100000@hydra.ae.utexas.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> > Some of us really hate having things flicker at us when we drag the mouse
> > around.  I would suggest adding this feature, but making it configurable via
> > X resource.
> 
> I like this idea, too.
> 

The resource configuration idea is certainly reasonable.  The diff 
follows...  (It again includes the original URL display line stuff from my
previous post.  In other words, it is for the vanilla 1.65 source.)

The new resource is anchorDisplay, so you'd put

Chimera.anchorDisplay:	false

in your ad file if you wanted to disable it.

Rob


Rob McMullen                    | Author of SciPlot Widget - Free x/y and polar
rwmcm@orion.ae.utexas.edu       | plotting widget for Xt.  Home page at
https://www.ae.utexas.edu/~rwmcm | https://www.ae.utexas.edu/~rwmcm/SciPlot.html


diff -c src-orig/main.c src/main.c
*** src-orig/main.c	Mon Apr  3 18:31:48 1995
- --- src/main.c	Mon Apr  3 18:23:56 1995
***************
*** 121,126 ****
- --- 121,128 ----
  	offset(showURL), XtRImmediate, (XtPointer)True },
    { "showTitle", XtCBoolean, XtRBoolean, sizeof(Boolean),
  	offset(showTitle), XtRImmediate, (XtPointer)True },
+   { "anchorDisplay", XtCBoolean, XtRBoolean, sizeof(Boolean),
+ 	offset(anchorDisplay), XtRImmediate, (XtPointer)True },
    { "button1Box", "BoxList", XtRString, sizeof(char *),
  	offset(button1Box), XtRString, (XtPointer)BUTTON_LIST },
    { "button2Box", "BoxList", XtRString, sizeof(char *),
***************
*** 1064,1069 ****
- --- 1066,1088 ----
    }
  
    return;
+ }
+ 
+ /* rwmcm */
+ /*
+  * AnchorURLDisplay
+  *
+  * Called when the mouse moves over an anchor
+  */
+ void
+ AnchorURLDisplay(w, c)
+ Widget w;
+ char *c;
+ {
+   Arg args[5];
+   
+   XtSetArg(args[0], XtNlabel, c);
+   XtSetValues(root.anchordisplay,args,1);
  }
  
  /*
diff -c src-orig/widget.c src/widget.c
*** src-orig/widget.c	Mon Apr  3 18:31:48 1995
- --- src/widget.c	Mon Apr  3 18:26:19 1995
***************
*** 226,231 ****
- --- 226,245 ----
    XtAddCallback(r->w, WbNanchorCallback, Anchor, r);
  
    /*
+    * rwmcm: Sixth pane, the URL anchor display
+    */
+   if (r->anchorDisplay)
+   {
+     XtSetArg(args[0], XtNjustify, XtJustifyLeft);
+     XtSetArg(args[1], XtNlabel, " ");
+     r->anchordisplay=XtCreateManagedWidget("anchordisplay",
+ 			  labelWidgetClass, paned,
+ 			  args, 2);
+     XtSetArg(args[0], WbNpointerMotionCallback, AnchorURLDisplay);
+     XtSetValues(r->w, args, 1);
+   }
+ 
+   /*
     * Set some callbacks for the HTML widget.
     */
    XtSetArg(args[0], WbNresolveImageFunction, ImageResolve);
diff -c src-orig/widget.h src/widget.h
*** src-orig/widget.h	Mon Apr  3 18:31:51 1995
- --- src/widget.h	Mon Apr  3 18:23:18 1995
***************
*** 50,55 ****
- --- 50,56 ----
    char *printerName; /* default printer */
    Boolean showURL; /* switch for the display of the current URL */
    Boolean showTitle; /* switch for the display of the current title */
+   Boolean anchorDisplay; /* display URL of current hyperlink */
    int statusUpdate; /* frequency of download status update */
    int inPort; /* the port that chimera listens on for data */
    char *httpProxy;
***************
*** 89,94 ****
- --- 90,96 ----
    Widget search;
    Widget cancel;
    Widget quit;
+   Widget anchordisplay;	/* rwmcm */
    char *savestr;
    char *loadstr;
    char *printstr;
***************
*** 117,122 ****
- --- 119,125 ----
  void Quit();
  void OpenDocument();
  void Anchor();
+ void AnchorURLDisplay();
  void Home();
  void Back();
  void Help();



------- Message 11

Received: from wn1.sci.kun.nl by JIMI.CS.UNLV.EDU id aa16119; 4 Apr 95 4:56 PDT
Received: from canteclaer.sci.kun.nl by wn1.sci.kun.nl via canteclaer.sci.kun.nl [131.174.132.34] with SMTP 
	id NAA06627 (8.6.10/2.9) for <bug-chimera@cephas.isri.unlv.edu>; Tue, 4 Apr 1995 13:56:01 +0200
Message-Id: <199504041156.NAA06627@wn1.sci.kun.nl>
To: bug-chimera@cephas.isri.unlv.edu
Subject: Chimera 1.65  src/main.c  SearchCallback bug ?
Date: Tue, 04 Apr 95 13:56:00 +0200
From: Michiel Boland <boland@sci.kun.nl>

Hi,

in src/main.c, SearchCallback is defined a second time w/o "static".
I assume the fix is trivial (i know almost nothing about C).

Here's the diff. This worked for me.


*** main.c.old  Sat Apr  1 03:45:19 1995
- --- main.c      Tue Apr  4 13:47:54 1995
***************
*** 1419,1421 ****
   */
! void
  SearchCallback(w, cldata, cbdata)
- --- 1419,1421 ----
   */
! static void
  SearchCallback(w, cldata, cbdata)


Michiel Boland <boland@sci.kun.nl>
University of Nijmegen
The Netherlands

------- Message 12

Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa16143; 4 Apr 95 4:58 PDT
Received: from [141.211.170.99] by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Tue, 04 Apr 95 07:57:34 -0400
From: Jim Rees <rees@umich.edu>
To: Chimera Lovers <bug-chimera@cs.unlv.edu>
Date: Tue, 04 Apr 1995 07:57:30 -0400
Subject: Imakefile bug
Sender: rees@citi.umich.edu

If you use the compat library, you'll need this patch to src/Imakefile.

% diff -cb Imakefile- Imakefile 
*** Imakefile-  Mon Mar 27 05:24:33 1995
- --- Imakefile   Tue Apr  4 07:53:09 1995
***************
*** 27,33 ****
  
  LOCAL_DEPLIBS    = ../common/libcommon.a ../mxw/libmxw.a \
                     ../libhtmlw/libhtmlw.a \
!                    ../xloadimage/libxloadimage.a $(COMPATLIB)
  
  AllTarget(chimera)
  
- --- 27,33 ----
  
  LOCAL_DEPLIBS    = ../common/libcommon.a ../mxw/libmxw.a \
                     ../libhtmlw/libhtmlw.a \
!                    ../xloadimage/libxloadimage.a $(DEPCOMPAT)
  
  AllTarget(chimera)
  

------- Message 13

Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa16985; 4 Apr 95 5:41 PDT
Received: from [141.211.170.99] by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Tue, 04 Apr 95 08:40:49 -0400
From: Jim Rees <rees@umich.edu>
To: Chimera Lovers <bug-chimera@cs.unlv.edu>
Date: Tue, 04 Apr 1995 08:40:44 -0400
Subject: gopher.c patch
Sender: rees@citi.umich.edu

Here's a patch to src/gopher.c that you may need depending on where your
time_t is defined.

% diff -cb gopher.c- gopher.c
*** gopher.c-   Sat Apr  1 22:18:03 1995
- --- gopher.c    Tue Apr  4 07:59:19 1995
***************
*** 10,15 ****
- --- 10,16 ----
  
  #include <stdio.h>
  #include <time.h>
+ #include <sys/types.h>
  
  #ifdef HAVE_STRING_H
  #include <string.h>

------- Message 14

Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa06144; 4 Apr 95 17:45 PDT
Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Tue, 04 Apr 95 20:44:28 -0400
From: Jim Rees <rees@umich.edu>
To: Chimera Lovers <bug-chimera@cs.unlv.edu>
Date: Tue, 04 Apr 1995 20:44:27 -0400
Subject: Seeing double
Sender: rees@citi.umich.edu

The html widget makes the unfortunate assumption that image depth and bits
per pixel are the same.  That's just not true for some servers, notably the
XFree86 VGA16 server runnning on Mach.  The fix is below.

I also fixed the image code to use the proper scanline padding, since
there's no good reason not to, and it will run much faster on some displays.

While I was at it, I removed the allocation of black and white from the
color map for mono displays, since some X servers can't handle that either.
This should be a benign change unless your two-color display is something
other than black and white.  It also runs faster.

I've tested these changes on a number of displays, from 1 to 8 bit, but I'd
be very interested in hearing any reports of displays on which these changes
don't work.  I think 16 and 24 bit displays will suffer the same bug, but I
didn't fix that part of the code because I have no such displays to test on.

Now, if I could just figure out some good way to compensate for the
non-square pixels on my Gateway Handbook (under 3 pounds, runs Unix), I'd be
happy.

Does anyone know how to get these fixes passed back to the html widget
maintainers for possible inclusion in Mosaic?

% diff -cb HTMLimages.c- HTMLimages.c
*** HTMLimages.c-       Fri Mar 24 05:20:28 1995
- --- HTMLimages.c        Tue Apr  4 20:16:10 1995
***************
*** 166,175 ****
    static int have_colors = 0;
    int NumCells;
  
    match = XAllocColor (dsp, colormap, colr);
    if (match == 0)
    {
- -     NumCells = DisplayCells (dsp, DefaultScreen (dsp));
      if (!have_colors)
      {
        for (i = 0; i < NumCells; i++)
- --- 166,183 ----
    static int have_colors = 0;
    int NumCells;
  
+   NumCells = XDisplayCells(dsp, DefaultScreen(dsp));
+   if (NumCells <= 2)
+   {
+     colr->pixel = (colr->red + colr->green + colr->blue > 98304) ?
+       WhitePixel(dsp, DefaultScreen(dsp)) : BlackPixel(dsp, DefaultScreen(dsp)) ;
+     XQueryColor(dsp, colormap, colr);
+     return;
+   }
+ 
    match = XAllocColor (dsp, colormap, colr);
    if (match == 0)
    {
      if (!have_colors)
      {
        for (i = 0; i < NumCells; i++)
***************
*** 298,303 ****
- --- 306,312 ----
  {
    int linepad, shiftnum;
    int shiftstart, shiftstop, shiftinc;
+   int bitsperpixel, scanline_pad;
    int bytesperline;
    int temp;
    int w, h;
***************
*** 308,314 ****
    unsigned long c;
    int rshift, gshift, bshift;
  
!   switch (depth)
    {
    case 6:
    case 8:
- --- 317,326 ----
    unsigned long c;
    int rshift, gshift, bshift;
  
!   bitsperpixel = _XGetBitsPerPixel(dsp, depth);
!   scanline_pad = _XGetScanlinePad(dsp, depth);
! 
!   switch (bitsperpixel)
    {
    case 6:
    case 8:
***************
*** 327,341 ****
      {
        shiftstart = 0;
        shiftstop = 8;
!       shiftinc = depth;
      }
      else
      {
!       shiftstart = 8 - depth;
!       shiftstop = -depth;
!       shiftinc = -depth;
      }
!     linepad = 8 - (width % 8);
      bit_data = (unsigned char *) XtMalloc (((width + linepad) * height)
                                           + 1);
      bitp = bit_data;
- --- 339,353 ----
      {
        shiftstart = 0;
        shiftstop = 8;
!       shiftinc = bitsperpixel;
      }
      else
      {
!       shiftstart = 8 - bitsperpixel;
!       shiftstop = -bitsperpixel;
!       shiftinc = -bitsperpixel;
      }
!     linepad = scanline_pad - (width % scanline_pad);
      bit_data = (unsigned char *) XtMalloc (((width + linepad) * height)
                                           + 1);
      bitp = bit_data;
***************
*** 367,377 ****
        }
        }
      }
!     bytesperline = (width + linepad) * depth / 8;
      newimage = XCreateImage (dsp,
                             DefaultVisual (dsp, DefaultScreen (dsp)),
                             depth, ZPixmap, 0, (char *) bit_data,
!                            (width + linepad), height, 8, bytesperline);
      break;
      /*
       * WARNING:  This depth 16 code is donated code for 16 bit
- --- 379,389 ----
        }
        }
      }
!     bytesperline = (width + linepad) * bitsperpixel / 8;
      newimage = XCreateImage (dsp,
                             DefaultVisual (dsp, DefaultScreen (dsp)),
                             depth, ZPixmap, 0, (char *) bit_data,
!                            (width + linepad), height, scanline_pad, bytesperline);
      break;
      /*
       * WARNING:  This depth 16 code is donated code for 16 bit

------- Message 15

Received: from cheviot.ncl.ac.uk by JIMI.CS.UNLV.EDU id aa21994;
          5 Apr 95 4:46 PDT
Received: from aire.ncl.ac.uk by cheviot.ncl.ac.uk id <MAA10813@cheviot.ncl.ac.uk>
  (8.6.10/ for ncl.ac.uk) with SMTP; Wed, 5 Apr 1995 12:10:53 +0100
Received: (njdc@localhost) by aire.ncl.ac.uk (8.6.7/8.6.x-cf revision 8 for SunOS 4.1.x) id MAA28667; Wed, 5 Apr 1995 12:09:22 +0100
From: "J.D.Coleman" <J.D.Coleman@newcastle.ac.uk>
Message-Id: <199504051109.MAA28667@aire.ncl.ac.uk>
Subject: Caching initialisation patches
To: Chimera Bugs Mailing List <bug-chimera@cs.unlv.edu>
Date: Wed, 5 Apr 1995 12:09:21 +0100 (BST)
Organisation: University of Newcastle Computing Service
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2151      

I was playing around with the cache settings and noticed a couple of things
that I thought could be improved.

First, if the cache parameters were set via X resources and not via a
cacheinfo file, the cache directory was not scanned in ScanCacheDirectories().
This was because the cache_list variable was still null.  I have made it point
to the default_cache structure.  Do we still need default_cache, or could
cache_list be filled in directly from the X resources?

Second, if a cacheinfo file contained a directory beginning with ~, the path
wasn't expanded, so the opendir failed.

Context diffs are against a vanilla 1.65, although they don't collide with
any of the previous patches.

J

- -- 
- --     Julian Coleman, Computing Service,     |    j.d.coleman@ncl.ac.uk
- --  Claremont Tower, University of Newcastle, | as967@cleveland.freenet.edu
- --   Newcastle upon Tyne, NE1 7RU, England.   | - - - - - - - - - - - - - -
- -- Tel +44-191-222-8068  Fax +44-191-222-8765 | Be wery, wery careful Wabbit

 ---8<---------------------------- Cut here ---------------------------->8---

*** src/cache.c.dist	Wed Mar 29 10:55:32 1995
- --- src/cache.c	Tue Apr  4 16:20:39 1995
***************
*** 196,202 ****
  {
    FILE *fp;
    char buffer[BUFSIZ];
!   char path[MAXPATHLEN + 1], domain[BUFSIZ];
    int max, ttl, clean;
    CacheInfo *ci, *ti;
    DIR *dp;
- --- 196,203 ----
  {
    FILE *fp;
    char buffer[BUFSIZ];
!   char domain[BUFSIZ];
!   char *path;
    int max, ttl, clean;
    CacheInfo *ci, *ti;
    DIR *dp;
***************
*** 208,216 ****
- --- 209,219 ----
    {
      if (buffer[0] == '#' || buffer[0] == '\n') continue;
  
+     path = alloc_mem(sizeof(char) * (MAXPATHLEN +1));
      if (sscanf(buffer, "%s %s %d %d %d",
  	       path, domain, &max, &ttl, &clean) == 5)
      {
+       path = FixFilename(path);
        if ((dp = opendir(path)) != NULL)
        {
  	ci = (CacheInfo *)alloc_mem(sizeof(CacheInfo));
***************
*** 364,369 ****
- --- 367,375 ----
    default_cache.clist = NULL;
    default_cache.next = NULL;
  
+   if (!cache_list) {
+     cache_list = &default_cache;
+   }
    ScanCacheDirectories();
  
    return;

------- Message 16

Received: from cheviot.ncl.ac.uk by JIMI.CS.UNLV.EDU id aa26691;
          5 Apr 95 8:48 PDT
Received: from blagdon.ncl.ac.uk by cheviot.ncl.ac.uk id <QAA12370@cheviot.ncl.ac.uk>
  (8.6.10/ for ncl.ac.uk) with SMTP; Wed, 5 Apr 1995 16:41:57 +0100
Received: (njkw@localhost) by blagdon.ncl.ac.uk (8.6.7/8.6.x-cf revision 8 for SunOS 4.1.x) id QAA27350; Wed, 5 Apr 1995 16:41:56 +0100
Date: Wed, 5 Apr 1995 16:41:56 +0100
From: Jim Wight <J.K.Wight@newcastle.ac.uk>
Message-Id: <199504051541.QAA27350@blagdon.ncl.ac.uk>
To: bug-chimera@cs.unlv.edu
Subject: Various nits
Reply-to: J.K.Wight@newcastle.ac.uk

1. The resizing behaviour of the Bookmark popup is silly. Given that
   the composite is a Paned I think we're stuck with allocating
   additional space to a single component. I suggest adding 

	*markbox.skipAdjust:	True

   to the resource file so that the lower of the two larger panes gets
   any extra space going.

2. It would be nice if the Bookmark popup remembered its new size
   (given 1 has been implemented) when next popped up.

3. It would be nice if the File popup directed keyboard input to the
   one and only place that keyboard input can go. All it requires is
   a single call to XtSetKeyboardFocus.

4. It would be nice if the File popup remembered its previous settings
   when next used.


I guess 2 and 4 are made more difficult as the popups are destroyed
when dismissed and recreated when needed. What is the rationale for
that policy? If it were me I would keep them hanging around.

Jim


------- Message 17

Received: from little-charlie.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa26420;
          6 Apr 95 1:42 PDT
To: J.K.Wight@newcastle.ac.uk
cc: bug-chimera@cs.unlv.edu
Subject: Re: Various nits 
In-reply-to: Your message of "Wed, 05 Apr 1995 16:41:56 BST."
             <199504051541.QAA27350@blagdon.ncl.ac.uk> 
Date: Thu, 06 Apr 1995 01:42:44 -0700
From: John Kilburg <john@little-charlie.ISRI.UNLV.EDU>

>3. It would be nice if the File popup directed keyboard input to the
>   one and only place that keyboard input can go. All it requires is
>   a single call to XtSetKeyboardFocus.

Oops, forgot.  I'll fix it.

>I guess 2 and 4 are made more difficult as the popups are destroyed
>when dismissed and recreated when needed. What is the rationale for
>that policy? If it were me I would keep them hanging around.

There is no rationale.  That is just the way it ended up.  I will
change it to popdown instead of destroy.

							-john

------- Message 18

Received: from wn1.sci.kun.nl by JIMI.CS.UNLV.EDU id aa28227; 6 Apr 95 3:59 PDT
Received: from canteclaer.sci.kun.nl by wn1.sci.kun.nl via canteclaer.sci.kun.nl [131.174.132.34] with SMTP 
	id MAA10169 (8.6.10/2.9) for <bug-chimera@cs.unlv.edu>; Thu, 6 Apr 1995 12:59:24 +0200
Message-Id: <199504061059.MAA10169@wn1.sci.kun.nl>
To: bug-chimera@cs.unlv.edu
Subject: How to display inline xpixmaps?
Date: Thu, 06 Apr 95 12:59:22 +0200
From: Michiel Boland <boland@sci.kun.nl>

Hi,

it appears that chimera can't display some inline xpm's
(notably the ones that are generated by ppmtoxpm)

Since chimera *can* display inline ppm, I reckoned I could put this
line in the convert file:

  inline image/x-xpixmap image/x-portable-pixmap xpmtoppm %s

however, this doesn't seem to work. In fact, chimera appears to ignore
this line altogether. Is this a bug or a feature? :)

regards,

Michiel Boland <boland@sci.kun.nl>
University of Nijmegen
The Netherlands

------- Message 19

Received: from utserv.mcc.ac.uk by JIMI.CS.UNLV.EDU id aa16627;
          10 Apr 95 7:16 PDT
Received: from ursa.cns.umist.ac.uk by utserv.mcc.ac.uk with SMTP (PP);
          Mon, 10 Apr 1995 15:15:29 +0100
Received: from csc.umist.ac.uk (actually jack.csc.umist.ac.uk) 
          by ursa.cns.umist.ac.uk with SMTP (PP);
          Mon, 10 Apr 1995 15:16:18 +0100
From: j braham levy <braham@csc.umist.ac.uk>
Message-Id: <28440.9504101413@horatio.csc.umist.ac.uk>
Subject: chimera 1-65 bug
To: bug-chimera@cs.unlv.edu
Date: Mon, 10 Apr 95 15:13:19 BST
X-Mailer: ELM [version 2.3 PL11]

The static was left out of the following line the 1.65 in the file
main.c


static void
SearchCallback(w, cldata, cbdata)
Widget w;
XtPointer cldata, cbdata;
{

this of course causes a nasty during compilation (SunOS 4.1.1 3/80)

braham
- -- 
j braham levy                   | Control Systems Centre,
email: braham@csc.umist.ac.uk   | UMIST, PO Box 88,
Tel: +44-161-200-4672           | Manchester, M60 1QD, UK.
Fax: +44-161-200-4647           |

------- Message 20

Received: from utserv.mcc.ac.uk by JIMI.CS.UNLV.EDU id aa24058;
          12 Apr 95 2:33 PDT
Received: from ursa.cns.umist.ac.uk by utserv.mcc.ac.uk with SMTP (PP);
          Wed, 12 Apr 1995 10:32:40 +0100
Received: from csc.umist.ac.uk (actually jack.csc.umist.ac.uk) 
          by ursa.cns.umist.ac.uk with SMTP (PP);
          Wed, 12 Apr 1995 10:33:38 +0100
From: j braham levy <braham@csc.umist.ac.uk>
Message-Id: <29033.9504120930@horatio.csc.umist.ac.uk>
Subject: Chimera-1.65 bug
To: bug-chimera@cs.unlv.edu
Date: Wed, 12 Apr 95 10:30:35 BST
X-Mailer: ELM [version 2.3 PL11]

Possible bug

No way of specifying Xaw3d widget set as in previous versions %-).


Quick workround. Edit Makefile in src directory so that line with -lXaw
reads -lXaw3d then relink for 3d version.

braham
- -- 
j braham levy                   | Control Systems Centre,
email: braham@csc.umist.ac.uk   | UMIST, PO Box 88,
Tel: +44-161-200-4672           | Manchester, M60 1QD, UK.
Fax: +44-161-200-4647           |

------- Message 21

Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa03386;
          12 Apr 95 23:50 PDT
Received: from koppang.cs.tu-berlin.de (czyborra@koppang.cs.tu-berlin.de [130.149.26.17]) by mail.cs.tu-berlin.de (8.6.10/8.6.10) with ESMTP id IAA26494; Thu, 13 Apr 1995 08:50:49 +0200
Received: (czyborra@localhost) by koppang.cs.tu-berlin.de (8.6.10/8.6.6) id IAA27589; Thu, 13 Apr 1995 08:50:47 +0200
From: Roman Czyborra <czyborra@cs.tu-berlin.de>
To: Chimera Doctors <bug-chimera@cs.unlv.edu>
cc: Gerd Knorr <kraxel@cs.tu-berlin.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: easier downloading
Date: Thu, 13 Apr 1995 08:50:46 +0200
Message-ID: <czyborra950413085027579@koppang.cs.tu-berlin.de>

Two things have been bugging me in the chimera downloader: First of
all, it wasn't offering the original filename in the dialog box.
Secondly, it uncompressed when downloading.  I didn't want to
completely rule out decompression of ftp:*.gz in the convert file
altogether because I want to be able to launch all the necessary
viewers on Button 1 and because tar files can sit on http: as well.

*** src/main.c~	1995/04/13 03:17:24
- --- src/main.c	1995/04/13 06:12:08
***************
*** 920,929 ****
    }
  
    /*
!    * Convert needs to be called in case there is a transfer or content
!    * encoding.
     */
!   if (d->ptext == NULL)
    {
      /*
       * This frightens me.  I know it is bad but I can't think of anything
- --- 920,929 ----
    }e
  
    /*
!    * Convert needs to be called in case there is a content transfer or content
!    * encoding.  But not for downloads, says Roman.
     */
!   if (d->ptext == NULL && ! download)
    {
      /*
       * This frightens me.  I know it is bad but I can't think of anything
***************
*** 951,957 ****
    if (d->status == DS_OK &&
        (download || (d->content == NULL && d->pcontent == NULL)))
    {
!     CreateStrReq("filename", root.savestr, False, SaveOCallback,
  		 SaveDCallback, (XtPointer)d);
    }
    else if ((d->content != NULL && strcasecmp(d->content, "text/html") == 0) ||
- --- 951,976 ----
    if (d->status == DS_OK &&
        (download || (d->content == NULL && d->pcontent == NULL)))
    {
! 
!       /* Let's offer the save the downloaded file under the same name.
! 	 Roman Czyborra, 1995-04-13 */
!       
!       char *filename=NULL, *basename; int length;
! 
!       if (d->up) if (filename= d->up->filename) if (length = strlen(filename))
!       {
! 	  if (filename[length-1]=='/')
! 	  {
! 	      filename[length-1]='\0';
! 	  }
! 	  if (basename = strrchr (filename, '/'))
! 	  {
! 	      filename = basename + 1;
! 	  }
!       }
!       if (! filename) filename="";
! 
!       CreateStrReq("filename", filename, False, SaveOCallback,
  		 SaveDCallback, (XtPointer)d);
    }
    else if ((d->content != NULL && strcasecmp(d->content, "text/html") == 0) ||


------- Message 22

Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa11309; 13 Apr 95 4:27 PDT
Received: from [141.211.170.108] by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Thu, 13 Apr 95 07:26:33 -0400
From: Jim Rees <rees@umich.edu>
To: Chimera Lovers <bug-chimera@cs.unlv.edu>
Date: Thu, 13 Apr 1995 07:26:30 -0400
Subject: Re: easier downloading 
Sender: rees@citi.umich.edu
In-Reply-To: Roman Czyborra, Thu, 13 Apr 1995 08:50:46 +0200

  Two things have been bugging me in the chimera downloader: First of
  all, it wasn't offering the original filename in the dialog box.

Yes, I like this.  I suggested the file name thing to the Mosaic developers
once, and they rejected it on the grounds that you can't always know the
file name.  In my opinion it's very useful in the 95% of the cases where you
do know the file name.

What I'd like to see, and this has been suggested before on this list, is to
have the middle mouse immediately bring up a popup.  The popup would have
several buttons and a file name entry box.  It would also have a box showing
the full, absolute url of the link you had clicked on.  It would also
display the size and type of the object the link points to (by getting the
mime header from the server).  You could then select the url for pasting
into another document, or decide whether to do the download based on the
file size, or maybe other things I haven't even thought of.

------- Message 23

Received: from a37.iue.tuwien.ac.at by JIMI.CS.UNLV.EDU id aa06358;
          19 Apr 95 7:11 PDT
Received: from h50.iue.tuwien.ac.at (h50.iue.tuwien.ac.at [128.130.68.41]) by a37.iue.tuwien.ac.at (8.6.11/8.6.11) with SMTP id QAA25320 for <bug-chimera@cs.unlv.edu>; Wed, 19 Apr 1995 16:11:24 +0200
Message-Id: <199504191411.QAA25320@a37.iue.tuwien.ac.at>
Received: by h50.iue.tuwien.ac.at with SMTP
	(1.37.109.8/16.2) id AA03759; Wed, 19 Apr 1995 16:11:23 +0200
To: bug-chimera@cs.unlv.edu
Subject: Bug with "#" type urls
Date: Wed, 19 Apr 95 16:11:09 +0200
From: Martin Stiftinger <stifting@iue.tuwien.ac.at>

Hello!

As I had some core dumps with chimera 1.65 with "#" type urls
I made a purified version and found the following bug (I think
it is one) in url.c:



h51~/chimera-1.65/src$ diff -c url.c url.c.orig
*** url.c       Wed Apr 19 15:37:02 1995
- --- url.c.orig  Sun Mar 26 11:26:06 1995
***************
*** 173,179 ****
    }
  
    len = strlen(protocol) + strlen(hostname) + strlen(filename) +
!         strlen(delim) + strlen(anchor) + 11;
    u = alloc_mem(len + 1);
    if (up->port == 0)
    {
- --- 173,179 ----
    }
  
    len = strlen(protocol) + strlen(hostname) + strlen(filename) +
!         strlen(delim) + 11;
    u = alloc_mem(len + 1);
    if (up->port == 0)
    {

Martin
_______________________________________________________________________________

  Martin Stiftinger
  Institute for Microelectronics         phone:  xx43-1-58801-3719
  Technical University Vienna            FAX  :  xx43-1-5059224
  Gusshausstrasse 27-29/360
  A-1040  Vienna                         email:  stiftinger@iue.tuwien.ac.at
  A U S T R I A / Europe                         stiftinger@eueclu.tuwien.ac.at
_______________________________________________________________________________

------- Message 24

Received: from deacon.cogsci.ed.ac.uk by JIMI.CS.UNLV.EDU id aa17494;
          19 Apr 95 13:22 PDT
Received: from scott.cogsci.ed.ac.uk (scott.cogsci.ed.ac.uk [129.215.144.3]) by deacon.cogsci.ed.ac.uk (8.6.10/8.6.9) with SMTP id VAA09268 for <bug-chimera@cs.unlv.edu>; Wed, 19 Apr 1995 21:21:34 +0100
Date: Wed, 19 Apr 95 21:21:33 BST
Message-Id: <2007.9504192021@scott.cogsci.ed.ac.uk>
From: Tim Bradshaw <tfb@ed.ac.uk>
To: Chimera bug list <bug-chimera@cs.unlv.edu>
Subject: Not a bug

What is the `Open' button meant to be for?  I just discovered that
typing a URL at the URL widget & hitting return works.  Given that,
surely the open button is pretty redundant?

- --tim

------- Message 25

Received: from URSA-MAJOR.SPDCC.COM by JIMI.CS.UNLV.EDU id aa03933;
          19 Apr 95 23:13 PDT
Received: by ursa-major.spdcc.com with sendmail-5.65/4.7 
	id <AA10324@ursa-major.spdcc.com>; Thu, 20 Apr 95 02:12:58 -0400
Message-Id: <9504200612.AA10324@ursa-major.spdcc.com>
Received: by crucible Thu, 20 Apr 95 01:46:31 EDT; id AA10018
Date: Thu, 20 Apr 95 01:46 EDT
From: Winston Edmond <wbe@psr.com>
Subject: Chimera confused after errors
To: bug-chimera@cs.unlv.edu

   On various occasions, I've seen chimera (either 1.63 or "real" 1.65)
get rather confused about where it is following an error during document
retrieval.  A situation that typically elicits the bug is:

* fetch a compound document (e.g., an html document with inline images)
* where there's an error retrieving one or more of the images
* then use OPEN and try to go to a new URL.

Chimera will claim that it has opened the new URL, but will display the
title and document associated with the partially successful compound
document retrieval (with X's in place of the missing images).  Since the
caching information is now wrong, attempts to OPEN the URL again
continue to display the "old" page.

For example, I got the following error while loading an HTML document
with images (I have no idea why, since all the images were on the same
system as the enclosing HTML page -- maybe chimera should optimize
repeated calls to gethostbyname() with the same domain name?):

  gethostbyname() failed: Non-authoritative `host not found', or server failed

I forget whether the mostly complete document was displayed.  In any
case, I then clicked on OPEN, entered a URL, clicked on OK, watched it
claim to fetch the data, and then saw it display the incompletely
fetched page claiming it was the new URL item.  Knowing better than to
fight that, I clicked on HOME (which worked) and tried to open another
new item by clicking on the highlighted text.  Chimera claimed the
remote server couldn't find the document even after several tries (and
yes, chimera printed the right server name and document name).  I quit
chimera, started up a new copy, and the problem was gone.

It feels like some piece of code is waiting for all the parts of the
compound document to arrive and isn't getting disabled when some parts
don't show up.  Then when the next (unrelated) thing(s) arrive(s), it
thinks it's finally gotten all the pieces to the old document.
 -WBE

------- Message 26

Received: from cass41.ast.cam.ac.uk by JIMI.CS.UNLV.EDU id aa13790;
          20 Apr 95 6:37 PDT
Received: from mamba.ast.cam.ac.uk by cass41 with smtp
	(Smail3.1.29.1 #9) id m0s1wPe-00005QC; Thu, 20 Apr 95 14:36 BST
Received: by mamba.ast.cam.ac.uk (Smail-3.1.28.1) 
	id m0s1wNd-0001VMC; Thu, 20 Apr 95 14:34 BST
Message-Id: <m0s1wNd-0001VMC@mamba.ast.cam.ac.uk>
Date: Thu, 20 Apr 95 14:34 BST
From: David Robinson <drtr@ast.cam.ac.uk>
To: bug-chimera@cs.unlv.edu
Cc: drtr@ast.cam.ac.uk
Content-Length: 837

Bug: Chimera does not properly encode form data using
application/x-www-form-urlencoded. It should always convert '+' to '%??'.

It seems you broke EscapeURL() after applying my earlier patch...

I do not subscribe to this list; comments via mail directly to me, please.

 David.

- ----------------------------- begin patch ---------------------------
*** url.c.orig	Sun Mar 26 10:26:06 1995
- --- url.c	Thu Apr 20 13:57:00 1995
***************
*** 49,55 ****
      {
        *n = '+';
      }
!     else if (isalnum(*cp) || strchr("$-_.'(),+!*", *cp) || (*cp=='+' && !s2p))
      {
        *n = *cp;
      }
- --- 49,55 ----
      {
        *n = '+';
      }
!     else if (isalnum(*cp) || strchr("$-_.'(),!*", *cp) || (*cp=='+' && !s2p))
      {
        *n = *cp;
      }
- ----------------------------- end patch ---------------------------

------- Message 27

Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa14426;
          20 Apr 95 7:12 PDT
Received: from titanic.cs.tu-berlin.de (czyborra@titanic.cs.tu-berlin.de [130.149.18.9]) by mail.cs.tu-berlin.de (8.6.10/8.6.10) with ESMTP id QAA21931; Thu, 20 Apr 1995 16:08:51 +0200
Received: (czyborra@localhost) by titanic.cs.tu-berlin.de (8.6.10/8.6.6) id QAA23966; Thu, 20 Apr 1995 16:08:43 +0200
From: Roman Czyborra <czyborra@cs.tu-berlin.de>
To: Tim Bradshaw <tfb@ed.ac.uk>
Cc: Chimera bug list <bug-chimera@cs.unlv.edu>
Subject: Re: Not a bug
In-Reply-To: <2007.9504192021@scott.cogsci.ed.ac.uk>
	by tfb@ed.ac.uk dated 1995-4-19 21:21:33
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Date: Thu, 20 Apr 1995 16:08:42 +0200
Message-ID: <czyborra950420160823958@titanic.cs.tu-berlin.de>

> What is the `Open' button meant to be for?  I just discovered that
> typing a URL at the URL widget & hitting return works.  Given that,
> surely the open button is pretty redundant?

Editing the URL display is indeed a very nice feature.
The Open URL popup has still two advantages:

1. You can press Open, Clear and paste in the X selection

2. You can simply press o and don't need to steer the mouse.

If you don't want the Open button, you can always use

chimera -xrm \
\*button1Box:quit,home,back,source,reload,file,help,bookmark,search,cancel


------- Message 28

Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa04974;
          20 Apr 95 18:04 PDT
Received: from gorisa.cs.tu-berlin.de (czyborra@gorisa.cs.tu-berlin.de [130.149.18.36]) by mail.cs.tu-berlin.de (8.6.10/8.6.10) with ESMTP id DAA11576; Fri, 21 Apr 1995 03:03:52 +0200
Received: (czyborra@localhost) by gorisa.cs.tu-berlin.de (8.6.10/8.6.6) id DAA20262; Fri, 21 Apr 1995 03:03:50 +0200
From: Roman Czyborra <czyborra@cs.tu-berlin.de>
To: David Robinson <drtr@ast.cam.ac.uk>
Cc: bug-chimera@cs.unlv.edu
Subject: encoding + as %2B
In-Reply-To: <m0s1wNd-0001VMC@mamba.ast.cam.ac.uk>
	by drtr@ast.cam.ac.uk dated 1995-4-20 14:34
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Date: Fri, 21 Apr 1995 03:03:50 +0200
Message-ID: <czyborra950421030320254@gorisa.cs.tu-berlin.de>

> It should always convert '+' to '%??'.

RFC 1738 says:

   ... alphanumerics, the special characters "$-_.+!*'(),", and
   reserved characters used for their reserved purposes may be used
   unencoded within a URL.

But you're right that most CGI parsers convert '+' to ' ' even in
forms so that it seems wise to encode '+'.

> else if (isalnum(*cp) || strchr("$-_.'(),!*", *cp) || (*cp=='+' && !s2p))

You mean

	else if (isalnum (*cp) || strchr ("$-_.'(),!*", *cp))


------- Message 29

Received: from cass41.ast.cam.ac.uk by JIMI.CS.UNLV.EDU id aa20514;
          21 Apr 95 6:47 PDT
Received: from cass39.ast.cam.ac.uk by cass41 with smtp
	(Smail3.1.29.1 #9) id m0s2J15-00005rC; Fri, 21 Apr 95 14:45 BST
Received: by cass39.ast.cam.ac.uk (Smail3.1.29.1 #9)
	id m0s2J0z-0003p9C; Fri, 21 Apr 95 14:44 BST
Message-Id: <m0s2J0z-0003p9C@cass39.ast.cam.ac.uk>
Date: Fri, 21 Apr 95 14:44 BST
From: David Robinson <drtr@ast.cam.ac.uk>
To: czyborra@cs.tu-berlin.de
Cc: bug-chimera@cs.unlv.edu, drtr@ast.cam.ac.uk
Subject: Re: encoding + as %2B
Content-Length: 1617

Roman Czyborra wrote:
>> It should always convert '+' to '%??'.
>
>RFC 1738 says:
>
>   ... alphanumerics, the special characters "$-_.+!*'(),", and
>   reserved characters used for their reserved purposes may be used
>   unencoded within a URL.
>
>But you're right that most CGI parsers convert '+' to ' ' even in
>forms so that it seems wise to encode '+'.
>
>> else if (isalnum(*cp) || strchr("$-_.'(),!*", *cp) || (*cp=='+' && !s2p))
>
>You mean
>
>        else if (isalnum (*cp) || strchr ("$-_.'(),!*", *cp))

Sorry, no I don't. My original code line was correct.
It's actaully mostly in the RFC.

>RFC 1738 says:
>
>   ... alphanumerics, the special characters "$-_.+!*'(),", and
>   reserved characters used for their reserved purposes may be used
    ~~~~~~~~                           ~~~~~~~~~~~~~~~~~ ~~~
>   unencoded within a URL.

This tells you that it _might_ be permissable to send an unencoded '+'.
In the search part of a URL, '+' is a reserved character. The meaning reseved
for it is 'a separator'. In the context of a form (whose data is sent with
the mime encoding application/x-www-form-urlencoded) the space character
entered by the user is a separator, and so is translate to '+'. Whereas a '+'
character entered by the user does not have any special meaning, and so is
_not_ being used for its reserved purpose. In which case, it must be escaped.

In fact, your code not is not particularly bad. It simply encodes a '+'
unnecessarily. In the context of the path part of a URL, '+' is not a reserved
character. So, as per the RFC which you quoted, sending it unencoded is
allowed.

 David.

------- Message 30

Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa07565;
          24 Apr 95 19:04 PDT
Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Mon, 24 Apr 95 22:03:15 -0400
From: Jim Rees <rees@umich.edu>
To: Chimera Lovers <bug-chimera@cs.unlv.edu>
Date: Mon, 24 Apr 1995 22:03:14 -0400
Subject: The missing sgml codes
Sender: rees@citi.umich.edu

Some people seem to prefer the sgml escapes to the actual characters when
writing html.  I don't understand why.  Maybe they're stuck with some
ancient text editor, like /bin/ed, that won't edit 8859-1.  Or maybe they're
stuck on some broken machine like a Mac that has a non-standard native
character set.  Whatever the reason, it seems like a good idea to include
all the sgml character escapes in chimera.  If nothing else, the html spec
requires it.

I didn't type these in.  I grabbed them off a list and spent a minute or two
in emacs changing them into the proper form.  For testing purposes, there is
a list of sgml names for the 8859-1 characters at
https://www.uni-passau.de/~ramsch/iso8859-1.html .

*** HTMLamp.h-	Sat Mar  4 02:54:21 1995
- --- HTMLamp.h	Mon Apr 24 21:55:50 1995
***************
*** 67,72 ****
- --- 67,106 ----
  	{"AMP", '&'},
  	{"quot", '\"'},
  	{"QUOT", '\"'},
+ 
+ 	{"nbsp", '\240'},
+ 	{"iexcl", '\241'},
+ 	{"cent", '\242'},
+ 	{"pound", '\243'},
+ 	{"curren", '\244'},
+ 	{"yen", '\245'},
+ 	{"brvbar", '\246'},
+ 	{"sect", '\247'},
+ 	{"uml", '\250'},
+ 	{"copy", '\251'},
+ 	{"ordf", '\252'},
+ 	{"laquo", '\253'},
+ 	{"not", '\254'},
+ 	{"shy", '\255'},
+ 	{"reg", '\256'},
+ 	{"hibar", '\257'},
+ 	{"deg", '\260'},
+ 	{"plusmn", '\261'},
+ 	{"sup2", '\262'},
+ 	{"sup3", '\263'},
+ 	{"acute", '\264'},
+ 	{"micro", '\265'},
+ 	{"para", '\266'},
+ 	{"middot", '\267'},
+ 	{"cedil", '\270'},
+ 	{"sup1", '\271'},
+ 	{"ordm", '\272'},
+ 	{"raquo", '\273'},
+ 	{"frac14", '\274'},
+ 	{"frac12", '\275'},
+ 	{"frac34", '\276'},
+ 	{"iquest", '\277'},
+ 
  	{"Agrave", '\300'},
  	{"Aacute", '\301'},
  	{"Acirc", '\302'},
***************
*** 91,97 ****
  	{"Otilde", '\325'},
  	{"Ouml", '\326'},
  
! 	{"?", '\327'}, /* ? */
  
  	{"Oslash", '\330'},
  	{"Ugrave", '\331'},
- --- 125,131 ----
  	{"Otilde", '\325'},
  	{"Ouml", '\326'},
  
! 	{"times", '\327'},
  
  	{"Oslash", '\330'},
  	{"Ugrave", '\331'},
***************
*** 125,131 ****
  	{"otilde", '\365'},
  	{"ouml", '\366'},
  
! 	{"?", '\367'}, /* ? */
  
  	{"oslash", '\370'},
  	{"ugrave", '\371'},
- --- 159,165 ----
  	{"otilde", '\365'},
  	{"ouml", '\366'},
  
! 	{"divide", '\367'},
  
  	{"oslash", '\370'},
  	{"ugrave", '\371'},

------- Message 31

Received: from deacon.cogsci.ed.ac.uk by JIMI.CS.UNLV.EDU id aa12941;
          26 Apr 95 13:24 PDT
Received: from macbeth.cogsci.ed.ac.uk (macbeth.cogsci.ed.ac.uk [129.215.110.33]) by deacon.cogsci.ed.ac.uk (8.6.10/8.6.9) with SMTP id VAA00891 for <bug-chimera@cs.unlv.edu>; Wed, 26 Apr 1995 21:24:20 +0100
Date: Wed, 26 Apr 95 21:24:19 BST
Message-Id: <20068.9504262024@macbeth.cogsci.ed.ac.uk>
From: Tim Bradshaw <tfb@ed.ac.uk>
To: Chimera bug list <bug-chimera@cs.unlv.edu>
Subject: mailto.pl

The version of this that I have (which variously claims to be 1.0 or
1.0 -- two $Id$ lines!) doesn't work: it makes a nice form but when
sending exciting things happen and sendmail barfs at me with al sorts
of odd-looking addresses with + in.

I guess this might be to do with the +-encoding stuff that people
talked about, but I thought I applied that patch (perhaps I shouldn't
have)

Anyway, before I fight through it, does anyone have a fixed version?

Chimera is 1.65 with at least some of the patches that appeared here.

thanks

- --tim

------- Message 32

Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa20268;
          26 Apr 95 17:06 PDT
Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Wed, 26 Apr 95 20:05:19 -0400
From: Jim Rees <rees@umich.edu>
To: Chimera Lovers <bug-chimera@cs.unlv.edu>
Date: Wed, 26 Apr 1995 20:05:17 -0400
Subject: sharing the cache
Sender: rees@citi.umich.edu

I have a vague memory that we discussed this before, but I really think
there should be better sharing of cache files between instances of chimera.
As it is now, if a file is cached by one instance of chimera, another
instance won't load it from the cache but will instead fetch a fresh copy.
I suppose the cacheinfo file should go in the directory where the cache
files are stored, and the X resource should just point at the directories.

------- Message 33

Received: from rosebud.turing.toronto.edu by JIMI.CS.UNLV.EDU id aa26909;
          26 Apr 95 21:27 PDT
Received: by turing.toronto.edu id <5396>; Thu, 27 Apr 1995 00:27:50 -0400
From:	Smarasderagd <smarry@turing.toronto.edu>
To:	bug-chimera@cs.unlv.edu, rees@umich.edu
Subject: Re:  sharing the cache
Message-Id: <95Apr27.002750edt.5396@turing.toronto.edu>
Date:	Thu, 27 Apr 1995 00:27:47 -0400

Sharing the cache between running instances of chimera seems iffy to me.
They need to keep their views of the cache consistent with each other,
and that leads to race conditions aplenty unless care is taken, to
say nothing of problems resulting from NFS inconsistencies.

My first coherent thought after this was that a caching proxy server
would make more sense, but this raises the question of what the 'reload'
button is supposed to do.  Pressing 'reload' and getting yet another
copy of the proxy server's cached copy would be annoying.

You might use a scheme that maps URLs to file names and have chimera
instances just dump files in the cache directory, and have a reaper
process in or out of chimera that periodically scans it and deletes
items when it exceeds the specified size.

------- Message 34

Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa28113;
          26 Apr 95 22:03 PDT
To: Smarasderagd <smarry@turing.toronto.edu>
cc: bug-chimera@cs.unlv.edu, rees@umich.edu
Subject: Re: sharing the cache 
In-reply-to: Your message of "Thu, 27 Apr 1995 00:27:47 EDT."
             <95Apr27.002750edt.5396@turing.toronto.edu> 
Date: Wed, 26 Apr 1995 22:02:57 -0700
From: John Kilburg <john@cephas.ISRI.UNLV.EDU>

>Sharing the cache between running instances of chimera seems iffy to me.
>They need to keep their views of the cache consistent with each other,
>and that leads to race conditions aplenty unless care is taken, to
>say nothing of problems resulting from NFS inconsistencies.
>
>My first coherent thought after this was that a caching proxy server
>would make more sense, but this raises the question of what the 'reload'
>button is supposed to do.  Pressing 'reload' and getting yet another
>copy of the proxy server's cached copy would be annoying.

This is handled by sending

Pragma: no-cache

to the server when a reload is done.  Chimera does this or at least
it did last time I checked.

If everyone used proxy servers then chimera would only have to deal
with HTTP (although this is true now if everyone was willing to deal
with external protocols handlers for gopher, ftp,...).  It would make
my life easier :)

The problem is that setting up a proxy server is not something that
everyone wants to get involved with.

>You might use a scheme that maps URLs to file names and have chimera
>instances just dump files in the cache directory, and have a reaper
>process in or out of chimera that periodically scans it and deletes
>items when it exceeds the specified size.

If you are going to create a reaper then how about a mini-proxy server
with an X interface that the user can
control with multiple chimera's talking to the proxy?  Other browsers
could even share the same cache.  The current chimera can accept
connections from other programs.

							-john

------- Message 35

Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa28507;
          26 Apr 95 22:18 PDT
Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Thu, 27 Apr 95 01:17:54 -0400
From: Jim Rees <rees@umich.edu>
To: Chimera Lovers <bug-chimera@cs.unlv.edu>
Date: Thu, 27 Apr 95 01:17:48 EDT
Subject: Re: sharing the cache 
Sender: rees@citi.umich.edu
In-Reply-To: Smarasderagd, Thu, 27 Apr 95 00:27:47 EDT

  Sharing the cache between running instances of chimera seems iffy to me.
  They need to keep their views of the cache consistent with each other,
  and that leads to race conditions aplenty unless care is taken, to
  say nothing of problems resulting from NFS inconsistencies.

I think a single global lock on the cache directory would take care of it.
Obviously you wouldn't use NFS to share data; it was never intended for that
purpose.

  You might use a scheme that maps URLs to file names and have chimera
  instances just dump files in the cache directory, and have a reaper
  process in or out of chimera that periodically scans it and deletes
  items when it exceeds the specified size.

Isn't that how it works now?  I think the only thing missing is a way to
lock the cache (see above) and a check for new (or removed) files on each
load.

------- Message 36

Received: from URSA-MAJOR.SPDCC.COM by JIMI.CS.UNLV.EDU id aa01700;
          26 Apr 95 23:41 PDT
Received: by ursa-major.spdcc.com with sendmail-5.65/4.7 
	id <AA21763@ursa-major.spdcc.com>; Thu, 27 Apr 95 02:41:14 -0400
Message-Id: <9504270641.AA21763@ursa-major.spdcc.com>
Received: by crucible Thu, 27 Apr 95 02:35:57 EDT; id AA12049
Date: Thu, 27 Apr 95 02:35 EDT
From: Winston Edmond <wbe@psr.com>
Subject: Bug: "chimera url" should not make url the home page
To: bug-chimera@cs.unlv.edu

Bug: Starting chimera 1.65 with a URL on the command line causes that URL
     to be considered one's home page.  Pushing the HOME button goes to
     the initial URL, not to one's home page.
In case it matters, yes, a chimera*homeURL resource is defined.
 -WBE

------- Message 37

Received: from nic.lth.se by JIMI.CS.UNLV.EDU id aa06482; 27 Apr 95 0:58 PDT
Received: from gatekeeper.axis.se (roma.axis.se [193.44.28.2]) by nic.lth.se (8.6.12/8.6.12) with SMTP id JAA03571 for <bug-chimera@cs.unlv.edu>; Thu, 27 Apr 1995 09:58:02 +0200
Received: from axisab.axis.se by gatekeeper.axis.se with smtp
	(Smail3.1.29.0 #1) id m0s4OSV-000m3JC; Thu, 27 Apr 95 09:57 MET DST
Received: from axis.se by axisab.axis.se with smtp
	(Smail3.1.28.1 #1) id m0s4OSV-000phIC; Thu, 27 Apr 95 09:57 MET DST
Message-Id: <m0s4OSV-000phIC@axisab.axis.se>
To: bug-chimera@cs.unlv.edu
Subject: Bug? in search
X-Face: ";qfS@AVy6@.5R{>2LcAxmyV?RZ~3m^^du$]?z-ay|Oy,;y_(&j}Rlxyd}.[< 
	 cfx7Fu-c;Mk:_tYRh!)\:nB}b/`/eq'td^-efI\>:@m0`(BL/:H5NU]|MFw`* 
	 %R%$Vk+4_-h];!_wh)sPEg|KeGbQN9xY2i7jg/0<6;lmw"IIN9TWn0+>|}J.S 
	 KMh9gO$Aa`@U~s<MHLv&Wa``g%Iv
Date: Thu, 27 Apr 1995 09:57:53 +0200
From: Joergen Haegg <jh@axis.se>


I had some problems when I tried to search for a word
containing 8-bit characters.
Chimera only searched for the characters up to the first
eight bit character in the search pattern.

Bug?

(Sunos 5.3, chimera 1.64)

- -------
Joergen Haegg				jh@axis.se
Axis Communications AB			Snailmail: Axis Communications AB
Phone: +46 46 191849			Scheelevaegen 16
Fax:   +46 46 136130			S-223 70 LUND, Sweden

------- Message 38

Received: from URSA-MAJOR.SPDCC.COM by JIMI.CS.UNLV.EDU id aa21814;
          27 Apr 95 10:44 PDT
Received: by ursa-major.spdcc.com with sendmail-5.65/4.7 
	id <AA13292@ursa-major.spdcc.com>; Thu, 27 Apr 95 13:43:33 -0400
Message-Id: <9504271743.AA13292@ursa-major.spdcc.com>
Received: by crucible Thu, 27 Apr 95 13:14:28 EDT; id AA14803
Date: Thu, 27 Apr 95 13:14 EDT
From: Winston Edmond <wbe@psr.com>
Subject: "checked" in <FORM>
To: bug-chimera@cs.unlv.edu

   Either the authors of

	https://www.sonicimages.com/cgi-bin/order.html

did something wrong, or there's a bug in Chimera's initial display of a
series of yes/no items in a <FORM>.  The HTML source shows that the
authors tried to have all the "NO" boxes checked initially.  However,
only the first NO box was "checked" [filled in] in Chimera's display.
The remaining NO boxes, and all the YES boxes, were "not checked".
Clicking on a YES or NO box caused it to be suitably filled in, and the
opposing NO or YES box would be properly unmarked, so the problem is
limited to the initial display.

   Here's an excerpt from that <FORM>:
===========================================================================
<FORM METHOD="POST" ACTION="https://www.earthlink.net/cgi-bin/mailto">
<INPUT TYPE="hidden" NAME="recipient" VALUE="admin@sonicimages.com">
<P>
<INPUT TYPE="hidden" NAME="thankURL" VALUE="https://www.sonicimages.com/cgi-bin/thanks.html"><P>
<INPUT TYPE="hidden" NAME="formtype" VALUE="Registration">
<tt>
Please check below the <b>Christopher Franke</b> release(s) you are ordering:
<P>
<INPUT TYPE="radio" NAME="21Babylon5" VALUE="Yes">Yes Please! <INPUT TYPE="radio" NAME="21Babylon5" VALUE="No" checked>No Thanks! <font size=5>- Babylon 5 - Soundtrack</font><BR>
<INPUT TYPE="radio" NAME="22Klemania" VALUE="Yes">Yes Please! <INPUT TYPE="radio" NAME="22Klemania" VALUE="No" checked>No Thanks! <font size=5>- Klemania</font><BR>
<INPUT TYPE="radio" NAME="23LondonConcert" VALUE="Yes">Yes Please! <INPUT TYPE="radio" NAME="23LondonConcert" VALUE="No" checked>No Thanks! <font size=5>- The London Concert</font><BR>
<INPUT TYPE="radio" NAME="24EnchantingNature" VALUE="Yes">Yes Please! <INPUT TYPE="radio" NAME="24EnchantingNature" VALUE="No" checked>No Thanks! <font size=5>- Enchanting Nature</font><BR>
<INPUT TYPE="radio" NAME="25RavenSoundtrack" VALUE="Yes">Yes Please! <INPUT TYPE="radio" NAME="25RavenSoundtrack" VALUE="No" checked>No Thanks! <font size=5>- Raven Soundtrack</font><BR>
<INPUT TYPE="radio" NAME="26UniversalSoldier" VALUE="Yes">Yes Please! <INPUT TYPE="radio" NAME="26UniversalSoldier" VALUE="No" checked>No Thanks! <font size=5>- Universal Soldier Soundtrack</font><BR>
===========================================================================
 -WBE

------- Message 39

Received: from toad.lake.cs.wwu.EDU by JIMI.CS.UNLV.EDU id aa24445;
          27 Apr 95 11:45 PDT
Received: by toad.lake.cs.wwu.edu (5.0/SMI-SVR4)
	id AA29808; Thu, 27 Apr 1995 11:43:53 -0700
Date: Thu, 27 Apr 1995 11:43:51 -0700 (PDT)
From: KESINGER <n9146070@toad.lake.cs.wwu.edu>
To: bug-chimera@cs.unlv.edu
Subject: Re: "checked" in <FORM>
In-Reply-To: <9504271743.AA13292@ursa-major.spdcc.com>
Message-Id: <Pine.SUN.3.91.950427113501.29696A-100000@toad>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 1784



On Thu, 27 Apr 1995, Winston Edmond wrote:

>    Either the authors of
> 
> 	https://www.sonicimages.com/cgi-bin/order.html
> 
> did something wrong, or there's a bug in Chimera's initial display of a
> series of yes/no items in a <FORM>.  The HTML source shows that the
> authors tried to have all the "NO" boxes checked initially.  However,
> only the first NO box was "checked" [filled in] in Chimera's display.
> The remaining NO boxes, and all the YES boxes, were "not checked".
> Clicking on a YES or NO box caused it to be suitably filled in, and the
> opposing NO or YES box would be properly unmarked, so the problem is
> limited to the initial display.
> 
I had a similar problem.  My entries were in an ordered list, 
and each entry had a different name="". The structure looked like:

   line of text
   a  b  c  d  e
and c was marked checked for all lines.  Chimera showed the first one 
as checked, and didn't mark the rest.  I could select the buttons okay
otherwise.  These are radio buttons, BTW.  I can't post the URL by
employer request, but the source reads:
<li>Question 1....<br>
<input type="radio" name="main/0" value="0">Never
<input type="radio" name="main/0" value="1">Rarely
<input type="radio" name="main/0" value="2" checked >Sometimes
<input type="radio" name="main/0" value="3">Often
<input type="radio" name="main/0" value="4">Always
<li>Question 2<br>
<input type="radio" name="main/1" value="0">Never
<input type="radio" name="main/1" value="1">Rarely
<input type="radio" name="main/1" value="2" checked >Sometimes
<input type="radio" name="main/1" value="3">Often
<input type="radio" name="main/1" value="4">Alway 
etc.  

Other browsers that I've checked (Lynx and Netscape, for now)
handle this correctly, so I suspect a Chimera bug.

  --Jake 

------- Message 40

Received: from isy.liu.se by JIMI.CS.UNLV.EDU id aa29949; 28 Apr 95 7:34 PDT
Received: from dagobert.isy.liu.se by isy.liu.se (5.65b/isy.minimaster-V1.0b2)
	id AA09991; Fri, 28 Apr 95 16:33:56 +0200
Received: from dtr-gw.isy.liu.se (lancelot) by dagobert.isy.liu.se (4.0/SMI-4.0)
	id AA04414; Fri, 28 Apr 95 16:34:00 +0200
Received: from ladon.YP.krikelin by dtr-gw.isy.liu.se (4.1/SMI-4.1)
	id AA08899; Fri, 28 Apr 95 16:33:51 +0200
Date: Fri, 28 Apr 95 16:33:51 +0200
From: Jean-Jacques Moulis <jj@isy.liu.se>
Message-Id: <9504281433.AA08899@dtr-gw.isy.liu.se>
Received: by ladon.YP.krikelin (4.1/SMI-4.1)
	id AA00997; Fri, 28 Apr 95 16:34:32 +0200
To: bug-chimera@cs.unlv.edu
Cc:  
Subject: fixed-font

Not a bug, just a question.

How can I change the size of the fixed-font used to display HTML source and
the preformatted text.
- --

- -------------------------------------------------------------------------------
Jean-Jacques Moulis                                        Phone:   46-13281684
Dept of Electrical Engineering                               Fax:   46-13281339
S-581 83 Linkoeping University, Sweden                  Internet: jj@isy.liu.se
- -------------------------------------------------------------------------------


------- Message 41

Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa04128;
          28 Apr 95 10:06 PDT
Received: from titanic.cs.tu-berlin.de (czyborra@titanic.cs.tu-berlin.de [130.149.18.9]) by mail.cs.tu-berlin.de (8.6.10/8.6.10) with ESMTP id SAA13886; Fri, 28 Apr 1995 18:16:37 +0200
Received: (czyborra@localhost) by titanic.cs.tu-berlin.de (8.6.10/8.6.6) id SAA02880; Fri, 28 Apr 1995 18:15:19 +0200
From: Roman Czyborra <czyborra@cs.tu-berlin.de>
To: Jean-Jacques Moulis <jj@isy.liu.se>
Cc: bug-chimera@cs.unlv.edu
Subject: Re: fixed-font
In-Reply-To: <9504281433.AA08899@dtr-gw.isy.liu.se>
	by jj@isy.liu.se dated 1995-4-28 16:33:51
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Date: Fri, 28 Apr 1995 18:15:18 +0200
Message-ID: <czyborra95042818152872@titanic.cs.tu-berlin.de>

> How can I change the size of the fixed-font used to display HTML
> source and the preformatted text.

I've put the following lines in our /usr/X11/lib/app-defaults/Chimera
because I want to be able to read lines 80 characters wide:

*fixedFont:       -*-lucidatypewriter-medium-r-*-*-12-*-*-*-*-*-iso8859-1
*fixedboldFont:   -*-lucidatypewriter-bold-r-*-*-12-*-*-*-*-*-iso8859-1
*fixeditalicFont: -*-lucidatypewriter-medium-r-*-*-12-*-*-*-*-*-iso8859-1
*listingFont:     -*-lucidatypewriter-medium-r-*-*-12-*-*-*-*-*-iso8859-1
*plainFont:       -*-lucidatypewriter-medium-r-*-*-12-*-*-*-*-*-iso8859-1
*plainboldFont:   -*-lucidatypewriter-bold-r-*-*-12-*-*-*-*-*-iso8859-1
*plainitalicFont: -*-lucidatypewriter-medium-r-*-*-12-*-*-*-*-*-iso8859-1


------- Message 42

Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa05234;
          28 Apr 95 10:41 PDT
Received: from titanic.cs.tu-berlin.de (czyborra@titanic.cs.tu-berlin.de [130.149.18.9]) by mail.cs.tu-berlin.de (8.6.10/8.6.10) with ESMTP id TAA16395; Fri, 28 Apr 1995 19:41:52 +0200
Received: (czyborra@localhost) by titanic.cs.tu-berlin.de (8.6.10/8.6.6) id TAA03549; Fri, 28 Apr 1995 19:41:49 +0200
From: Roman Czyborra <czyborra@cs.tu-berlin.de>
To: Tim Bradshaw <tfb@ed.ac.uk>
Cc: Chimera bug list <bug-chimera@cs.unlv.edu>
Subject: Re: mailto.pl
In-Reply-To: <20068.9504262024@macbeth.cogsci.ed.ac.uk>
	by tfb@ed.ac.uk dated 1995-4-26 21:24:19
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Date: Fri, 28 Apr 1995 19:41:49 +0200
Message-ID: <czyborra95042819413541@titanic.cs.tu-berlin.de>

> The version of this that I have doesn't work: it makes a nice form
> but when sending exciting things happen and sendmail barfs at me
> with al sorts of odd-looking addresses with + in.

I don't know what mailto.pl you're talking about.
My mailto helper looks like this:

#!/bin/sh

read GET address HTTP

: ${MUA=pine}
xterm -e "$MUA" "$address" >&- &

echo "HTTP/1.0 204 No Content
Content-Type: text/html

<H1><IMG SRC="https://www/bilder/sendmail.gif" >mailto:$address</H1>
Compose your message to $address with $MUA..."

# Chimera ignores the 204 response and displays the text instead.


------- End of Forwarded Messages