[Top][All Lists]

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

Re: [Lynx-dev] [PATCH] DJGPP and MingW patch against 2.8.6rel.2

From: Thomas Dickey
Subject: Re: [Lynx-dev] [PATCH] DJGPP and MingW patch against 2.8.6rel.2
Date: Sun, 15 Oct 2006 20:34:50 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Oct 15, 2006 at 02:28:57PM -0700, Doug Kaufman wrote:
> Here are some small suggested changes to get the 2.8.7dev series going.
> Several different problems are rolled into one patch (attached), so I'll
> try to go over the problems and possible solutions.
> 1. When the "endwin" function was added for PDCurses in LYCurses.c, the
> code to clear the screen for DJGPP and MingW was (accidentally)
> orphaned, so both were leaving the screen filled at exit. In trying to
> put back the screen clearing code, I noticed that the MingW code had
> never really worked. This attempts to fix the screen clearing problem
> for the two platforms.

oh.  I had thought this particular case was due to a different intent.
Rather than requiring the screen to be cleared on exit (which is plausible),
the code as written was attempting to clear the screen but not actually
exit from curses.  That seemed to be because someone was avoiding some
visual effect when spawning a short subprocess (or that they didn't like
the convention of positioning the cursor at the lower-left).
> 3. For MingW, when I switched to gettext 0.15 from 0.11.5, gettext was
> getting undefined in LYMain.c. For reasons not clear to me, one of the
> changes in the gettext versions was to now define gettext for MingW as
> a macro. This didn't work with the code in LYMain.c. I chose to define
> "_INTL_REDIRECT_INLINE", which prevents gettext from being defined as a
> macro. It might be more general to instead wrap the undef of gettext in
> LYMain.c in "#ifndef _INTL_REDIRECT_MACROS", but I wasn't sure exactly
> what the undefining was supposed to do, so I left it MingW specific.

iirc, this was to fix a symbol redefinition.  Recent gettext is defining a
macro to replace the function (for no particularly good reason that I can see,
though I can easily imagine many of the arguments).
> 4. Per the recent discussion about being able to prevent downloading
> and saving to disk on Win98, where users have full control, I put in a
> define "LYNX_CRIPPLED" which, when defined at compile time, should make
> downloading and saving to disk difficult, and with no way to override
> this with command line arguments or settings in lynx.cfg.

will see - thanks

offhand though - it seems that adding a common symbol to replace the
normal true/false in the restrictions would be less clutter than ifdef's.
> I hope that I haven't introduced too many problems with these changes.

Thomas E. Dickey <address@hidden>

reply via email to

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