GNU bug report logs - #1483
cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1483 in the body.
You can then email your comments to 1483 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c
Date: Tue, 2 Dec 2008 22:35:09 -0800 (PST)

NO_SOCKETS_IN_FILE_SYSTEM is the same as WINDOWSNT, so better replace it
and have one less identifier to worry about.

Message #8 received at 1483 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: jasonr <at> f2s.com
To: Dan Nicolaescu <dann <at> ics.uci.edu>, 1483 <at> debbugs.gnu.org
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in	emacsclient.c
Date: Wed,  3 Dec 2008 08:03:26 +0000

Quoting Dan Nicolaescu <dann <at> ics.uci.edu>:

> NO_SOCKETS_IN_FILE_SYSTEM is the same as WINDOWSNT, so better replace it
> and have one less identifier to worry about.

Does DOS have unix domain sockets?

And what happens when someone adds emulation of them for WINDOWSNT, they need to
go through every WINDOWSNT define to figure out which are dealing with this
feature?

In general conditional compilation should deal with features, not platforms,
even if only one platform is missing that feature.

PS: Why are you reporting this as a bug?

Message #11 received at 1483 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: jasonr <at> f2s.com
Cc: 1483 <at> debbugs.gnu.org
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in	emacsclient.c
Date: Wed, 3 Dec 2008 07:24:11 -0800 (PST)

jasonr <at> f2s.com writes:

  > Quoting Dan Nicolaescu <dann <at> ics.uci.edu>:
  > 
  > > NO_SOCKETS_IN_FILE_SYSTEM is the same as WINDOWSNT, so better replace it
  > > and have one less identifier to worry about.
  > 
  > Does DOS have unix domain sockets?

Is DOS using emacsclient?

  > And what happens when someone adds emulation of them for WINDOWSNT, they need to
  > go through every WINDOWSNT define to figure out which are dealing with this
  > feature?

That's better than everyone else having to figure out the same thing
until that hypothetical moment.

  > PS: Why are you reporting this as a bug?

So that it can be tracked.

Message #16 received at 1483 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Dan Nicolaescu" <dann <at> ics.uci.edu>, 1483 <at> debbugs.gnu.org
Cc: jasonr <at> f2s.com
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c
Date: Wed, 3 Dec 2008 16:33:54 +0100

On Wed, Dec 3, 2008 at 16:24, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:

> That's better than everyone else having to figure out the same thing
> until that hypothetical moment.

There's nothing to figure right now: NO_SOCKETS_IN_FILE_SYSTEM is
self-descriptive.

 Juanma

Message #21 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>, 1483 <at> debbugs.gnu.org
Cc: jasonr <at> f2s.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM	in	emacsclient.c
Date: Wed, 03 Dec 2008 20:30:30 +0200

> Date: Wed, 3 Dec 2008 07:24:11 -0800 (PST)
> From: Dan Nicolaescu <dann <at> ics.uci.edu>
> Cc: 1483 <at> emacsbugs.donarmstrong.com
> 
> jasonr <at> f2s.com writes:
> 
>   > Quoting Dan Nicolaescu <dann <at> ics.uci.edu>:
>   > 
>   > > NO_SOCKETS_IN_FILE_SYSTEM is the same as WINDOWSNT, so better replace it
>   > > and have one less identifier to worry about.
>   > 
>   > Does DOS have unix domain sockets?
> 
> Is DOS using emacsclient?

No, it doesn't.  And probably never will (emacsclient does not work at
all in the MS-DOS port).

But I agree with Jason and Juanma: replacing the above symbol with
just WINDOWSNT gains very little, but obfuscates the condition being
tested.  If anything, I'd support the opposite changes: replace each
and every ugly system name such as WINDOWSNT with a meaningful symbol
whose name would explain what is the underlying (mis)feature.

Message #29 received at 1483 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 1483 <at> debbugs.gnu.org, jasonr <at> f2s.com
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c
Date: Wed, 3 Dec 2008 11:15:04 -0800 (PST)

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

  > On Wed, Dec 3, 2008 at 16:24, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
  > 
  > > That's better than everyone else having to figure out the same thing
  > > until that hypothetical moment.
  > 
  > There's nothing to figure right now: NO_SOCKETS_IN_FILE_SYSTEM is
  > self-descriptive.

