[Top][All Lists]

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

LYNX-DEV Lynx bugs submitted by Debian users.

From: Christian Hudon
Subject: LYNX-DEV Lynx bugs submitted by Debian users.
Date: Sun, 18 May 1997 00:33:36 -0400

Hi Lynx-dev people,

I'm maintaining a lynx package for the Debian distribution of Linux. I
thought you'd like to hear about (and hopefully help me fix) the bugs that
Debian users have filed on my lynx package. I have verified all these bugs
with lynx 2.7.1. I compile lynx for Debian using the "linux-slang"
entry. Im running the latest stable linux kernel. The versions of the
libraries that get linked with lynx are:

libc  : 5.4.23
slang : 0.99.38

Here we go with the bugs themselves...

Bug #6035,8406: lynx ignores SIGWINCH

Basically, lynx doesn't refresh itself when I resize xterm-color. I also
tried to send a SIGWINCH signal directly to lynx (using kill) and nothing
happens. I have to hit Ctrl-W to get lynx to repaint the screen. When I hit
Ctrl-W, it does repaint the screen according to the new dimensions. I tried
to trace this one through the lynx code using gdb/ddd. It looks like the
SIGWINCH signal doesn't get through to the signal handler when lynx is
waiting for keypresses. (I sent once a SIGWINCH signal when lynx wasn't
waiting for keypresses and it got through to the signal handler lynx had
installed.) By the way, shouldn't the 'recent_sizechange' variable (the one
that is set in the size_change signal handler) be declared as volatile?
Otherwise some compilers might optimize it away.

Bug #7920: lynx misinterprets ^G on quit confirmation

When the user presses Ctrl-G on the "Are you sure you want to quit? [Y]"
prompt, lynx exists. Shouldn't Ctrl-G cancel the 'quit' command and get the
user back to lynx?

Bug #7846: lynx redraws coloured links incorrectly

Italic or bold links initially show up as emboldened colour 0, but
after highlighting then unhilihting them, they become colour 1. 

A page where this bug shows up nicely is
Just move to the "[ Write Us | Add URL | Random Link | Info ]" bar.

Bug #8063: lynx saves gzipped files as not gzipped.

I do lynx ftp://whateveryouwant/file.diff.gz. To save this file I say I
want to print it, then select "Save to a local file". The filename to be
saved is "file.diff.gz", but lynx saves it uncompressed. It should offer
file.diff as filename or save it compressed.

Bug #7595: lyxn mailcap problems.

A few things...

a) lynx gets mailcap files 'backwards'. It uses the last entry that matches
the content-type and all the 'test' clauses (instead of the first one).

b) lynx doesn't understand all the % and %{} commands and passes them
directly to the shell. For example some text/* entries use %{charset} in
their test clause, but lynx doesn't expand it to the charset of the current

c) would it also be possible to add test "$DISPLAY" != "" and friends to
the list of "faked" tests? They're also fairly common, I believe.

I've attached a typical Debian mailcap and mime.types files to this
message. (No, we don't write these by hands. Debian packages which can
handle mime types call a home-brewed 'install-mime' program in their
postinst script, and the proper entries get automatically added to the
mailcap and mime.types files.)

Bug #3846: multiple <dt> in <dl> handling

Is there any reason why lynx puts a blank like between multiple <dt>
entries in a <dl>?

For example

<dt>keyword 1
<dt>keyword 2
Second paragraph

Quoting from the users' bug report:

> This doesn't make it clear that keyword1 and keyword2 both apply to
> paragraph (which is the meaning of consecutive <dt>'s without a
> <dd>).  There should either be an extra line after keyword2 (which
> would be ugly IMO) or the one after keyword1 should be removed.

> <dt>'s are supposed to be fairly short, and I don't think that
> displaying them next to each other even in a non-compact <dl> will be
> a problem.

What do you people say?

Bug #8001: Lynx don't work on mono console

When I set TERM to 'linux-m' and fire up lynx, it still comes up using
colors. I'm using an up-to-date version of Eric S, Raymond terminfo

That's it as far as bugs go. (Well, there are also a small patch that's
needed to compile lynx with Linux libc6 (aka glibc 2.0), which I'll post
here as soon as I get my hands onto it.

A feature request: it'd be nice if lynx's "file:" method could
automatically try file foo.gz if it doesn't find fill foo. Some http
servers (boa, for instance) already do that. It would allow people to
compress a set of web pages (the lynx help pages, say) and still be able to
access them using lynx without having to update all the links. If people
think that could be a useful feature, I could probably implement it and
submit a patch...

Finally, any reason why the default for lynxcgi is "any source and path
permitted" instead of "nothing permitted", like it is for lynxexec and
lynxprog? The latter seems safer...

Thanks for your time.


Attachment: mime.types
Description: Sample Debian mime.tupes file

Attachment: mailcap
Description: Sample Debian mailcap file

Attachment: pgpZ9dcurs1sP.pgp
Description: PGP signature

reply via email to

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