Re: New version of multiscreen patch

[Pavel Roskin <proski gnu org>]

Hi, Miguel!

I appreciate that you are reading this list!

> > > Ctrl-Alt-Insert: Add bookmark
> > > Ctrl-Alt-Up: Move to previous bookmark
> > > Ctrl-Alt-Down: Move to next bookmark
> >
> > Supporting this in xterm may be problematic, unless mc is linked with
> > libX11.  Perhaps linking with libX11 should become the default at some
> > point.
>
> This is a terrible idea, lets not link with X11 for a text-mode
> application.  Not to mention that it will also be incorrect for some
> cases.

It's not near as bad as it sounds.  I just didn't want to go into small
details of the implementation - my point just was that it can be done.

Let me explain in details what kind of implementation I meant.  (Note that
I have no definite plans to implement it - my first priority is to keep up
with the list, check patches and apply those of them that look good.)

libX11 will only be used by default if dynamic loading of libraries is
supported.  Strictly speaking, it's not linking.  But it should still be
possible to enable libX11 support through linking or to disable it
completely.

An attempt to load libX11 will only be made if WINDOWID and DISPLAY are
defined in the environment.  Other sanity checks may be added if needed.

MC will get the status of modifiers (Shift, Ctrl etc) from X for every
keystroke.  This status will be used in the internal representation of all
keys.  I'm not going to actually read keystrokes from X, at least in the
initial implementation.

The benefits of recording modifiers for every key:

1) Even when the output of Fn and Shift-Fn is the same (e.g. kterm 6.2.0),
mc will be able to distinguish them.

2) MC will be able to distinguish F11 and Shift-F1.

3) Double Escape with pressed Alt won't be interpreted as an Escape.

Ctrl-Alt-Insert generates \e\e[2^ on rxvt.  Normally, \e\e would match a
sequence in the MC key table and would be interpreted as Escape.  However,
we can specify in the sequence definition that it's not just \e on input
- we can require it to be \e without modifiers.

-- 
Regards,
Pavel Roskin