Gopher directory rendering problem

    Hello all!

    These days I have started playing with gopher and lynx.
And I
think there is an error in the way it renders the directory
listings:
the first and second items are rendered on the same line. (I
am using
the latest lynx stable version 2.8.6.)

    For example you could try gopher://gopher.floodgap.com/
and the
result would be:
                                  Gopher Menu

       Welcome to Floodgap Systems' official gopher server. 
     Floodgap has b
een serving the gopher community since
       1999 (formerly gopher.ptloma.edu).
[...]

    But the good result would be:
                                  Gopher Menu

       Welcome to Floodgap Systems' official gopher server.
       Floodgap has been serving the gopher community since
       1999 (formerly gopher.ptloma.edu).
[...]

    Or you could try gopher://gopher.quux.org/1/Archives and
obtain:
                                  Gopher Menu

(FILE) [1]Comprehensive Master Index (DIR) [2]Mailing Lists
 (DIR) [3]Online Books Initiative
[...]

    Thanks all.
    Ciprian.

    P.S.: Please keep me in the copy of the message, as I am
not on
the mailing list.


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On Sun, 16 Mar 2008, Ciprian Dorin Craciun wrote:

>    Hello all!
>
>    These days I have started playing with gopher and
lynx. And I
> think there is an error in the way it renders the
directory listings:
> the first and second items are rendered on the same
line. (I am using
> the latest lynx stable version 2.8.6.)

thanks - it's been a while since I'd seen a live gopher
site.

>    Or you could try gopher://gopher.quux.org/1/Archives
and obtain:
>                                  Gopher Menu
>
> (FILE) [1]Comprehensive Master Index (DIR) [2]Mailing
Lists
> (DIR) [3]Online Books Initiative
> [...]

I see (the second link is put on the end of the first
line).
(will take a closer look this evening...)

>    Thanks all.
>    Ciprian.
>
>    P.S.: Please keep me in the copy of the message, as
I am not on
> the mailing list.
>
>
> _______________________________________________
> Lynx-dev mailing list
> Lynx-devnongnu.org
> htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev
>

-- 
Thomas E. Dickey
http://invisible-island.n
et
ftp://invisible-island.net


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

Thomas Dickey dixit:

> thanks - it's been a while since I'd seen a live gopher
site.

gopher://gopher.semmel.ch/ from Ventilator, an author on the
german
news site http://symlink.ch/

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens
to hit upon it
when God enlightens him. Or only God invents algorithms, we
merely copy them.
If you don't believe in God, just consider God as Nature if
you won't deny
existence.		-- Coywolf Qi Hunt


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On Sun, 16 Mar 2008, Thorsten Glaser wrote:

> Thomas Dickey dixit:
>
>> thanks - it's been a while since I'd seen a live
gopher site.
>
> gopher://gopher.semmel.ch/ from Ventilator, an author
on the german
> news site http://symlink.ch/

...another.  The last time I thought of it, a few years ago,
I googled
around and was unable to find any.

-- 
Thomas E. Dickey
http://invisible-island.n
et
ftp://invisible-island.net


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

On Sun, 16 Mar 2008, Thorsten Glaser wrote:

> Thomas Dickey dixit:
>
>> thanks - it's been a while since I'd seen a live
gopher site.
>
> gopher://gopher.semmel.ch/ from Ventilator, an author
on the german
> news site http://symlink.ch/

Here's what happens: WWW/Library/Implementation/HTGopher.c
creates an HTML 
document in an internal stream, and puts most of it in a
<PRE>...</PRE>.

GridText is not seeing the first newline (which would split
the line) 
since the logic in src/HTML.c for HTML_put_character()
around line 350 for 
the HTML_PRE case is not seeing the me->inPRE flag set.

     case HTML_PRE:              /* Formatted text */
         /*
          * We guarantee that the style is up-to-date in
begin_litteral. But we
          * still want to strip r's.
          */
         if (c != 'r' &&
             !(c == 'n' && me->inLABEL
&& !me->inP) &&
             !(c == 'n' && !me->inPRE)) {     
<-- this condition should pass
             me->inP = TRUE;
             me->inLABEL = FALSE;
             HText_appendCharacter(me->text, c);
         }
         me->inPRE = TRUE;
         break;


