lynx-dev lynx and ncurses and gpm

[Klaus Weide]

I've been trying to understand the mouse code in lynx.  The NCURSES mouse
code basically works for me in an xterm.  But usually I don't use X but
work from the linux console.  The ncurses documentation suggests that
NCURSES mouse support should also work in this environment (I have the
gpm daemon running anyway).

First, I've found that, although I have gpm (several packages: binaries
and libraries) and ncurses (libncurses4 Debian package with associated
dev library package) installed, the binary /lib/libncurses.so.4.2 from
Debian was not compiled with gpm support (I didn't find this documented
anywhere, and the /usr/man/man3/mouse.3ncurses.gz that comes with it
suggests otherwise).

 -- Question 1:
    Is this common for all Linux distributions?  Are thare any Linux
    distributions with an ncurses package that has gpm support enabled?

So I got the latest ncurses from Tom Dickey's FTP site (patches up to
990410) and compiled it.  I also got newer gpm source (1.17.6) and 
recompiled the libgpm libraries, making sure both the new ncurses and
the new libgpm reference the new versions' -I and -L directories.

After recompiling lynx against the new ncurses lib, what I got was a 
binary that recognized mouse events (when invoked with -use_mouse,
of course), but the mouse support is mostly unusable.   The reason
is that mouse events handled by lynx are still also handled by the default
gpm "selection" handler.  So a middle-button click pastes the contents
of the selection buffer into the input stream, in addition to being
passed to lynx.

 -- Question 2:
    Are there any known applications running successfully with gpm
    mouse support *only* via ncurses (no direct calls to libgpm functions
    from the application)?

I traced this back to the way gpm is initialized by the call to Gpm_Open
in ncurses's lib_mouse.c:

        gpm_connect.eventMask = GPM_DOWN|GPM_UP;
        gpm_connect.defaultMask = ~gpm_connect.eventMask;
        gpm_connect.minMod = 0;
        gpm_connect.maxMod = ~0;

This is hardwired, there is no way the application can change these
default flags (unless it calls libgpm directly, losing the advantage
of the details-agnostic interface provided by ncurses completely).

Another formulation of question 2: are there any known applications
for which these defaults are appropriate?

I changed the initialization to

    #if USE_GPM_SUPPORT
    .....
    #include <linux/keyboard.h>     /* defines KG_* macros */
    #endif
    
    .....
            gpm_connect.eventMask = GPM_DOWN|GPM_UP;
            gpm_connect.defaultMask = ~(gpm_connect.eventMask|GPM_HARD);
            gpm_connect.minMod = 0;
            gpm_connect.maxMod = ~((1<<KG_SHIFT)|(1<<KG_SHIFTL)|(1<<KG_SHIFTR));

recompiled ncurses, and got a lynx with mouse support under gpm that 
works.  At least brief testing didn't shown problems that were specific
to the gpm environment, only those that are also there in an xterm.

The change to defaultMask prevents events handled by ncurses from being
also passed to the default handler, it is the crucial one.  The change
to maxMod allows mouse events with SHIFT modifiers to be handled by
the default selection (copy/paste) mechanism, so SHIFT can be used the
same way as under xterm.  (I'm not sure whether the SHIFTL and SHIFTR
are necessary or useful here.)

 -- Question 3:
    Tom, could these changes be incorporated into ncurses?
    (If there are no apllication for which the previous behavior was
    right, as I suspect, this should go into the to-be-released-soon
    ncurses.)

Rather than replacing one set of hardwired flags by another set of
hardwired flags, it would be nicer if the interface to ncurses mouse
functions could be enhanced so that the application has more control
at runtime over which events are handled or passed on.  The disadvantage
is that this would probably be specific to gpm, so the application cannot
any more be completely ignorant of how mouse support via ncurses is
provided.  After thinking about this a bit, it seems to me the best
way to support this would be not adding more functions to the interface,
but allowing the application or user to set an environment variable (say
GPM_CONNECT); if set, it would be parsed to determine mask values to
be used instead of the defaults before Gpm_Open is called.

There are already BUTTON_SHIFT, BUTTON_ALT, BUTTON_CTRL flags for
mousemask that could in principle be used for intializing the
gpm_connect structure appropriately (so that modifiers we are not
interested in could be passed to the default handler).  But this
seems to require significant changes - especially since the mouse
mask can change at runtime.

 -- Question 4:
    How are the chances of getting this kind of increased flexibility
    into the ncurses distribution?
    (Also, are there significant security issues with allowing
    control by an env variable? - Note it can hardly be worse than
    what there is currently.)    

 -------------------

Various other remarks steeming from recompiling-ncurses experience:

1. I added another model to the ncurses configuration, to get shared libs
   with debugging: they will be generated after 
       ./configure --with-debugshared
   as lib*_g.so[.M[.N]] (in case of linux, at least).  The changes are
   mostly straightforward, just a combination of --with-shared and
   --with-debug settings.  Tom, are you interested in patches?

2. What is --with-install-prefix supposed to do, and is it implemented
   correctly by configure?
   I used it as
        ./configure  --prefix=/usr/local --exec-prefix=/usr/local \
        --with-install-prefix=/usr/local/stow/ncurses-5.0-beta1-990403 ...

   and assumed that compiled-in paths would be configured to reference
   locations (for terminfo directory etc.) under /usr/local/, but
   actual installation on 'make install' would take place under
   the longer path (for example, terminfo files under
   /usr/local/stow/ncurses-5.0-beta1-990403/share/terminfo).
   But what I found was that actual installation actually takes place
   under /usr/local/stow/ncurses-5.0-beta1-990403/usr/local/,
                                                 ^^^^^^^^^^
   is that as intended?  It seems rather useless.

   (I am playing around with the GNU "stow" program, which assumes
   packages that are supposed to appear under /usr/local are actuall
   installed under /usr/local/stow/<packagename> and then maps all
   files into their expected locations as symlinks.)

3. Yep, the ABI has changed (just confirming...).
   However, running an older lynx binary compiled against the previous
   ncurses version mostly works when linked at runtime against the new
   library (via a bogus symlink), but with completely wrong colors
   (only tried an --enable-color-style binary).  Where it crashed
   is in parsing the
       setkey "^(cuu1)"        UPARROW
       setkey "^(up)"          UPARROW
   entries from a .lynx-keymaps file (no crash after commenting them out).

   What's happening:
   $ /usr/local/src/lynx2-8-1-cs/src/lynx
     .....
   A Fatal error has occurred in Lynx Ver. 2.8.1rel.2
     .....
   Lynx now exiting with signal:  11
   $ gdb /usr/local/src/lynx2-8-1-cs/src/lynx core
     .....
   (gdb) where
     .....
   #3  0x8063b28 in FatalProblem (sig=11) at ./LYMain.c:3235
   #4  <signal handler called>
   #5  0x400aa3d4 in strcpy ()
   #6  0x804bc58 in expand_tiname (first=0xbfffef2a "cuu1)\"", len=4, 
result=0xbfffcdac)
    at ./LYStrings.c:428

   apparently the lynx code here accesses internal ncurses structures
   directly which have changed (this may be sensitive to smaller library
   upgrades that are *not* reflected in changing the library's soname).
   Maybe it would be safer if lynx didn't do this...

4. Regarding the ^Z problems discussed a while ago:
   The obvious ones, which I was observing all the time with the previous
   libncurses 4.2, don't occur any more with the new version, but I
   haven't checked yet in detail.

 Klaus