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

[John Reagan]

On Tuesday, June 28, 2016 at 5:13:36 PM UTC-4, hb wrote:
> 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
> /
> $

I'll look into using that patch in the next week or so when Mike Z returns from vacation (he's the one who did our local build).