Re: emacsclient's option decoding code

[Juanma Barranquero]

On Tue, Nov 11, 2008 at 05:09, Eli Zaretskii <address@hidden> wrote:

>>  - emacsclient -c causes the same error, because emacsclient thinks
>> that "-c" + null DISPLAY => "-t"; I proposed the attached patch (1),
>> because even if -t is supported on Windows, the assumption that an
>> empty DISPLAY implies a tty frame is false.
>
> Then why is the patch Windows-specific?  If the above assumption is
> false, it shouldn't be made on Posix platforms as well.
>
> Can someone explain why this assumption is in the code?

Chong has already explained the assumption. And IMO that assumption is
correct for POSIX, but will never (for some values of "never", of
course) be for the Windows port, because even if we someday support X,
Windows and tty frames simultaneously in the same running Emacs
instance, it is a long shot to assume that any specific user will be
using X or have DISPLAY defined in their environment. On POSIX, having
DISPLAY defined is the norm; on Windows it will always be the
exception, unless things change drastically. -c for a Windows user is
much more likely to mean "another frame on my display" than "another
frame on some remote X display", and if it really is the latter, well,
then the probability of the user having DISPLAY set is much higher in
the first place. (Note, BTW, that emacsclient's help for -c talks just
about "a new frame", with no mention of DISPLAY.)

> What happens if emacsclient is invoked with --display=DISPLAY argument
> on Windows, after your patch?

-d/--display is not currently accepted on Windows. Once activated, and
without X display support:

- As it stands now, with Chong's patch, if would make a frame on the
current display.
- With my patch, it would throw the "Invalid display, no HOST:SERVER
or HOST:SERVER.SCREEN" error.

I think the behavior I propose is more consistent. Also, if we someday
implement X support on the Windows port, my patch would naturally
work, while the current one would have to be fixed.

IMHO the desire to fix the -c/-t problem on Windows has muddled the
waters a bit. As I said in a previous message, if we want
`make-frame-on-display' to allow `nil' to default to the current
frame, that seems sensible. But making an exception for Windows and
allowing "", or in fact any other value, string or otherwise, is ugly
and just a consequence of the fact that (frame-parameter nil 'display)
returns "" on Windows. The right thing to do IMHO is fix the places
where the Windows port calls make-frame-on-display, and make sure that
it passes nil when it really means "I don't have a DISPLAY".

> Please add an entry to NEWS, so we won't forget that.

I'll do as soon as we settle on a fix.

Thanks,

  Juanma