emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Kastrup
Subject: Re: w32 does not have emacsclient/server - getting paper size
Date: Sat, 16 Jul 2005 00:33:52 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Lennart Borgman <address@hidden> writes:

> David Kastrup wrote:
>
>>I don't see that Emacs has an interface into the locale in general
>>which would be required for reading the papersize setting.  And the
>>usual way for GhostScript is just to look for "gs" in the exec path.
>>Since the process shell does that already, "gs" is usually used as
>>the default command.  There is no separate database to search for
>>such information.  That's what PATH is for.
>>  
>>
> 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.

>>So if one built a general interface into stuff like the paper size,
>>and then filled it with life also on the free systems, doing the
>>same on w32 would not violate any policies.
>>
> 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.

Not half as bad as Emacs catering for w32 better than for free
systems.  We don't want people to get started on Emacs on w32 to find
themselves in the situation that they don't want to switch operating
systems because then Emacs will fail to work.

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.

If you find that you are missing something like paper size, then this
shortcoming is not a w32-specific one, and "solving" this by providing
registry access is a w32-only solution.  No thanks.

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.

That way, the functionality is accessible, and people don't get hooked
on Windows _because_ of Emacs.

> Am I right in assuming that the lack of this capability on for
> example GNU/Linux does not give such an impression?

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]