Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Juanma Barranquero]

On Thu, Dec 11, 2008 at 00:36, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Log message:
>        (main): Fix previous change.

At last.

    Juanma

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Juanma Barranquero]

>        (decode_options): Do not allow an empty alternate_editor on
>        WINDOWSNT.

Why do you force me to use an alternate editor?

    Juanma

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Juanma Barranquero]

OK, so it works on Windows, and you just used most of my patch, but
changed EMACS_DAEMON to WINDOWSNT because you didn't like it.

I like more descriptive defines. So do others.

Can we please go back in time to the moment where arbitrary parts of
Emacs weren't yours just because you said so?

  Juanma

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Dan Nicolaescu]

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

  > OK, so it works on Windows, and you just used most of my patch, but
  > changed EMACS_DAEMON to WINDOWSNT because you didn't like it.

You asked "modify according to your taste".   Not only is my taste not to
add unneeded #defines, but the main reason is that there's other code in
src that deals with the daemon that uses just fine #ifdef WINDOWSNT.
Consistency in all directories is important.

  > Can we please go back in time to the moment where arbitrary parts of
  > Emacs weren't yours just because you said so?

Please STOP this.

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Juanma Barranquero]

On Wed, Dec 10, 2008 at 16:46, Dan Nicolaescu <dann@ics.uci.edu> wrote:

> You asked "modify according to your taste".

Yes. I also said "please don't delete the EMACS_DAEMON define".

> Not only is my taste not to
> add unneeded #defines, but the main reason is that there's other code in
> src that deals with the daemon that uses just fine #ifdef WINDOWSNT.
> Consistency in all directories is important.

That other code should also use EMACS_DAEMON or similar.

> Please STOP this.

Then please stop acting like this. You revert one of my changes after
I explicitly asked not to do, and "defend yourself" by saying that I
was provoking you... If you don't want me to think that you're acting
arbitrarily, don't do it. Please discuss before taking conflictive
decisions.

And the reason I fixed emacsclient.c on my own is that, as you left
it, it wouldn't even compile; otherwise, I would have brought the
discussion to the list first. I have no interest in fighting you; but
I also don't have the inclination to leave you to impose your view
over the code, when there are alternate POVs to consider.

    Juanma

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Chong Yidong]

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

>> Not only is my taste not to add unneeded #defines, but the main
>> reason is that there's other code in src that deals with the daemon
>> that uses just fine #ifdef WINDOWSNT.  Consistency in all directories
>> is important.
>
> That other code should also use EMACS_DAEMON or similar.

That depends on the specifics of the situation.  Could either you or Dan
point out the places in src that use WINDOWSNT to handle daemon mode, to
give us more information to work with?  (The macro should probably be
called HAVE_DAEMON for consistency.)

Another thing to consider: does the Emacs server and daemon work on
Nextstep?

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Juanma Barranquero]

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

> (The macro should probably be
> called HAVE_DAEMON for consistency.)

Agreed. But then we should rename NO_SOCKETS_IN_FILE_SYSTEM to
HAVE_SOCKETS_IN_FILE_SYSTEM (and negate every #if(n?)def that uses
it).

> Another thing to consider: does the Emacs server and daemon work on
> Nextstep?

That's a good question.

But the base discussion is whether features should be tested by
feature tests, or lumped together into the WINDOWSNT, DOS_NT,
NS_IMPL_* bags. We've been saying for years that Emacs lisp programs
must not check the Emacs version, but features. The same reasoning
applies to checking HAVE_DAEMON vs. WINDOWSNT.

    Juanma

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Chong Yidong]

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

> But the base discussion is whether features should be tested by
> feature tests, or lumped together into the WINDOWSNT, DOS_NT,
> NS_IMPL_* bags. We've been saying for years that Emacs lisp programs
> must not check the Emacs version, but features. The same reasoning
> applies to checking HAVE_DAEMON vs. WINDOWSNT.

That's typically true, but again: specifics matter.  For instance, if
the majority of the code controlled by the HAVE_DAEMON macro is
platform-dependent anyway, we would simply be replacing

#ifdef WINDOWSNT
...
#endif

with

#ifdef HAVE_DAEMON
#ifdef WINDOWSNT
...
#endif
...
#endif

Which situation pertains in the actual code?

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Juanma Barranquero]

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

