emacs-devel
[Top][All Lists]
Advanced

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

Re: emacsclient's option decoding code


From: Juanma Barranquero
Subject: Re: emacsclient's option decoding code
Date: Wed, 12 Nov 2008 10:33:29 +0100

On Wed, Nov 12, 2008 at 03:31, Stefan Monnier <address@hidden> wrote:

> I don't like using nil for "the w32 window system", indeed.  I think the
> "" we currently use is better.

It's not really important, but I don't understand why "" would be
better. At the "Basic Parameters" node, it is said:

  `display'
       The display on which to open this frame.  It should be a string of
       the form `"HOST:DPY.SCREEN"', just like the `DISPLAY' environment
       variable.

At no point in the docs is the value of DISPLAY assumed to be other
than "HOST:DPY.SCREEN", or else incorrect.

Also, nil is a more meaningful value to say that we don't have a
DISPLAY value (which is what's happening in this case, but could
change if we ever support X frames on Windows Emacs).

We're not talking about a frame parameter that does offer information
about the kind of display we're connecting to (not even `display-type'
does so, alas). `display' is purposefully modeled on DISPLAY. With
insight, it seems like there should perhaps be another frame parameter
that explicitly said whether the frame is X, tty, Windows or whatever.
Code could check that and not make unwarranted suppositions about
`display'.

> Can't we just make make-frame-on-display
> accept an argument "" to mean "the w32 window system"?

Yes, at the cost of adding Windows specific stuff, either the current

        ((eq system-type 'windows-nt)
         ;; On Windows, ignore DISPLAY.
         (make-frame parameters))

which I deeply dislike because it accepts *everything*, or the still more ugly

        ((and (eq system-type 'windows-nt) (string= display ""))
         ;; On Windows, ignore DISPLAY == ""
         (make-frame parameters))

And that's just in make-frame-on-display. If we're going to treat ""
as a "display" on Windows, perhaps other code would have to be
"generalized" that way. With my proposal, it becomes

        ((null display)
         (make-frame parameters))

and the generalization of nil meaning "the current display" for all
environments, not just Windows, seems more fitting.

  Juanma




reply via email to

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