[Vim-vms] RE: VIM on OpenVMS (fwd)

[Arpadffy Zoltan]

Hi Frank,

I am terribly sorry for late reply, but arpadffy at polarfox.com is my official
- heavily spammed e-mail address therefore I do not read/delete mail from
that account every day just about once a week.

I am really happy that HP takes care about Vim and hopefully other useful
tools.
You do have competence and time to work full time with these issues, unlike
we - the rest of the world - who are just in desperate need in Vi like
editor on OpenVMS.

I do support HP's GNV approach and I am aware that it will help achieve
higher OpenVMS popularity.
OpenVMS with its stability, scalability and security with Unix portability
is a winner combination in mission critical environments as Lottery,
Banking, Stock market etc.

Only problem is that GNV is a new application/environment that does not work
on old OpenVMS 5.3 and 6.2 etc.

Therefore, I would not suggest to use GNV related calls, includes in VIM
code, although I support idea that Vim should be included in GNV package as
an essential editor.
About legal issues you should contact Bram Moolenaar <Bram at moolenaar.net>

It is true that I take care about OpenVMS related Vim development since 1998
and I am guilty for most of the bug fixes, Unix compatibility, GTK build,
make files, tests and documentation on OpenVMS. I did it with all knowledge
that I have, but I am primarily a mathematician that works as a security
expert for Lottery environment.

So, as you might see, I am not the most competent person to take care about
VMS relate code, but unfortunately this is what Vim got on VMS platform...
During these years there were less then a dozen authors that were willing to
contribute.... and I did all these development just when I could not accept
some bug any more - as everybody else who contributed.
 
Therefore, all improvements are very welcome, but please keep in mind, that
Vim should be able to run on OpenVMS boxes without GNV environment as well. 

I am sure that Bram shares my opinion.

Even if GNV is a future (and in some extent, key for existence) of OpenVMS
operating system, there are many OpenVMS old-timers worldwide that are not
capable to run GNV or admins just simply refuse to use Unix like environment
on they loved VMS. (To be honest, I do use about 10 Unix like systems every
day, including Linux, xBSD, HP-UX, AIX, Solaris etc. I do like Unix and I
consider myself an Unix addict, but it must happen a miracle to force me
type cd .. in OpenVMS prompt)

Thank you very much for positive approach and keep up the good work.

Best regards, 
Z

---------- Forwarded message ----------
Date: Thu, 6 Nov 2003 15:34:56 -0500
From: "Ries, Frank" <frank.ries at hp.com>
To: arpadffy at polarfox.com
Subject: VIM on OpenVMS

Hi Zoltan,



My name is Frank Ries, and I work for Hewlett-Packard. HP has a set of
open source UNIX portability tools which are meant to help developer's
port UNIX applications to OpenVMS. I work with the team which develops
the GNV component of these tools. If you have not heard of GNV, or the
other open source tools available from HP, you can find information and
other links at http://gnv.sourceforge.net. We would like to include VIM
for OpenVMS as part of GNV, however, I have run into a problem with one
of the OpenVMS specific routines. Since you are listed as the maintainer
of this code, I wanted to communicate the problem to you, and offer you
a fix. I was not sure if I should direct this issue to you, or to Bram
Moolenaar. Please let me know if I should contact Bram directly on this.



The problem I ran into is with routine vms_read() in module os_vms.c.
The idea of this routine appears to be to wait for any input from the
terminal, and return as soon as any input is received. Currently, the
routine does a read with timeout, with a timeout value of 0. This will
return any data in the terminals type ahead buffer, else return
immediately if there is no data. If there was no data, the routine waits
for 0.05 seconds, and then tries the read again.



The problem is that occasionally, the routine will not fully read a
complete escape sequence when keys such as the arrow keys are typed.
When this happens, the escape sequence is split across two reads, and
VIM then does not interpret the sequence correctly, most of the time
resulting in the key being ignored. It also consumes considerable system
resources since it continuously polls for input. I have included with
this email the routine in question with an alternate method of doing the
input. The code I have provided will return immediately after any input
is entered, and will also return complete escape sequences. It does this
by specifying that all characters be treated as break characters. This
method does not require a timeout, and does not need to poll. Using this
code, VIM has no problem dealing with type ahead, or escape sequences.



I would appreciate any comments you might have on this change, and your
thoughts on accepting this as a modification to your code. If you find
this change appropriate, would you want to handle submitting this change
or would you prefer that I do that?



Thank you very much for any assistance you can give on this.



Frank Ries





/*

 * vms_read()

 * function for low level char input

 *

 * Returns: input length

 */

    int

vms_read(char *inbuf, size_t nbytes)

{

#ifdef __GNV

    int     status, function, len;

    TT_MODE tt_mode;

    ITEM    itmlst[2];

    static long trm_mask[8] = {-1, -1, -1, -1, -1, -1, -1, -1};



    /* whatever happened earlier we need an iochan here */

    if (!iochan)

       tt_mode = get_tty();



    vul_item(&itmlst[0], 0, TRM$_MODIFIERS,

     (char *)(TRM$M_TM_ESCAPE | TRM$M_TM_NOECHO | TRM$M_TM_NOEDIT |

                  TRM$M_TM_NOFILTR | TRM$M_TM_NORECALL |
TRM$M_TM_TRMNOECHO), 0);

    vul_item(&itmlst[1], sizeof(trm_mask), TRM$_TERM, (char *)&trm_mask,
0);



    function = (IO$_READLBLK | IO$M_EXTEND);

    memset(inbuf, 0, nbytes);



    while (1)

    {

            status = sys$qiow(0,iochan,function,&iosb,0,0,


inbuf,nbytes-1,0,0,&itmlst,sizeof(itmlst));

            len = strlen(inbuf);

            if (len > 0)

                break;

    }

    return len;

#else

    int     status, function, len;

    float   wait = 0.05;

    TT_MODE tt_mode;



    /* whatever happened earlier we need an iochan here */

    if (!iochan)

       tt_mode = get_tty();



    function = (IO$_READLBLK | IO$M_NOECHO | IO$M_TIMED | IO$M_ESCAPE);

    memset(inbuf, 0, nbytes);



    while (1)

    {

            status =
sys$qiow(0,iochan,function,&iosb,0,0,inbuf,nbytes-1,0,0,0,0);

            len = strlen(inbuf);

            if (len > 0)

                break;

            lib$wait(&wait);

    }

    return len;

#endif

}