Aaron Sloman See text for reply address wrote:
Hi Aaron,
I'm mailing you directly rather than posting because I want to be sure I
don't have the wrong end of the stick.
> This made it fairly easy to define a procedure to read a file whose
> name has spaces into a Ved buffer, without altering any VED system
> files.
Your procedure is going to be immediately useful to people who are
suffering from the problem of spaces in names, but wouldn't it be good
to also fix the problem at source, i.e., in the system files?
Of course there are going to be people, e.g., students, who aren't in a
position to install a new system for themselves and will want to use
your procedure in the meantime, but in the long run, a separate
procedure for reading in files with spaces in their names would be an
extra piece of obscure lore for the new user to trip over.
From the (lack of) reaction to your original post, I would guess that
there are few if any people who make use of the multi file facility, so
it would probably be ok to make the possibility of spaces in names be
the default, and have a settable variable to give you the old behavior
(with a warning in the documentation that it is likely to be phased
out).
The only remark I have about your procedure is that it seems to prevent
the user from opening a new file with a space in the name. (I haven't
actually tried your code, just read it.)
;;; Check that the file exists
lvars filedev = readable(vedargument);
unless filedev then
vederror('FILE NOT FOUND: ' <> vedargument);
endunless;
With an ordinary space-free filename, if the file doesn't exist I get a
"new file" message on the command line, rather than an error message.
In the windows code that Robert Duncan wrote, it also seems to be
impossible to open a new file with spaces in the name from the command
line. Is there some deeper problem that makes this necessary?
Regards,
Steve
|