> #ifdef WINDOWSNT
> ...
> #endif
>
> with
>
> #ifdef HAVE_DAEMON
> #ifdef WINDOWSNT
> ...
> #endif
> ...
> #endif
>
> Which situation pertains in the actual code?

Currently there's no Windows code to do it, so it is not clear.

    Juanma

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Jason Rumney]

Juanma Barranquero wrote:
> But the base discussion is whether features should be tested by
> feature tests, or lumped together into the WINDOWSNT, DOS_NT,
> NS_IMPL_* bags. We've been saying for years that Emacs lisp programs
> must not check the Emacs version, but features. The same reasoning
> applies to checking HAVE_DAEMON vs. WINDOWSNT.
>   

When it is just not possible to support a feature because of the 
platform, then I have no problem using the platform constant to 
conditionally compile it out. But if it is just a lack of developers on 
a particular platform that is preventing the feature from being 
implemented, then it is much easier for later developers who wish to 
implement it if there is a feature specific constant.

NO_SOCKETS_IN_FILE_SYSTEM is sitting on a blurry line, since although 
Windows does not support unix domain sockets, it is conceivable that an 
emulation of them using named pipes could be developed in future.

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Juanma Barranquero]

On Wed, Dec 10, 2008 at 17:40, Jason Rumney <jasonr@f2s.com> wrote:

> But if it is just a lack of developers on a particular platform that
> is preventing the feature from being implemented, then it is much easier for
> later developers who wish to implement it if there is a feature specific
> constant.

That's my thinking too.

As for the daemon stuff, I already posted once my opinion: if we ever
implement the possibility of hiding Emacs in the tray (or GNU/Linux
equivalent), activating the --daemon option would make sense on
Windows for consistency with non-Windows builds, because although the
implementation is quite different, the user interface (starting Emacs
and making it invisible until requested) is pretty similar. In fact, I
would *love* to have the possibility of running "emacs --daemon" and
having it start "trayed".

    Juanma

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Dan Nicolaescu]

Jason Rumney <jasonr@f2s.com> writes:

  > Juanma Barranquero wrote:
  > > But the base discussion is whether features should be tested by
  > > feature tests, or lumped together into the WINDOWSNT, DOS_NT,
  > > NS_IMPL_* bags. We've been saying for years that Emacs lisp programs
  > > must not check the Emacs version, but features. The same reasoning
  > > applies to checking HAVE_DAEMON vs. WINDOWSNT.
  > >   
  > 
  > When it is just not possible to support a feature because of the
  > platform, then I have no problem using the platform constant to
  > conditionally compile it out. But if it is just a lack of developers
  > on a particular platform that is preventing the feature from being
  > implemented, then it is much easier for later developers who wish to
  > implement it if there is a feature specific constant.
  > 
  > NO_SOCKETS_IN_FILE_SYSTEM is sitting on a blurry line, since although
  > Windows does not support unix domain sockets, it is conceivable that
  > an emulation of them using named pipes could be developed in future.

The problem with that is that WINDOWSNT has many many idiosyncrasies,
having a #define for each one of them adds an overhead for the ones of
us working on free systems.

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Lennart Borgman]

On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> The problem with that is that WINDOWSNT has many many idiosyncrasies,
> having a #define for each one of them adds an overhead for the ones of
> us working on free systems.

Exactly how does it add overhead? Is it just because there are new
#define names?

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Dan Nicolaescu]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

  > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
  > > having a #define for each one of them adds an overhead for the ones of
  > > us working on free systems.
  > 
  > Exactly how does it add overhead? Is it just because there are new
  > #define names?

Yes.  You have to learn or figure out something that you don't otherwise
need.

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Lennart Borgman]

On Wed, Dec 10, 2008 at 8:36 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>
>  > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>  > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
>  > > having a #define for each one of them adds an overhead for the ones of
>  > > us working on free systems.
>  >
>  > Exactly how does it add overhead? Is it just because there are new
>  > #define names?
>
> Yes.  You have to learn or figure out something that you don't otherwise
> need.

Thanks, I see.

