Re: printing.el v6.6.3

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> Date: Sat, 8 Dec 2001 06:17:58 -0700 (MST)
> 
> pr-dosify-path actually operates on file names.  But I think the job
> it does is no longer considered desirable; it should probably be
> eliminated, not renamed.  The same for pr-unixify-path.  Eli,
> what do you think?

pr-dosify-path is certainly not required for file names passed to
Emacs primitives.  But it might be required if the resultant file
name is passed to an external program: if that program doesn't grok
Unix-style forward slashes, it will choke.  (DOS and Windows system
calls do support forward slashes, but if an application parses its
command line, it could reject Unix-style file names if the programmer
didn't make allowances for forward slashes.)

It is hard for me to see what exactly are the results of
pr-dosify-path used for, but I'm certain Vinicius will know ;-)

> However, I have to question the usefulness of the whole pr-path-alist
> feature.  Many Emacs packages find commands to run.  Normally they
> find these commands either through $PATH or through variables that
> specify the command name (which can be a file name) to do a certain
> job.
> 
> It seems to me that there is no particular reason to add this new
> mechanism for printing commands alone.

I agree.  I'm guessing that this feature was motivated by the fact
that there are no standard directories on Windows systems where you
could expect programs like Ghostscript to be installed.  But it
should be enough to let users specify a full file name to their
Ghostscript executable via defcustom.

> If we do add a hairy method for finding commands, we should add it for
> all of Emacs, and integrate it with Custom.

We could simply add a feature that adds directories to exec-path, or
something like that.