[Info-vax] Emacs 21.2, was Re: PC/VT Keyboarrd Mapping

[hb]

On 06/25/2016 10:02 PM, John Reagan wrote:
> Absolutely.  I use a standard PC keyboard and use the keypad with
> LSE, DTM, and Notes.  It all works just fine.  I have an LSE init
> file that makes F9-F12 into the "DO" key.  I tend to use Emacs all
> the time, but Emacs seems to have issues when I have SET
> PROC/PARSE=EXTENDED enabled.  It also has issues with using angle
> braces instead of square braces in filespecs.  Those are the times
> I'll just hop into LSE.

It looks like the angel bracket problem shows/showed with concealed
rooted logical names and the current default directory, when the latter
is specified with square brackets - and vice versa.

What seems to work without any problem:
 Process set to extended parsing
 Current directory on an ODS-5 disk: [] style
 Copy of the emacs dump file saved as Emacs-21_2.Dump;1 in the current
   directory
 File names in lowercase

For example
 $ mcr bld_root:[local.bin]emacs-21_2 -map <>emacs-21_2.dump
sys$disk:<>lowercase.txt

What didn't work was editing a file specified like
  <>lowercase.txt
or
  root:<whatever>lowercase.txt
with root defined /translation=(concealed,terminal)

No surprise, using square brackets in both error cases worked as expected.

I changed the code and fixed "something" (FILEIO.C) and I hope I didn't
break something else. The changes are independent of the platforms
VAX/Alpha/I64. Diffs/patches are appended. Whether the change can/needs
to be applied to 19.28 (which I assume is the other version), I don't know.

Emacs was build and runs on Alpha V8.3, with a "recent" CRTL as well as
recent include files and HP C V7.3-010.

To build in this environment (and likely on recent I64 versions) you
need to make the call to access() consistent, either always use (the
#defined) sys_access() and maybe prefix that with __LONG_GID_ or use
access() from decc$shr. I dared to do the first one (OK, looks like a
hack, because including unistd.h in VMSFNS.C creates more compile time
errors/warnings than I wanted to handle). Otherwise my friend the LINKER
will complain about an undefined symbol SYS_ACCESS in VMSFNS.OBJ - and
the LINKER is always right :-)

On not so recent versions, especially of unistd.h, there is no such
build problem - and sys_access, more or less a CRTL-workaround-code, is
used.

When using access() from DECC$SHR, I experienced write access problems
for files which were not write protected. I didn't spend the time to
investigate. And no, I don't see any DECC$ feature logicals being defined.

PATCHES:

$ diff/slp [-.emacs212_3.src]fileio.c;-1 ;
$ diff/slp [-.emacs212_3.src]vmsfns.c;-1 ;
$ ty *.dif

BLD_ROOT:[EMACS.BUILD]FILEIO.DIF;1

- 1064
  int fbrack = 0;
- 1232
              fbrack = 0;
- 1258, 1263
            {
              lbrack++, brack = 0;
              if (fbrack==0)
                fbrack = p[0];
              else
                p[0] = fbrack;
            }
          /* count close brackets, set close bracket pointer */
          if (p[0] == ']' || p[0] == '>')
            {
              rbrack++, brack = p;
              p[0] = fbrack + 2;
            }
          /* detect ][ or >< */
          if ((p[0] == ']' && p[1] == '[') || (p[0] == '>' && p[1] == '<'))
- 1303
                  p = tmp+(colon-nm)+8;
/

BLD_ROOT:[EMACS.BUILD]VMSFNS.DIF;1

-   27
#if __USE_LONG_GID_T
#   pragma __extern_prefix __save
#   pragma __extern_prefix "__long_gid_"
#endif

int  access    (const char *__file_spec, int __mode);

#if __USE_LONG_GID_T
#   pragma __extern_prefix __restore
#endif
/
$