In turn, that is not set because of this chunk in src/HTML.c
around line 
2270:

     case HTML_PRE:              /* Formatted text */
         /*
          * Set our inPRE flag to FALSE so that a newline
immediately following
          * the PRE start tag will be ignored. 
HTML_put_character() will set it
          * to TRUE when the first character within the PRE
block is received.
          * - FM
          */
         me->inPRE = FALSE;
         /* FALLTHRU */

Using that clue, I see that adding a PUT('n'); in
HTGopher.c after the 
START(HTML_PRE) call passes in the "newline immediately
following", which 
sets the flag, making the newline seen as a place to split
the line, etc.

The chunk in HTGopher.c looks like this now:

     END(HTML_H1);
     PUTC('n');
     START(HTML_PRE);
     PUTC('n');			<--- add this
     while ((ich = NEXT_CHAR) != EOF) {

-- 
Thomas E. Dickey
http://invisible-island.n
et
ftp://invisible-island.net


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

Thomas Dickey dixit:

>         * We guarantee that the style is up-to-date in
begin_litteral. But we

s/litteral/literal/

>         * still want to strip r's.

s/'s/s/

> Using that clue, I see that adding a PUT('n'); in
HTGopher.c after the
> START(HTML_PRE) call passes in the "newline
immediately following", which sets
> the flag, making the newline seen as a place to split
the line, etc.

Looks like you got it.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens
to hit upon it
when God enlightens him. Or only God invents algorithms, we
merely copy them.
If you don't believe in God, just consider God as Nature if
you won't deny
existence.		-- Coywolf Qi Hunt


_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev

    Thanks for your info! It works.

    I have attached a patch with the modification you have
suggested.

    Ciprian.

    P.S. I recently (re-)discovered the Gopher protocol and
it seemed
a very nice idea for a simple content distribution protocol
(and it
could be very easibly built into appliances). (Also I wanted
to try my
Erlang knowledge to build a Gopher server into it... And for
testing
purposes I used 7070 port, which doesn't work with
Firefox...)


On Mon, Mar 17, 2008 at 2:05 AM, Thomas Dickey
<dickeyhis.com> wrote:
> On Sun, 16 Mar 2008, Thorsten Glaser wrote:
>
>  > Thomas Dickey dixit:
>
> >
>  >> thanks - it's been a while since I'd seen a
live gopher site.
>  >
>  > gopher://gopher.semmel.ch/ from Ventilator, an
author on the german
>  > news site http://symlink.ch/
>
>  Here's what happens:
WWW/Library/Implementation/HTGopher.c creates an HTML
>  document in an internal stream, and puts most of it in
a <PRE>...</PRE>.
>
>  GridText is not seeing the first newline (which would
split the line)
>  since the logic in src/HTML.c for HTML_put_character()
around line 350 for
>  the HTML_PRE case is not seeing the me->inPRE flag
set.
>
>      case HTML_PRE:              /* Formatted text */
>          /*
>           * We guarantee that the style is up-to-date
in begin_litteral. But we
>           * still want to strip r's.
>           */
>          if (c != 'r' &&
>              !(c == 'n' && me->inLABEL
&& !me->inP) &&
>              !(c == 'n' && !me->inPRE)) {  
   <-- this condition should pass
>              me->inP = TRUE;
>              me->inLABEL = FALSE;
>              HText_appendCharacter(me->text, c);
>          }
>          me->inPRE = TRUE;
>          break;
>
>
>  In turn, that is not set because of this chunk in
src/HTML.c around line
>  2270:
>
>      case HTML_PRE:              /* Formatted text */
>          /*
>           * Set our inPRE flag to FALSE so that a
newline immediately following
>           * the PRE start tag will be ignored. 
HTML_put_character() will set it
>           * to TRUE when the first character within the
PRE block is received.
>           * - FM
>           */
>          me->inPRE = FALSE;
>          /* FALLTHRU */
>
>  Using that clue, I see that adding a PUT('n'); in
HTGopher.c after the
>  START(HTML_PRE) call passes in the "newline
immediately following", which
>  sets the flag, making the newline seen as a place to
split the line, etc.
>
>  The chunk in HTGopher.c looks like this now:
>
>      END(HTML_H1);
>      PUTC('n');
>      START(HTML_PRE);
>      PUTC('n');                        <--- add
this
>      while ((ich = NEXT_CHAR) != EOF) {
>
>
>
>  --
>  Thomas E. Dickey
>  http://invisible-island.n
et
>  ftp://invisible-island.net

_______________________________________________
Lynx-dev mailing list
Lynx-devnongnu.org
htt
p://lists.nongnu.org/mailman/listinfo/lynx-dev