Re: w32 does not have emacsclient/server - getting paper size

[Lennart Borgman]

David Kastrup wrote:

> > Ghostscript is not installed that way on w32. It is not supposed to
> > be find in the PATH. That is because the w32 "architecture" is
> > different. You can only find Ghostscript through the registry (or
> > searching the whole disk ;-)
> >    
>
> Does not sound too intelligent.
>  
I believe that this was my first thought long ago too, but I am actually 
not sure it is not an intelligent solution. You have to have more of the 
picture to decide that I believe.

> > That would be very nice. The problem is however that until this is
> > done Emacs is kind of a second class citizen that do not have access
> > to things all other w32 programs has.  And that makes for a bad
> > impression.
> >    
>
> So unless the registry access is required for implementing some
> cross-platform functionality, there is no motivation to add it into
> Emacs because that would only encourage unportable applications.
>
> The right way to go about this is first to create an API that is
> useful across operating systems.  Then this API can be filled with
> life.  It would appear that on Posix system, this would entail a
> read-only interface into setlocale(3), and maybe on w32 reading
> registry keys.  Whether those interfaces should be exposed to Lisp, is
> a different question.  It would make sense to define this stuff with
> the Posix semantics, and then let w32-specific code translate this
> into the respective registry reading calls.
>  
Yes, I agree.  On w32 I think at least new users would expect this to 
work. If we want them to switch to GNU/Linux then I believe we should 
anticipate that they will expect this on GNU/Linux too. If you think 
this is the right way to go then I would be glad if you (or someone 
else) did this for Posix systems. Then I (or someone else) will 
implement this on w32 because at least I feel it is the right way to go.

> What capability?  Reading the registry?  Don't be silly.  Querying the
> paper size?  Well, I don't see why that omission should be less of a
> problem on a Unix-like operating system.
Fine, then we could perhaps have a common goal in this small but not 
unimportant detail. It is not unimportant since it is part of a bigger 
picture concerning the integration with the OS that new users probably 
do expect.