[Top][All Lists]
[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 17:37:53 +0100 |
On Wed, Nov 12, 2008 at 16:56, Stefan Monnier <address@hidden> wrote:
> You might be right. I tend to think of `display' as something similar
> to `terminal', but they're not the same. To tell you the truth, I'm not
> sure what `display' is meant for exactly.
Same here. I find weird (though perhaps understandable) that Emacs has
a clear separation between tty and graphics frames, but not such
between X and w32 (and ns, etc.) frames. By that I mean that there is
code which calls x-functions when compiled on GNU/Linux, and their
w32-* counterparts when compiled on Windows. That will be a problem if
someday we have a multi-GUI Emacs.
> E.g., let's imagine a w32 version of Emacs which has been hacked to be
> able to use X11 as well. And let's additionally say that it can even
> also use GNUstep, so it can have w32, x11, and ns frames, all displayed
> on the same screen. Both ns and x11 frames will have a `display' set to
> the same value (typically ":0.0" or something along these lines),
> whereas the w32 frames's display will be "" (or nil, or ...).
> This discrepency doesn't seem good.
>
> So maybe we should just make w32 use display=":0.0".
Fine by me. Someday, if multi-GUI materializes, we'll have to add a
frame parameter or another way for lisp code to query the GUI
associated with a given frame.
> The current display should be obtained via (frame-parameter nil 'display).
Yes. My doubt was whether "current display" makes as much sense for
Windows frames as it does for X ones.
But I don't want to insist; I'd be happy just by fixing some of the
issues, one way or another.
So, please answer these:
- Should the "-c + no DISPLAY" => "-t" implication of emacsclient be
removed only for Windows (because it does in fact make sense on
POSIX), or be removed for good (Eli's view, I think)?
- Do I change term/w32-win.el to use ":0.0" as argument to `x-open-connection'?
- If yes, do we leave `make-frame-on-display' as it stands now, i.e.
accepting any DISPLAY string as valid when called from Windows, or do
we change it to accept just ":0.0" for the time being? (I favor the
second, which is simpler and cleaner: it's just removing the recent
three-line patch by Chong.)
- Do we want `make-frame-on-display' to accept a null DISPLAY (on
every platform) to mean "create a frame on the current display"?
Juanma
- Re: emacsclient's option decoding code, (continued)
- Re: emacsclient's option decoding code, Eli Zaretskii, 2008/11/11
- Re: emacsclient's option decoding code, Juanma Barranquero, 2008/11/12
- Re: emacsclient's option decoding code, Eli Zaretskii, 2008/11/12
- Re: emacsclient's option decoding code, Juanma Barranquero, 2008/11/12
- Re: emacsclient's option decoding code, Eli Zaretskii, 2008/11/12
- Re: emacsclient's option decoding code, Juanma Barranquero, 2008/11/13
- Re: emacsclient's option decoding code, Eli Zaretskii, 2008/11/12
- Re: emacsclient's option decoding code, Stefan Monnier, 2008/11/11
- Re: emacsclient's option decoding code, Juanma Barranquero, 2008/11/12
- Re: emacsclient's option decoding code, Stefan Monnier, 2008/11/12
- Re: emacsclient's option decoding code,
Juanma Barranquero <=
- Re: emacsclient's option decoding code, Stefan Monnier, 2008/11/12
- Re: emacsclient's option decoding code, Lennart Borgman, 2008/11/12
- Re: emacsclient's option decoding code, Eli Zaretskii, 2008/11/12
- Re: emacsclient's option decoding code, Juanma Barranquero, 2008/11/13
- Re: emacsclient's option decoding code, Dan Nicolaescu, 2008/11/13
- Re: emacsclient's option decoding code, Juanma Barranquero, 2008/11/13
- Re: emacsclient's option decoding code, Juanma Barranquero, 2008/11/13
- Re: emacsclient's option decoding code, Dan Nicolaescu, 2008/11/13
- Re: emacsclient's option decoding code, Eli Zaretskii, 2008/11/12
- Re: emacsclient's option decoding code, Stefan Monnier, 2008/11/12