Code like this:
struct option longopts[] =
{
  { "no-wait",  no_argument,       NULL, 'n' },
  { "eval",     no_argument,          NULL, 'e' },
  { "help",     no_argument,             NULL, 'H' },
  { "version",  no_argument,                NULL, 'V' },
  { "tty",      no_argument,       NULL, 't' },
  { "nw",       no_argument,       NULL, 't' },
  { "create-frame", no_argument,   NULL, 'c' },
  { "alternate-editor", required_argument, NULL, 'a' },
  { "retry-with-daemon", no_argument, NULL, 't' },
#ifndef NO_SOCKETS_IN_FILE_SYSTEM
  { "socket-name",      required_argument, NULL, 's' },
#endif
  { "server-file",      required_argument, NULL, 'f' },
#ifndef WINDOWSNT
  { "display",  required_argument, NULL, 'd' },
#endif
  { 0, 0, 0, 0 }
};

should only need a single #ifdef.  


The clear precedent is that WINDOWSNT already encompasses a bazillion
features, why would a bazillion + 1 won't make any difference?  It would
make a difference for the vast majority of people that write to the
emacs repository, most do not use windows and can just ignore the #ifdef
WINDOWSNT code.

On a not so related note, why are there #includes on line 671 in
emacsclient.c instead of at the beginning of the file?

Message #34 received at 1483 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Dan Nicolaescu" <dann <at> ics.uci.edu>
Cc: 1483 <at> debbugs.gnu.org, jasonr <at> f2s.com
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c
Date: Wed, 3 Dec 2008 22:08:00 +0100

On Wed, Dec 3, 2008 at 20:15, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:

> should only need a single #ifdef.

Why?

> The clear precedent is that WINDOWSNT already encompasses a bazillion
> features, why would a bazillion + 1 won't make any difference?

As Eli pointed out, we should be moving towards decreasing the
bazillion things conflated into #ifdef WINDOWSNT, not increasing them.

> It would
> make a difference for the vast majority of people that write to the
> emacs repository, most do not use windows and can just ignore the #ifdef
> WINDOWSNT code.

Apparently it's not that confusing. There has been no complain until
now from the people who's hacked on emacsclient.

> On a not so related note, why are there #includes on line 671 in
> emacsclient.c instead of at the beginning of the file?

Because they affect code inside a big #else which goes from there to
the end of the file.

They were already there before the TCP socket support, indeed from
version 1.1 of the file (though it was line 49 back then...)

    Juanma

Message #37 received at 1483 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: "Juanma Barranquero" <lekktu <at> gmail.com>
Cc: 1483 <at> debbugs.gnu.org, jasonr <at> f2s.com
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c
Date: Wed, 3 Dec 2008 14:03:45 -0800 (PST)

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

  > On Wed, Dec 3, 2008 at 20:15, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:
  > 
  > > should only need a single #ifdef.
  > 
  > Why?

Because it's simpler. 

  > > The clear precedent is that WINDOWSNT already encompasses a bazillion
  > > features, why would a bazillion + 1 won't make any difference?
  > 
  > As Eli pointed out, we should be moving towards decreasing the
  > bazillion things conflated into #ifdef WINDOWSNT, not increasing them.

