[Top][All Lists]

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

Re: lynx-dev Suggestion for merging the libcurses and libslang code

From: Klaus Weide
Subject: Re: lynx-dev Suggestion for merging the libcurses and libslang code
Date: Mon, 8 Nov 1999 18:36:26 -0600 (CST)

On Mon, 8 Nov 1999 address@hidden wrote:

> Now that there is a concerted effort to make pdcurses work for lynx, it
> might be appropriate look into eliminating explicit calls on libslang
> entirely from the lynx code.
> I say this because libslang has an slcurses interface, in which a subset
> of curses functions are simulated by slang calls within the library.  The
> Linux version of libslang is automatically an slcurses library, and there
> is an include file, slcurses.h, that sets up the correspondences.

My version of history goes like this:
Lynx had the (questionable) luck to be one of the first programs that
used slang as an alternative for (n)curses.  At the point in time when
lynx was slang-ified, the slcurses interface, as a drop-in replacement
for curses, was far less complete than it is now.  As a result, there
are numerous slangisms in the code.  Most of them wouldn't be there
if lynx had been slang-ified later, when just including slcurses.h would
have provided most or all of the needed curses functions and macros
under their curses names.

But those slangisms are now entrenched in the lynx code; getting rid of
them may be a lot of work.  So far I'm just talking about Unix (and
possibly VMS); with the inclusion of Windows and DOS specific code, the
situation has become more murky.  (As far a I can [or cannot] see).
The addition of special keymap handling code just for the slang code path
hasn't helped either (effectively the LYgetch() for slang (w/ Unix only? -
see USE_KEYMAPS) has forked from the LYgetch() used otherwise).

The special role that lynx has played in the history of slcurses can be
seen in the slcurses.h distributed with slang; up to version 1.2.2 at
least (the latest I have, for linux), ther is a special workaround for
lynx in that header

/* This is a temporary hack until lynx is fixed to not include this file. */
#ifndef LYCURSES_H

  .... normal slcurses interface ...

/* Lynx compatability */

  .... much reduced slcurses interface for lynx ...


No other app gets that kind of special treatment in slcurses.h.

(Lynx has longs since been "fixed" to not include slcurses.h afaik,
so the special treatment and the "Lynx compatability" section aren't
needed excpt perhaps if one tried to compile ancient lynx code with
slang.  The "Lynx compatability" section is (part of?) the contents
of LYCurses.h of some old Lynx version, probably incompatible with
what Lynx uses now.  Luckily it doesn't matter, since lynx doesn't
include the header at all.)

> Although Davis doesn't encourage this, I have compiled the Windows version
> of libslang with the slcurses.c functions included.
> When Davis was posting to this news group, he pointed out that slcurses
> may not have the complete curses functionality wanted in lynx. But, I find
> it difficult to believe that libpdcurses, which compiles to 50 KB on my
> machine, could really have that much more functionality than libslang that
> compiles to 400 KB.

If "When Davis was posting to this news group" refers to the time of first
slangification, around Lynx 2-5, then slcurses has changed a lot since

> One problem that may need looking at if this direction is followed is that
> libslang/libslcurses is designed to work best with a Linux terminal, and
> some versions of Davis's slrn will give error messages if TERM=vt100 is
> used instead of TERM=Linux.

In my experience of compiling Lynx against slang on linux, slang has never
been *that* inflexible.


reply via email to

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