(featurep 'multi-tty) => t on Windows

(featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

From etc/NEWS:

  *** Emacs now supports using both X displays and ttys in one session.
  With an Emacs server active (M-x server-start), `emacsclient -t'
  creates a tty frame connected to the running emacs server.  You can
  use any number of different ttys.  `emacsclient -c' creates a new X11
  frame on the current $DISPLAY (or a tty frame if $DISPLAY is not set).

  You can test for the presence of this feature in your Lisp code by
  testing for the `multi-tty' feature.

Currently, (featurep 'multi-tty) returns t in the Windows (NT_GUI)
port. Should it?

  Juanma

Re: (featurep 'multi-tty) => t on Windows

[dhruva]

Hi,

On Wed, Dec 3, 2008 at 6:24 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>  You can test for the presence of this feature in your Lisp code by
>  testing for the `multi-tty' feature.
>
> Currently, (featurep 'multi-tty) returns t in the Windows (NT_GUI)
> port. Should it?

IMO, it should not, it is confusing.

-dhruva

-- 
Contents reflect my personal views only!

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Wed, Dec 3, 2008 at 13:54, Juanma Barranquero <lekktu@gmail.com> wrote:

> Currently, (featurep 'multi-tty) returns t in the Windows (NT_GUI)
> port. Should it?

ping...

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>> Currently, (featurep 'multi-tty) returns t in the Windows (NT_GUI)
>> port. Should it?

Could you check whether anything in the Emacs sources tests for the
multi-tty feature?

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Wed, Dec 10, 2008 at 15:00, Chong Yidong <cyd@stupidchicken.com> wrote:

> Could you check whether anything in the Emacs sources tests for the
> multi-tty feature?

Just once:

`erc-cmd-SV' (from erc/erc.el) uses it, but just to build a string to
display the current Emacs version:

   (if (featurep 'multi-tty) ", multi-tty" ""))


  Juanma

Re: (featurep 'multi-tty) => t on Windows

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>> Could you check whether anything in the Emacs sources tests for the
>> multi-tty feature?
>
> Just once:
>
> `erc-cmd-SV' (from erc/erc.el) uses it, but just to build a string to
> display the current Emacs version:
>
>    (if (featurep 'multi-tty) ", multi-tty" ""))

I think this feature should be nil on Windows.  Go ahead and make the
change.

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Wed, Dec 10, 2008 at 17:16, Chong Yidong <cyd@stupidchicken.com> wrote:

>>    (if (featurep 'multi-tty) ", multi-tty" ""))
>
> I think this feature should be nil on Windows.  Go ahead and make the
> change.

I hadn't thought of any specific change. We can wrap the Fprovide into #ifdefs

#ifndef WINDOWSNT
  Fprovide (intern ("multi-tty"), Qnil);
#endif

if nobody thinks of a better way.

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Chetan Pandya]

Wouldn't it make more sense for it to be DOS_NT?
In general, I like the idea of feature based defines to deal with any changes here.

Chetan

--- On Thu, 12/11/08, Juanma Barranquero <lekktu@gmail.com> wrote:

> From: Juanma Barranquero <lekktu@gmail.com>
> Subject: Re: (featurep 'multi-tty) => t on Windows
> To: "Chong Yidong" <cyd@stupidchicken.com>
> Cc: "Emacs Devel" <emacs-devel@gnu.org>
> Date: Thursday, December 11, 2008, 9:47 AM
> On Wed, Dec 10, 2008 at 17:16, Chong Yidong
> <cyd@stupidchicken.com> wrote:
> 
> >>    (if (featurep 'multi-tty) ",
> multi-tty" ""))
> >
> > I think this feature should be nil on Windows.  Go
> ahead and make the
> > change.
> 
> I hadn't thought of any specific change. We can wrap
> the Fprovide into #ifdefs
> 
> #ifndef WINDOWSNT
>   Fprovide (intern ("multi-tty"), Qnil);
> #endif
> 
> if nobody thinks of a better way.
> 
>     Juanma

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> Date: Thu, 11 Dec 2008 09:35:19 -0800 (PST)
> From: Chetan Pandya <pandyacus@sbcglobal.net>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> Reply-To: pandyacus@sbcglobal.net
> 
> Wouldn't it make more sense for it to be DOS_NT?

Not unless you show me a use case where multi-tty features don't work
in the MS-DOS port of Emacs.  I have yet to see any Lisp code that
wouldn't DTRT in the DOS port because of this.

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Fri, Dec 12, 2008 at 00:24, Eli Zaretskii <eliz@gnu.org> wrote:

> Not unless you show me a use case where multi-tty features don't work
> in the MS-DOS port of Emacs.  I have yet to see any Lisp code that
> wouldn't DTRT in the DOS port because of this.

There's currently no Lisp code that does the wrong thing on the
Windows port either, if not for other reason that the multi-tty port
is quite new.

The point is, IMHO, that (featurep 'multi-tty) will allow the code to
have some expectations, like the possibility of having simultaneous
tty and GUI frames, that currently the Windows port can not satisfy.
If the Windows port defines the multi-tty feature, it just dilutes its
meaning. Is that not true for the DOS port?

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> Date: Fri, 12 Dec 2008 00:39:10 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: pandyacus@sbcglobal.net, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> The point is, IMHO, that (featurep 'multi-tty) will allow the code to
> have some expectations, like the possibility of having simultaneous
> tty and GUI frames

Code that assumes such a possibility without testing for (featurep 'x)
(or something similar for Windows) is buggy and should be fixed.  One
can build Emacs --without-x, in which case it cannot have both tty and
GUI frames.  But such an Emacs is still multi-tty, since it can have
multiple tty frames.

> that currently the Windows port can not satisfy.

I think the situation on Windows is worse: there are some multi-tty
primitives that simply crash or cause Emacs to throw a signal.  I
think you discovered that while testing the latest changes in
emacsclient.  Or does my faulty memory fail me again?

> If the Windows port defines the multi-tty feature, it just dilutes its
> meaning. Is that not true for the DOS port?

The DOS port supports only one kind of frame, so several different
kinds are not an issue (again, assuming Lisp code without bugs
mentioned above).

When I worked on reviving the DOS port, I actively tried to break it
by using multi-tty primitives, but any use-case that can be reproduced
on DOS either worked or silently did nothing.  That is why I didn't
bother to revoke the multi-tty feature in the DOS port.  If someone
shows me a use-case that contradicts that, I will think again.

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Fri, Dec 12, 2008 at 13:01, Eli Zaretskii <eliz@gnu.org> wrote:

> Code that assumes such a possibility without testing for (featurep 'x)
> (or something similar for Windows) is buggy and should be fixed.  One
> can build Emacs --without-x, in which case it cannot have both tty and
> GUI frames.  But such an Emacs is still multi-tty, since it can have
> multiple tty frames.

Perhaps the multi-tty feature should have subfeatures, like
`make-network-process'; they would be computed at runtime, and would
say whether the running instance supports multiple ttys, mixed tty/GUI
frames, etc.

> I think the situation on Windows is worse: there are some multi-tty
> primitives that simply crash or cause Emacs to throw a signal.  I
> think you discovered that while testing the latest changes in
> emacsclient.  Or does my faulty memory fail me again?

Your memory is sound: "Bug#1325: make-terminal-frame causes assertion
failure on Windows"

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1325

> When I worked on reviving the DOS port, I actively tried to break it
> by using multi-tty primitives, but any use-case that can be reproduced
> on DOS either worked or silently did nothing.  That is why I didn't
> bother to revoke the multi-tty feature in the DOS port.

Understood.

Thanks,

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> Date: Fri, 12 Dec 2008 13:14:41 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: pandyacus@sbcglobal.net, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> Perhaps the multi-tty feature should have subfeatures, like
> `make-network-process'; they would be computed at runtime, and would
> say whether the running instance supports multiple ttys, mixed tty/GUI
> frames, etc.

Actually, I'd dare to submit that I cannot see any reason at all for
providing `multi-tty' as a Lisp feature.  At the time, I asked several
related questions here, and my conclusion from the responses was that
almost all (if not plainly all) features added by multi-tty are (or
are supposed to be) invoked through emacsclient.  Since emacsclient
cannot test Emacs features, providing `multi-tty' seems useless.  The
fact that no code tests for it reaffirms that conclusion.

Perhaps I'm missing something, but I'd love to know what that is.

If I _am_ right, we should simply stop providing `multi-tty', while it
is still not too late.

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Fri, Dec 12, 2008 at 13:54, Eli Zaretskii <eliz@gnu.org> wrote:

> Actually, I'd dare to submit that I cannot see any reason at all for
> providing `multi-tty' as a Lisp feature.  At the time, I asked several
> related questions here, and my conclusion from the responses was that
> almost all (if not plainly all) features added by multi-tty are (or
> are supposed to be) invoked through emacsclient.

It is apparently so, yes.

> Since emacsclient
> cannot test Emacs features

Not sure I understand what you mean:

 C:\> emacsclient --eval "(featurep 'multi-tty)"
 t

> If I _am_ right, we should simply stop providing `multi-tty', while it
> is still not too late.

Perhaps; I'm not opposed to removing it. But I think that, if some
package author finds a use for it in the future, it will be cleaner to
check (featurep 'multi-tty) than (f?boundp whatever).

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> Date: Fri, 12 Dec 2008 17:23:13 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: pandyacus@sbcglobal.net, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> > Since emacsclient
> > cannot test Emacs features
> 
> Not sure I understand what you mean:
> 
>  C:\> emacsclient --eval "(featurep 'multi-tty)"
>  t

That's Emacs who evaluated the expression, not emacsclient, and doing
something with that in normal emacsclient usage is impossible.  What I
meant is that you users cannot tweak emacsclient to do something like
"if this Emacs supports feature XYZ use option -N, otherwise use
option -M" (although one could write a shell script to do that).
emacsclient doesn't have an extension language that could make use of
that paradigm.

> > If I _am_ right, we should simply stop providing `multi-tty', while it
> > is still not too late.
> 
> Perhaps; I'm not opposed to removing it. But I think that, if some
> package author finds a use for it in the future, it will be cleaner to
> check (featurep 'multi-tty) than (f?boundp whatever).

Only if we don't already have other features that could be checked
instead.

And btw, I don't think Emacs practice agrees with you in general: we
have quite a few features that cannot be tested with featurep, because
no code `provide'd them.  Just grep the Lisp sources for fboundp.

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Sat, Dec 13, 2008 at 00:27, Eli Zaretskii <eliz@gnu.org> wrote:

> That's Emacs who evaluated the expression, not emacsclient, and doing
> something with that in normal emacsclient usage is impossible.  What I
> meant is that you users cannot tweak emacsclient to do something like
> "if this Emacs supports feature XYZ use option -N, otherwise use
> option -M" (although one could write a shell script to do that).
> emacsclient doesn't have an extension language that could make use of
> that paradigm.

I suppose a limited form of that wouldn't be too hard to implement, if
necessary.

> And btw, I don't think Emacs practice agrees with you in general: we
> have quite a few features that cannot be tested with featurep, because
> no code `provide'd them.  Just grep the Lisp sources for fboundp.

I know. But there's a difference between

   (if (fboundp 'whatever)
       (whatever ...))

and

  (if (fboundp 'whatever)
      (something-else...))

Checking for a function before using it is clean. Checking for a
function or a variable, as a way to know whether some "pack" of new
features are installed, is not. Now, I'm not proposing to start adding
features or subfeatures for the old code, of course. But it is at
least something to consider when adding big chunks of new
functionality.

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> Date: Sat, 13 Dec 2008 00:50:34 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: pandyacus@sbcglobal.net, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> I know. But there's a difference between
> 
>    (if (fboundp 'whatever)
>        (whatever ...))
> 
> and
> 
>   (if (fboundp 'whatever)
>       (something-else...))
> 
> Checking for a function before using it is clean. Checking for a
> function or a variable, as a way to know whether some "pack" of new
> features are installed, is not.

And how exactly is

    (if (featurep 'foo)
    	(something))

cleaner than the latter?

Re: (featurep 'multi-tty) => t on Windows

[mail]

Eli Zaretskii <eliz@gnu.org> writes:
>
> And how exactly is
>
>     (if (featurep 'foo)
>     	(something))
>
> cleaner than the latter?

It's clearer in intention, if nothing else. If I understand correctly,
Juanma considers checking for the existence of a feature to be a cleaner
way of writing feature specific code than checking for some function
that may be an indication that such a feature might exist. The two
approaches are equal in lines of code, but checking for a function so
that ou may execute code that has nothing to do with that function is
uglier (though equivalently effective).

-- 
Just because you're paranoid doesn't mean they AREN'T after you.

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> From: mail@justinbogner.com
> Date: Fri, 12 Dec 2008 23:03:51 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >
> > And how exactly is
> >
> >     (if (featurep 'foo)
> >     	(something))
> >
> > cleaner than the latter?
> 
> It's clearer in intention, if nothing else.

Unless "something" includes "foo" as a substring, I don't see how it
is clearer.

> If I understand correctly,
> Juanma considers checking for the existence of a feature to be a cleaner
> way of writing feature specific code than checking for some function
> that may be an indication that such a feature might exist. The two
> approaches are equal in lines of code, but checking for a function so
> that ou may execute code that has nothing to do with that function is
> uglier (though equivalently effective).

Yes, that's what Juanma says, I just am not sure I agree.

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Sat, Dec 13, 2008 at 11:24, Eli Zaretskii <eliz@gnu.org> wrote:

> Unless "something" includes "foo" as a substring, I don't see how it
> is clearer.

In this particular example, I see

  (if (featurep 'multi-tty)
     (something...)

as cleaner, if `something' is code that depends on the multi-tty
support, even if `something' does not include multi-tty in the name.

(It is a different question whether `multi-tty', specificially, should
be a feature or not.)

> Yes, that's what Juanma says, I just am not sure I agree.

It's OK. I'd bet most developers agree with you, anyway. :-)

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Stefan Monnier]

> It's OK. I'd bet most developers agree with you, anyway. :-)

I wouldn't bet on it, but I think a large proportion couldn't care less.
I.e. this discussion is a waste of time,


        Stefan

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Sat, Dec 13, 2008 at 17:13, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I wouldn't bet on it, but I think a large proportion couldn't care less.
> I.e. this discussion is a waste of time,

Exploring the space of developers' preferences is not a waste of time IMO. YMMV.

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Stefan Monnier]

>> I wouldn't bet on it, but I think a large proportion couldn't care less.
>> I.e. this discussion is a waste of time,
> Exploring the space of developers' preferences is not a waste of time
> IMO. YMMV.

We're talking about preferenced for a bikeshed's color.


        Stefan

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Sun, Dec 14, 2008 at 03:42, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> We're talking about preferenced for a bikeshed's color.

No, using features vs. f?boundp is not a bikeshed's color for me.

But it's OK, there's no point in arguing right now.

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Richard M Stallman]

    > That's Emacs who evaluated the expression, not emacsclient, and doing
    > something with that in normal emacsclient usage is impossible.  What I
    > meant is that you users cannot tweak emacsclient to do something like
    > "if this Emacs supports feature XYZ use option -N, otherwise use
    > option -M" (although one could write a shell script to do that).
    > emacsclient doesn't have an extension language that could make use of
    > that paradigm.

    I suppose a limited form of that wouldn't be too hard to implement, if
    necessary.

I don't think we should go in that direction.  If the user wants to
program how to handle an emacsclient request in various circumstances,
it is much cleaner to write the program in Lisp, rather  than in
arguments to a shell command.

I think that is more appropriate anyway, because the preference for
what to do is more likely to vary from user to user than from caller
to caller.

Is there some reason why this CANNOT be done in Emacs?

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Sat, Dec 13, 2008 at 12:40, Richard M Stallman <rms@gnu.org> wrote:

> If the user wants to
> program how to handle an emacsclient request in various circumstances,
> it is much cleaner to write the program in Lisp, rather  than in
> arguments to a shell command.

That's what we do.

> Is there some reason why this CANNOT be done in Emacs?

No.

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Chetan Pandya]

--- On Thu, 12/11/08, Eli Zaretskii <eliz@gnu.org> wrote:

> From: Eli Zaretskii <eliz@gnu.org>
>
> > Wouldn't it make more sense for it to be DOS_NT?
> 
> Not unless you show me a use case where multi-tty features
> don't work
> in the MS-DOS port of Emacs.  I have yet to see any Lisp
> code that
> wouldn't DTRT in the DOS port because of this.

I can show where it does not work if you can show me that DOS port can be built from the sources as they exist.

The etc/MACHINES file does list DOS as one of the supported platforms.

Chetan

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> Date: Thu, 11 Dec 2008 20:38:58 -0800 (PST)
> From: Chetan Pandya <pandyacus@sbcglobal.net>
> Reply-To: pandyacus@sbcglobal.net
> Cc: lekktu@gmail.com, cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> > From: Eli Zaretskii <eliz@gnu.org>
> >
> > > Wouldn't it make more sense for it to be DOS_NT?
> > 
> > Not unless you show me a use case where multi-tty features
> > don't work
> > in the MS-DOS port of Emacs.  I have yet to see any Lisp
> > code that
> > wouldn't DTRT in the DOS port because of this.
> 
> I can show where it does not work if you can show me that DOS port can be built from the sources as they exist.

Yes, it can; see msdos/INSTALL.

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> Date: Thu, 11 Dec 2008 10:47:29 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> On Wed, Dec 10, 2008 at 17:16, Chong Yidong <cyd@stupidchicken.com> wrote:
> 
> >>    (if (featurep 'multi-tty) ", multi-tty" ""))
> >
> > I think this feature should be nil on Windows.  Go ahead and make the
> > change.
> 
> I hadn't thought of any specific change. We can wrap the Fprovide into #ifdefs
> 
> #ifndef WINDOWSNT
>   Fprovide (intern ("multi-tty"), Qnil);
> #endif
> 
> if nobody thinks of a better way.

Can't we test something, instead of a preprocessor define that states
an OS?  I'd rather not proliferate abuse of preprocessor for this.

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Fri, Dec 12, 2008 at 00:17, Eli Zaretskii <eliz@gnu.org> wrote:

> Can't we test something, instead of a preprocessor define that states
> an OS?  I'd rather not proliferate abuse of preprocessor for this.

I'd rather not, too. That's why I haven't committed anything.

    Juanma

Re: (featurep 'multi-tty) => t on Windows

[Eli Zaretskii]

> Date: Fri, 12 Dec 2008 00:35:33 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
> 
> On Fri, Dec 12, 2008 at 00:17, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Can't we test something, instead of a preprocessor define that states
> > an OS?  I'd rather not proliferate abuse of preprocessor for this.
> 
> I'd rather not, too. That's why I haven't committed anything.

Well, boundp and fboundp can be called from C as well, so if you can
find something that we could test for bound-ness, that will do the
trick.

(I'm traveling and don't have easy access to sources nor enough time
to look myself, sorry.)

Re: (featurep 'multi-tty) => t on Windows

[Juanma Barranquero]

On Fri, Dec 12, 2008 at 12:52, Eli Zaretskii <eliz@gnu.org> wrote:

> Well, boundp and fboundp can be called from C as well, so if you can
> find something that we could test for bound-ness, that will do the
> trick.

I'll take a look.

    Juanma