Good luck convincing anyone about that.  There are 378 undocumented
macros in admin/CPP-DEFINES, and probably 1000-2000 in use in src/*,
increasing that number does not seem such a hot idea.

  > > It would
  > > make a difference for the vast majority of people that write to the
  > > emacs repository, most do not use windows and can just ignore the #ifdef
  > > WINDOWSNT code.
  > 
  > Apparently it's not that confusing. There has been no complain until
  > now from the people who's hacked on emacsclient.

This is not a valid proof.  Maybe people didn't want to complain, or
didn't figure out the difference, etc.

  > > On a not so related note, why are there #includes on line 671 in
  > > emacsclient.c instead of at the beginning of the file?
  > 
  > Because they affect code inside a big #else which goes from there to
  > the end of the file.
  > 
  > They were already there before the TCP socket support, indeed from
  > version 1.1 of the file (though it was line 49 back then...)

Still not too good, and a deviation from the normal style of not having
includes in the middle of the file.

Message #42 received at 1483 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Dan Nicolaescu" <dann <at> ics.uci.edu>
Cc: 1483 <at> debbugs.gnu.org, jasonr <at> f2s.com
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c
Date: Wed, 3 Dec 2008 23:15:42 +0100

On Wed, Dec 3, 2008 at 23:03, Dan Nicolaescu <dann <at> ics.uci.edu> wrote:

> Because it's simpler.

Simpler does not always imply clearer.

> Good luck convincing anyone about that.

I don't have to convince anyone, because I'm not proposing changing
anything. You're the one who wants to do it, and until this moment
three people who have modified that code more or less extensively have
expressed their opposition to the idea.

> There are 378 undocumented
> macros in admin/CPP-DEFINES, and probably 1000-2000 in use in src/*,
> increasing that number does not seem such a hot idea.

That's like saying "there are thousand of undocumented local variables
in the sources, let's reuse variables instead of creating new ones".
If they are undocumented, the way to fix it is documenting them, not
conflating them in as few as possible.

> This is not a valid proof.  Maybe people didn't want to complain, or
> didn't figure out the difference, etc.

Yeah, or maybe not. But we're talking of people who's hacked that
source and apparently didn't have any trouble.

> Still not too good, and a deviation from the normal style of not having
> includes in the middle of the file.

process.c has an include at line 388, and I've just looked for a few seconds.

But still, if you want to change it and the result is clearer, by all
means go ahead.

    Juanma

Message #49 received at 1483 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Dan Nicolaescu" <dann <at> ics.uci.edu>
Cc: 1483 <at> debbugs.gnu.org, jasonr <at> f2s.com
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c
Date: Thu, 4 Dec 2008 00:51:05 +0100

On Wed, Dec 3, 2008 at 23:15, Juanma Barranquero <lekktu <at> gmail.com> wrote:

> process.c has an include at line 388, and I've just looked for a few seconds.

Clearer still:

32 matches for "^#include" in buffer: image.c
     21:#include <config.h>
     22:#include <stdio.h>
     23:#include <math.h>
     24:#include <ctype.h>
     27:#include <unistd.h>
     34:#include "lisp.h"
     35:#include "frame.h"
     36:#include "window.h"
     37:#include "dispextern.h"
     38:#include "blockinput.h"
     39:#include "systime.h"
     40:#include <epaths.h>
     41:#include "character.h"
     42:#include "coding.h"
     43:#include "termhooks.h"
     44:#include "font.h"
     47:#include "xterm.h"
     48:#include <sys/types.h>
     49:#include <sys/stat.h>
     65:#include "w32term.h"
     85:#include "nsterm.h"
     86:#include <sys/types.h>
     87:#include <sys/stat.h>
   3324:#include "X11/xpm.h"
   3331:#include "X11/xpm.h"
   6418:#include <jpeglib.h>
   6419:#include <jerror.h>
   6420:#include <setjmp.h>
   6979:#include <tiffio.h>
   7451:#include <gif_lib.h>
   7456:#include <gif_lib.h>
   7876:#include <librsvg/rsvg.h>

    Juanma

Message #54 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>, 1483 <at> debbugs.gnu.org
Cc: lekktu <at> gmail.com, jasonr <at> f2s.com, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in	emacsclient.c
Date: Thu, 04 Dec 2008 06:13:15 +0200

> Date: Wed, 3 Dec 2008 14:03:45 -0800 (PST)
> From: Dan Nicolaescu <dann <at> ics.uci.edu>
> Cc: 1483 <at> emacsbugs.donarmstrong.com, jasonr <at> f2s.com
> 
>   > > The clear precedent is that WINDOWSNT already encompasses a bazillion
>   > > features, why would a bazillion + 1 won't make any difference?
>   > 
>   > As Eli pointed out, we should be moving towards decreasing the
>   > bazillion things conflated into #ifdef WINDOWSNT, not increasing them.
> 
> Good luck convincing anyone about that.

I don't see any need for convincing someone about that.  Making such
changes is routine maintenance that doesn't need any approval.  The
main problem is to find a volunteer for this huge job.

> There are 378 undocumented macros in admin/CPP-DEFINES, and probably
> 1000-2000 in use in src/*, increasing that number does not seem such
> a hot idea.

The sheer number of defines is not the problem.  The problem is that
some or maybe even most of them don't clearly tell what they mean.  It
is this problem that IMO we should work on, not just on removing
defines or lumping unrelated features into a single OS-dependent
define.

Message #64 received at 1483-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, Jason Rumney <jasonr <at> f2s.com>,
	1483-done <at> debbugs.gnu.org
Subject: Re: bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in
	emacsclient.c
Date: Mon, 4 Jul 2011 13:34:13 +0200

Consensus among the Windows developers was that we oppose conflating
more meanings into WINDOWSNT and would in fact prefer to do the
opposite, so I'm closing this bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.