bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Dan Nicolaescu]

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

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[jasonr]

Quoting Dan Nicolaescu <dann@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?

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Dan Nicolaescu]

jasonr@f2s.com writes:

  > Quoting Dan Nicolaescu <dann@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.

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Juanma Barranquero]

On Wed, Dec 3, 2008 at 16:24, Dan Nicolaescu <dann@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

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Eli Zaretskii]

> Date: Wed, 3 Dec 2008 07:24:11 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: 1483@emacsbugs.donarmstrong.com
> 
> jasonr@f2s.com writes:
> 
>   > Quoting Dan Nicolaescu <dann@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.

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Dan Nicolaescu]

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

  > On Wed, Dec 3, 2008 at 16:24, Dan Nicolaescu <dann@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?

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Juanma Barranquero]

On Wed, Dec 3, 2008 at 20:15, Dan Nicolaescu <dann@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

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Dan Nicolaescu]

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

  > On Wed, Dec 3, 2008 at 20:15, Dan Nicolaescu <dann@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.

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Juanma Barranquero]

On Wed, Dec 3, 2008 at 23:03, Dan Nicolaescu <dann@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

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Juanma Barranquero]

On Wed, Dec 3, 2008 at 23:15, Juanma Barranquero <lekktu@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

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Eli Zaretskii]

> Date: Wed, 3 Dec 2008 14:03:45 -0800 (PST)
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Cc: 1483@emacsbugs.donarmstrong.com, jasonr@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.

bug#1483: cleanup: replace NO_SOCKETS_IN_FILE_SYSTEM in emacsclient.c

[Juanma Barranquero]

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.