Post by John ReaganAbsolutely. 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
/
$