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

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

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.