But there are tools withing Emacs for doing this, or? Can't we setup a
list of hide-ifdef-env for different platforms?

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Dan Nicolaescu]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

  > On Wed, Dec 10, 2008 at 8:36 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > > "Lennart Borgman" <lennart.borgman@gmail.com> writes:
  > >
  > >  > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > >  > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
  > >  > > having a #define for each one of them adds an overhead for the ones of
  > >  > > us working on free systems.
  > >  >
  > >  > Exactly how does it add overhead? Is it just because there are new
  > >  > #define names?
  > >
  > > Yes.  You have to learn or figure out something that you don't otherwise
  > > need.
  > 
  > Thanks, I see.
  > 
  > But there are tools withing Emacs for doing this, or? 

Tools are useful, but they don't solve the problem.

  > Can't we setup a list of hide-ifdef-env for different platforms?

That's a separate issue, and IMHO it would be useful to have.

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Lennart Borgman]

On Wed, Dec 10, 2008 at 9:03 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>
>  > On Wed, Dec 10, 2008 at 8:36 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>  > > "Lennart Borgman" <lennart.borgman@gmail.com> writes:
>  > >
>  > >  > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>  > >  > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
>  > >  > > having a #define for each one of them adds an overhead for the ones of
>  > >  > > us working on free systems.
>  > >  >
>  > >  > Exactly how does it add overhead? Is it just because there are new
>  > >  > #define names?
>  > >
>  > > Yes.  You have to learn or figure out something that you don't otherwise
>  > > need.
>  >
>  > Thanks, I see.
>  >
>
>  > Can't we setup a list of hide-ifdef-env for different platforms?
>
> That's a separate issue, and IMHO it would be useful to have.

It is a separate issue too, but wouldn't it at least partly solve the
problem with learning you mentioned above?

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Dan Nicolaescu]

"Lennart Borgman" <lennart.borgman@gmail.com> writes:

  > On Wed, Dec 10, 2008 at 9:03 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > > "Lennart Borgman" <lennart.borgman@gmail.com> writes:
  > >
  > >  > On Wed, Dec 10, 2008 at 8:36 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > >  > > "Lennart Borgman" <lennart.borgman@gmail.com> writes:
  > >  > >
  > >  > >  > On Wed, Dec 10, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > >  > >  > > The problem with that is that WINDOWSNT has many many idiosyncrasies,
  > >  > >  > > having a #define for each one of them adds an overhead for the ones of
  > >  > >  > > us working on free systems.
  > >  > >  >
  > >  > >  > Exactly how does it add overhead? Is it just because there are new
  > >  > >  > #define names?
  > >  > >
  > >  > > Yes.  You have to learn or figure out something that you don't otherwise
  > >  > > need.
  > >  >
  > >  > Thanks, I see.
  > >  >
  > >
  > >  > Can't we setup a list of hide-ifdef-env for different platforms?
  > >
  > > That's a separate issue, and IMHO it would be useful to have.
  > 
  > It is a separate issue too, but wouldn't it at least partly solve the
  > problem with learning you mentioned above?

"partly solving" is not enough.

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Lennart Borgman]

> "partly solving" is not enough.

I can't help citing VS Naipaul then: "I had replaced the thought about
decay, the idea about the ideal that can be the cause of so much
grief, with the thought about change" -- (my free translation from
Swedish ... ;-)

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > "Juanma Barranquero" <lekktu@gmail.com> writes:
  > 
  > >> Not only is my taste not to add unneeded #defines, but the main
  > >> reason is that there's other code in src that deals with the daemon
  > >> that uses just fine #ifdef WINDOWSNT.  Consistency in all directories
  > >> is important.
  > >
  > > That other code should also use EMACS_DAEMON or similar.
  > 
  > That depends on the specifics of the situation.  Could either you or Dan
  > point out the places in src that use WINDOWSNT to handle daemon mode, to
  > give us more information to work with?

emacs.c: main uses DOS_NT (which is WINDOWSNT || MSDOS)
emacclient.c is not used in DOS

  > Another thing to consider: does the Emacs server and daemon work on
  > Nextstep?

Adrian has a patch to make it working on Cocoa (it's only needed because
the daemon does a fork() and continues executing in the child, and the
Cocoa libraries don't work in such a situation).  From what I
understood, the patch would no be needed on GNUStep.

Re: [Emacs-diffs] emacs/lib-src emacsclient.c ChangeLog

[Harald Hanche-Olsen]

+ Chong Yidong <cyd@stupidchicken.com>:

> Another thing to consider: does the Emacs server and daemon work on
> Nextstep?

The answer is yes, on my mac at least.

- Harald