I can't build from cvs sources on cygwin for some time now

I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Hello group!

Not sure when it broke, I have a build dated 11:th of september that 
works just fine. But when I tried to build a new version two weeks or so 
ago using the same procedure as before, it wouldn't build. Tried again 
now. Still won't build. Error:
In file included from emacsclient.c:286:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: 
warning: #warning "fd_set and associated macros have been defined in 
sys/types.      This may cause runtime problems with W32 sockets"
gcc -o oo-spd/i386/emacsclient.exe   -mno-cygwin 
oo-spd/i386/emacsclient.o oo-spd/i386/getopt.o oo-spd/i386/getopt1.o 
oo-spd/i386/ntlib.o -lwsock32   -ladvapi32
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x11b): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x1b9): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x45b): undefined 
reference to `__imp___ctype_'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x473): undefined 
reference to `__imp___ctype_'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x4f0): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x724): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x7b4): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x8b9): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0x923): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0xa2f): more undefined 
references to `___getreent' follow
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0xbc5): undefined 
reference to `_errno'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0xbd4): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0xcfc): undefined 
reference to `__imp___ctype_'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0xdd2): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0xe5e): undefined 
reference to `___getreent'
oo-spd/i386/emacsclient.o:emacsclient.c:(.text+0xf29): undefined 
reference to `___getreent'
collect2: ld returned 1 exit status
mingw32-make[1]: *** [oo-spd/i386/emacsclient.exe] Error 1
mingw32-make[1]: Leaving directory `c:/cvsemacs/emacs/lib-src'
mingw32-make: *** [all-other-dirs-gmake] Error 2

My steps:
$ export CVS_RSH="ssh"
$ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co emacs
$ cd emacs/nt/
$ ./configure.bat --with-gcc --no-cygwin --no-debug
$ mingw32-make bootstrap-clean

Cygwin is fully updated (gcc version is 3.4.4-1), mingw32-make is 
version 3.81. I scanned this group and founds some posts seeming to 
indicate a problem with debug builds of emacs on cygwin using that 
version of gcc. I'm not building a debug build, but I built gcc-4.1.1 
myself a few days ago just to try. Unfortunately, I couldn't build emacs 
using it (sorry, no error log). And even if I has succeeded doing that, 
I really would like to use cygwin's gcc so I can pass it -mno-cygwin 
because I don't want emacs to depend on cygwin1.dll. What should I do? 
I've been enjoying following the cvs version for more than two years 
now. There have been problems compiling before but they were usually 
fixed promptly. Now I don't even see any posts from people having the 
same problems as me... What prompted me to compile a new version from 
cvs was that I wanted to ask about a few problems I'm having and I 
wanted to test the latest sources first to see if they fixed the 
problems before I asked.

/ E

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:

> But when I tried to build a new version two weeks or so
> ago using the same procedure as before, it wouldn't build. Tried again
> now. Still won't build. Error:
> In file included from emacsclient.c:286:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2:
> warning: #warning "fd_set and associated macros have been defined in
> sys/types.      This may cause runtime problems with W32 sockets"

lib-src/emacsclient.c has a

#include <sys/types.h>

near the beginning. Could you please wrap it on

#ifndef CYGWIN
...
#endif

(assuming there's CYGWIN or another define that can be used to detect
that we're compiling under cygwin) and report back?

Just out of curiosity. Did you run ./configure?

                    /L/e/k/t/u

Re: I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Juanma Barranquero skrev:
> On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:
> 
>> But when I tried to build a new version two weeks or so
>> ago using the same procedure as before, it wouldn't build. Tried again
>> now. Still won't build. Error:
>> In file included from emacsclient.c:286:
>> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: 
>>
>> warning: #warning "fd_set and associated macros have been defined in
>> sys/types.      This may cause runtime problems with W32 sockets"
> 
> lib-src/emacsclient.c has a
> 
> #include <sys/types.h>
> 
> near the beginning. Could you please wrap it on
> 
> #ifndef CYGWIN
> ...
> #endif

Thanks, done that now and trying to recompile (did a bootstrap-clean so 
it will take a few minutes before I know how it went).

> 
> (assuming there's CYGWIN or another define that can be used to detect
> that we're compiling under cygwin) and report back?
> 
> Just out of curiosity. Did you run ./configure?

I ran configure.bat in the nt subdir as I have always done when building 
emacs on this platform. It was mentioned in "My steps" in my op.

> 
>                    /L/e/k/t/u

Thanks for the quick reply!

/ E

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:

> Thanks, done that now and trying to recompile (did a bootstrap-clean so
> it will take a few minutes before I know how it went).

Did you use "#ifndef CYGWIN"? Does CYGWIN exist?

> I ran configure.bat in the nt subdir as I have always done when building
> emacs on this platform.

I don't understand. If you're doing a Cygwin build, you don't run
nt/configure.bat, just ./configure on the root dir of the source
tarball...

                    /L/e/k/t/u

Re: I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Juanma Barranquero skrev:
> On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:
> 
>> Thanks, done that now and trying to recompile (did a bootstrap-clean so
>> it will take a few minutes before I know how it went).
> 
> Did you use "#ifndef CYGWIN"? Does CYGWIN exist?
> 
>> I ran configure.bat in the nt subdir as I have always done when building
>> emacs on this platform.
> 
> I don't understand. If you're doing a Cygwin build, you don't run
> nt/configure.bat, just ./configure on the root dir of the source
> tarball...
> 
>                    /L/e/k/t/u

I'm using the cygwin tools to make mingw build. Nothing weird about it.

Re: I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Eric Lilja skrev:
> Juanma Barranquero skrev:
>> On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:
>>
>>> Thanks, done that now and trying to recompile (did a bootstrap-clean so
>>> it will take a few minutes before I know how it went).
>>
>> Did you use "#ifndef CYGWIN"? Does CYGWIN exist?
>>
>>> I ran configure.bat in the nt subdir as I have always done when building
>>> emacs on this platform.
>>
>> I don't understand. If you're doing a Cygwin build, you don't run
>> nt/configure.bat, just ./configure on the root dir of the source
>> tarball...
>>
>>                    /L/e/k/t/u
> 
> I'm using the cygwin tools to make mingw build. Nothing weird about it.

Didn't help. Somewhere it decides to include <sys/types.h> but it should 
not because I specified --no-cygwin when configuring. Got the same 
warning and error.
CYGWIN is not defined, WINDOWSNT is, still that files gets included 
somewhere and then the compiler warns later when <winsock2.h> is included.
gcc -DWINDOWSNT -DHAVE_GETCWD -DHAVE_STRERROR -c -o 
oo-spd/i386/emacsclient.o emacsclient.c
-mno-cygwin is passed to other files...but not emacsclient.c it seems. Bug?

/ E

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:

> Didn't help. Somewhere it decides to include <sys/types.h> but it should
> not because I specified --no-cygwin when configuring. Got the same
> warning and error.

What does contain the end of src/config.h? (The part written by configure.bat).

                    /L/e/k/t/u

Re: I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Juanma Barranquero skrev:
> On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:
> 
>> Didn't help. Somewhere it decides to include <sys/types.h> but it should
>> not because I specified --no-cygwin when configuring. Got the same
>> warning and error.
> 
> What does contain the end of src/config.h? (The part written by 
> configure.bat).
> 
>                    /L/e/k/t/u

$ tail ../src/config.h
#else
#define NO_RETURN       /* nothing */
#endif
#endif

/* arch-tag: df720992-aa5a-499a-882d-958dc5eeb5e9
    (do not change this comment) */

/* Start of settings from configure.bat.  */
/* End of settings from configure.bat.  */

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/13/06, Eric Lilja <mindcooler@gmail.com> wrote:
> /* Start of settings from configure.bat.  */
> /* End of settings from configure.bat.  */

And the start of lib-src/Makefile?

                    /L/e/k/t/u

Re: I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Juanma Barranquero skrev:
> On 11/13/06, Eric Lilja <mindcooler@gmail.com> wrote:
>> /* Start of settings from configure.bat.  */
>> /* End of settings from configure.bat.  */
> 
> And the start of lib-src/Makefile?
> 
>                    /L/e/k/t/u

$ head  ../lib-src/Makefile
# Start of settings from configure.bat
COMPILER=gcc
MCPU_FLAG=-mtune=pentium4
NODEBUG=1
NOCYGWIN=1
# End of settings from configure.bat

#  -*- Makefile -*- definition file for building GNU Emacs on Windows NT.
#  Copyright (C) 2000, 2001, 2002, 2003, 2004,
#    2005, 2006 Free Software Foundation, Inc.

Look OK to me...

Re: I can't build from cvs sources on cygwin for some time now

[Jason Rumney]

Eric Lilja wrote
> gcc -DWINDOWSNT -DHAVE_GETCWD -DHAVE_STRERROR -c -o 
> oo-spd/i386/emacsclient.o emacsclient.c
> -mno-cygwin is passed to other files...but not emacsclient.c it seems. 
> Bug?
I've just checked in a fix for this. You'll need to run configure.bat to 
regenerate the makefiles, but you shouldn't need to bootstrap to test 
the fix.

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/13/06, Jason Rumney <jasonr@gnu.org> wrote:

> I've just checked in a fix for this.

Thanks!

                    /L/e/k/t/u

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/13/06, Juanma Barranquero <lekktu@gmail.com> wrote:

> > I've just checked in a fix for this.

Hmm.  emacsclient doesn't like something in src/config.h. After your
patch, I can only get it to compile by commenting out

#include <config.h>

??

                    /L/e/k/t/u

Re: I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Juanma Barranquero skrev:
> On 11/13/06, Juanma Barranquero <lekktu@gmail.com> wrote:
> 
>> > I've just checked in a fix for this.
> 
> Hmm.  emacsclient doesn't like something in src/config.h. After your
> patch, I can only get it to compile by commenting out
> 
> #include <config.h>
> 
> ??
> 
>                    /L/e/k/t/u

I didn't try your work-around, Juanma, but I am too seing new 
compilation errors after Jason's check-in. Still, I think Jason is on 
the right track. If I specify --no-cygwin when running nt/configure.bat 
all c language source files should be compiled with the flag 
-mno-cygwin, not just most. Thanks for looking into this, Jason.

/ E

Re: I can't build from cvs sources on cygwin for some time now

[Jason Rumney]

Juanma Barranquero wrote:
> Hmm.  emacsclient doesn't like something in src/config.h. After your
> patch, I can only get it to compile by commenting out
>
> #include <config.h>

It seems I didn't follow my own advice for testing this.
I've checked in some changes that give the correct value for 
HAVE_INET_SOCKETS on windows, and I see you beat me to the rest of the 
change (allowing winsock to load).

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/13/06, Jason Rumney <jasonr@gnu.org> wrote:

> It seems I didn't follow my own advice for testing this.

Doesn't it happen to all of us sooner or later? ;)

> I've checked in some changes that give the correct value for
> HAVE_INET_SOCKETS on windows

Thanks.
                    /L/e/k/t/u

emacsclientw

[Jason Rumney]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

Have you tested the emacsclientw.exe build with MSVC?

I think there is also a need for something that starts Emacs if it is 
not already running, so I came up with the following (based on 
runemacs.c), which I intended to check into the nt directory. The 
intention is to use this to associate Emacs with file types in Explorer 
and other applications that allow external editors.



[-- Attachment #2: emacsassoc.c --]
[-- Type: text/plain, Size: 3223 bytes --]

/* Copyright (C) 2006 Free Software Foundation, Inc.

This file is part of GNU Emacs.

GNU Emacs is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Emacs; see the file COPYING.  If not, write to
the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA.  */


/*
  Simple program to start emacsclient or emacs with its console window
  hidden.

  This program is provided for conveniently associating emacs with
  files in Windows Explorer and other GUI programs.

  */

#include <windows.h>
#include <string.h>
#include <malloc.h>

int launch_app(char *dir_name, char *app_name, LPSTR cmd_line)
{
  STARTUPINFO start;
  SECURITY_ATTRIBUTES sec_attrs;
  PROCESS_INFORMATION child;
  int wait_for_child = FALSE;
  DWORD priority_class = NORMAL_PRIORITY_CLASS;
  DWORD ret_code = 0;
  char *new_cmd_line;

  new_cmd_line = alloca (MAX_PATH + strlen (cmd_line) + 3);

  /* Quote executable name in case of spaces in the path.  */
  *new_cmd_line = '"';
  strcpy (new_cmd_line + 1, dir_name);

  strcat (new_cmd_line, "\\");
  strcat (new_cmd_line, app_name);
  strcat (new_cmd_line, "\" ");

  /* Append original arguments if any.  */
  strcat (new_cmd_line, cmd_line);

  memset (&start, 0, sizeof (start));
  start.cb = sizeof (start);
  start.dwFlags = STARTF_USESHOWWINDOW | STARTF_USECOUNTCHARS;
  start.wShowWindow = SW_HIDE;
  /* Ensure that we don't waste memory if the user has specified a huge
     default screen buffer for command windows.  */
  start.dwXCountChars = 80;
  start.dwYCountChars = 25;

  sec_attrs.nLength = sizeof (sec_attrs);
  sec_attrs.lpSecurityDescriptor = NULL;
  sec_attrs.bInheritHandle = FALSE;

  if (CreateProcess (NULL, new_cmd_line, &sec_attrs, NULL, TRUE, priority_class,
                     NULL, NULL, &start, &child))
    {
      WaitForSingleObject (child.hProcess, INFINITE);
      GetExitCodeProcess (child.hProcess, &ret_code);

      CloseHandle (child.hThread);
      CloseHandle (child.hProcess);
    }
  else
    ret_code = 1;

  return ret_code;
}

int WINAPI
WinMain (HINSTANCE self, HINSTANCE prev, LPSTR cmd_line, int show)
{
  char dir_name[MAX_PATH];
  char *p;

  /* Figure out what directory this is run from, so we can find the
     emacsclient and emacs executables.  */
  if (!GetModuleFileName (NULL, dir_name, MAX_PATH))
    goto error;
  if ((p = strrchr (dir_name, '\\')) == NULL)
    goto error;
  *p = 0;

  if ((launch_app (dir_name, "emacsclient.exe", cmd_line) == 0)
      || launch_app(dir_name, "emacs.exe", cmd_line) == 0)
    return 0;

 error:
  MessageBox (NULL, "Could not start Emacs", "Error", MB_ICONSTOP);
  return 1;
}


[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacsclientw

[Juanma Barranquero]

On 11/13/06, Jason Rumney <jasonr@gnu.org> wrote:

> Have you tested the emacsclientw.exe build with MSVC?

No, I have not set up a build enviroment for MSVC. Did you try it?

BTW, Lennart's got a bunch of changes to emacsclient that would allow
emacsclient's error messages to go to GUI message boxes when run as
emacsclientw.exe. I'm testing it right now.

> I think there is also a need for something that starts Emacs if it is
> not already running, so I came up with the following (based on
> runemacs.c), which I intended to check into the nt directory. The
> intention is to use this to associate Emacs with file types in Explorer
> and other applications that allow external editors.

Cool.

                    /L/e/k/t/u

Re: emacsclientw

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Juanma Barranquero wrote:
> On 11/13/06, Jason Rumney <jasonr@gnu.org> wrote:
>
>> Have you tested the emacsclientw.exe build with MSVC?
>
> No, I have not set up a build enviroment for MSVC. Did you try it?
>
> BTW, Lennart's got a bunch of changes to emacsclient that would allow
> emacsclient's error messages to go to GUI message boxes when run as
> emacsclientw.exe. I'm testing it right now.

I have attached this patch. Neither Juanma nor I can test it on for 
example GNU/Linux. Can someone please do that? (It should in effect 
change nothing at all except on w32.)


[-- Attachment #2: emacsclient-messagebox.diff --]
[-- Type: text/plain, Size: 9731 bytes --]

Index: emacsclient.c
===================================================================
RCS file: /cvsroot/emacs/emacs/lib-src/emacsclient.c,v
retrieving revision 1.89
diff -u -r1.89 emacsclient.c
--- emacsclient.c	10 Nov 2006 15:41:44 -0000	1.89
+++ emacsclient.c	13 Nov 2006 00:31:08 -0000
@@ -30,6 +30,7 @@
 
 # include <malloc.h>
 # include <stdlib.h>
+# include <windows.h>
 
 # define HAVE_SOCKETS
 # define HAVE_INET_SOCKETS
@@ -142,6 +143,109 @@
   { 0, 0, 0, 0 }
 };
 
+/* Message functions. */
+
+#ifdef WINDOWSNT
+int w32_console_app = 0;
+
+void
+w32_check_console_app()
+{
+  /* Did not work, found also in nonconsole app: stdinhandle =
+     GetStdHandle(STD_OUTPUT_HANDLE);
+   */
+  /* Test for console title */
+  TCHAR szOldTitle[MAX_PATH];
+  DWORD titlen;
+
+  titlen = GetConsoleTitle(szOldTitle, MAX_PATH);
+  if (titlen) {
+    //MessageBox ( NULL, szOldTitle, "testing", MB_ICONINFORMATION);
+    w32_console_app = 1;
+  } else {
+    //MessageBox ( NULL, "no title", "testing", MB_ICONINFORMATION);
+  }
+  //exit (EXIT_FAILURE);
+}
+#endif
+
+void
+message_internal(msg, is_error)
+     char *msg;
+     int is_error;
+{
+#ifdef WINDOWSNT
+  if (!w32_console_app) {
+    if (is_error) {
+      MessageBox (NULL, msg, "Emacsclient", MB_ICONINFORMATION);
+    } else {
+      MessageBox (NULL, msg, "Emacsclient ERROR", MB_ICONINFORMATION);
+    }
+  } else {
+#endif
+    //MessageBox (NULL, "here 0", "Emacsclient ERROR", MB_ICONINFORMATION);
+    if (is_error) {
+      //MessageBox (NULL, "here 1", "Emacsclient ERROR", MB_ICONINFORMATION);
+      fprintf(stderr, msg);
+    } else {
+      //MessageBox (NULL, "here 2", "Emacsclient ERROR", MB_ICONINFORMATION);
+      printf(msg);
+    }
+#ifdef WINDOWSNT
+  }
+#endif
+}
+
+void
+errormsg(msg)
+     char *msg;
+{
+  message_internal(msg, 1);
+}
+
+void
+errormsg1(msg, par1)
+     char *msg;
+     char *par1;
+{
+  char buf[2048];
+  sprintf(buf, msg, par1);
+  message_internal(buf, 1);
+}
+
+void
+errormsg2(msg, par1, par2)
+     char *msg;
+     char *par1;
+     char *par2;
+{
+  char buf[2048];
+  sprintf(buf, msg, par1, par2);
+  message_internal(buf, 1);
+}
+
+void
+errormsg3(msg, par1, par2, par3)
+     char *msg;
+     char *par1;
+     char *par2;
+     char *par3;
+{
+  char buf[2048];
+  sprintf(buf, msg, par1, par2, par3);
+  message_internal(buf, 1);
+}
+
+void
+message1(msg, par1)
+     char *msg;
+     char *par1;
+{
+  char buf[2048];
+  sprintf(buf, msg, par1);
+  message_internal(buf, 1);
+}
+
 /* Decode the options from argv and argc.
    The global variable `optind' will say how many arguments we used up.  */
 
@@ -199,7 +303,7 @@
 	  break;
 
 	case 'V':
-	  printf ("emacsclient %s\n", VERSION);
+	  message1 ("emacsclient %s\n", VERSION);
 	  exit (EXIT_SUCCESS);
 	  break;
 
@@ -208,7 +312,7 @@
 	  break;
 
 	default:
-	  fprintf (stderr, "Try `%s --help' for more information\n", progname);
+	  errormsg1 ("Try `%s --help' for more information\n", progname);
 	  exit (EXIT_FAILURE);
 	  break;
 	}
@@ -218,7 +322,7 @@
 void
 print_help_and_exit ()
 {
-  printf (
+  message1 (
 	  "Usage: %s [OPTIONS] FILE...\n\
 Tell the Emacs server to visit the specified files.\n\
 Every FILE can be either just a FILENAME or [+LINE[:COLUMN]] FILENAME.\n\
@@ -259,7 +363,7 @@
       argv[i] = (char *)alternate_editor;
 #endif
       execvp (alternate_editor, argv + i);
-      fprintf (stderr, "%s: error executing alternate editor \"%s\"\n",
+      errormsg2 ("%s: error executing alternate editor \"%s\"\n",
                progname, alternate_editor);
     }
   exit (EXIT_FAILURE);
@@ -273,9 +377,8 @@
      int argc;
      char **argv;
 {
-  fprintf (stderr, "%s: Sorry, the Emacs server is supported only\n",
+  errormsg1 ("%s: Sorry, the Emacs server is supported only\non systems with Berkely sockets.\n",
 	   argv[0]);
-  fprintf (stderr, "on systems with Berkeley sockets.\n");
 
   fail (argc, argv);
 }
@@ -424,7 +527,7 @@
 
   if (WSAStartup (MAKEWORD (2, 0), &wsaData))
     {
-      fprintf (stderr, "%s: error initializing WinSock2", progname);
+      errormsg1 ("%s: error initializing WinSock2", progname);
       exit (EXIT_FAILURE);
     }
 
@@ -480,7 +583,7 @@
     }
   else
     {
-      fprintf (stderr, "%s: invalid configuration info", progname);
+      errormsg1 ("%s: invalid configuration info", progname);
       exit (EXIT_FAILURE);
     }
 
@@ -490,7 +593,7 @@
 
   if (! fread (authentication, AUTH_KEY_LENGTH, 1, config))
     {
-      fprintf (stderr, "%s: cannot read authentication info", progname);
+      errormsg1 ("%s: cannot read authentication info", progname);
       exit (EXIT_FAILURE);
     }
 
@@ -535,7 +638,7 @@
     return INVALID_SOCKET;
 
   if (server.sin_addr.s_addr != inet_addr ("127.0.0.1"))
-    fprintf (stderr, "%s: connected to remote socket at %s\n",
+    errormsg2 ("%s: connected to remote socket at %s\n",
              progname, inet_ntoa (server.sin_addr));
 
   /*
@@ -543,8 +646,8 @@
    */
   if ((s = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0)
     {
-      fprintf (stderr, "%s: ", progname);
-      perror ("socket");
+      errormsg2 ("%s: socket: %s\n", progname, strerror(errno));
+      //perror ("socket");
       return INVALID_SOCKET;
     }
 
@@ -553,8 +656,8 @@
    */
   if (connect (s, (struct sockaddr *) &server, sizeof server) < 0)
     {
-      fprintf (stderr, "%s: ", progname);
-      perror ("connect");
+      errormsg2 ("%s: connect: %s\n", progname, strerror(errno));
+      //perror ("connect");
       return INVALID_SOCKET;
     }
 
@@ -606,8 +709,8 @@
 
   if ((s = socket (AF_UNIX, SOCK_STREAM, 0)) < 0)
     {
-      fprintf (stderr, "%s: ", progname);
-      perror ("socket");
+      errormsg2 ("%s: socket: %s\n", progname, strerror(errno));
+      //perror ("socket");
       return INVALID_SOCKET;
     }
 
@@ -637,7 +740,7 @@
       strcpy (server.sun_path, socket_name);
     else
       {
-	fprintf (stderr, "%s: socket-name %s too long",
+	errormsg2 ("%s: socket-name %s too long",
 		 progname, socket_name);
 	exit (EXIT_FAILURE);
       }
@@ -672,7 +775,7 @@
 		  strcpy (server.sun_path, socket_name);
 		else
 		  {
-		    fprintf (stderr, "%s: socket-name %s too long",
+		    errormsg2 ("%s: socket-name %s too long",
 			     progname, socket_name);
 		    exit (EXIT_FAILURE);
 		  }
@@ -692,7 +795,7 @@
            we are root. */
         if (0 != geteuid ())
           {
-            fprintf (stderr, "%s: Invalid socket owner\n", progname);
+            errormsg1 ("%s: Invalid socket owner\n", progname);
 	    return INVALID_SOCKET;
           }
         break;
@@ -700,12 +803,12 @@
       case 2:
         /* `stat' failed */
         if (saved_errno == ENOENT)
-          fprintf (stderr,
+          errormsg1 (
                    "%s: can't find socket; have you started the server?\n\
 To start the server in Emacs, type \"M-x server-start\".\n",
 		   progname);
         else
-          fprintf (stderr, "%s: can't stat %s: %s\n",
+          errormsg3 ("%s: can't stat %s: %s\n",
 		   progname, server.sun_path, strerror (saved_errno));
         return INVALID_SOCKET;
       }
@@ -714,8 +817,8 @@
   if (connect (s, (struct sockaddr *) &server, strlen (server.sun_path) + 2)
       < 0)
     {
-      fprintf (stderr, "%s: ", progname);
-      perror ("connect");
+      errormsg2 ("%s: connect: %s\n", progname, strerror(errno));
+      //perror ("connect");
       return INVALID_SOCKET;
     }
 
@@ -738,7 +841,7 @@
       if ((s != INVALID_SOCKET) || alternate_editor)
         return s;
 
-      fprintf (stderr, "%s: error accessing socket \"%s\"",
+      errormsg2 ("%s: error accessing socket \"%s\"",
                progname, socket_name);
       exit (EXIT_FAILURE);
     }
@@ -754,7 +857,7 @@
       if ((s != INVALID_SOCKET) || alternate_editor)
         return s;
 
-      fprintf (stderr, "%s: error accessing server file \"%s\"",
+      errormsg2 ("%s: error accessing server file \"%s\"",
                progname, server_file);
       exit (EXIT_FAILURE);
     }
@@ -773,7 +876,7 @@
     return s;
 
   /* No implicit or explicit socket, and no alternate editor.  */
-  fprintf (stderr, "%s: No socket or alternate editor.  Please use:\n\n"
+  errormsg1 ("%s: No socket or alternate editor.  Please use:\n\n"
 #ifndef NO_SOCKETS_IN_FILE_SYSTEM
 "\t--socket-name\n"
 #endif
@@ -793,6 +896,10 @@
   char *cwd;
   char string[BUFSIZ+1];
 
+#ifdef WINDOWSNT
+  w32_check_console_app();
+#endif
+
   progname = argv[0];
 
   /* Process options.  */
@@ -800,8 +907,8 @@
 
   if ((argc - optind < 1) && !eval)
     {
-      fprintf (stderr, "%s: file name or argument required\n", progname);
-      fprintf (stderr, "Try `%s --help' for more information\n", progname);
+      errormsg2 ("%s: file name or argument required\nTry `%s --help' for more information\n",
+              progname, progname);
       exit (EXIT_FAILURE);
     }
 
@@ -817,10 +924,10 @@
     {
       /* getwd puts message in STRING if it fails.  */
 #ifdef HAVE_GETCWD
-      fprintf (stderr, "%s: %s (%s)\n", progname,
+      errormsg3 ("%s: %s (%s)\n", progname,
 	       "Cannot get current working directory", strerror (errno));
 #else
-      fprintf (stderr, "%s: %s (%s)\n", progname, string, strerror (errno));
+      errormsg3 ("%s: %s (%s)\n", progname, string, strerror (errno));
 #endif
       fail (argc, argv);
     }

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacsclientw

[dhruva]

Hi,

I was looking for something like this. Thank you.

On 11/13/06, Jason Rumney <jasonr@gnu.org> wrote:
> Have you tested the emacsclientw.exe build with MSVC?

I built it and tried it under MSVC. It works fine. I feel there is a
need to have emacsclient's "--no-wait" option to be able to set in an
environmental variable. Once I associate the file extensions to open
with emacsclientw, I do not want to keep getting the message in the
minibuffer area warning about clients...This did not happen with
gnuclientw.

-dk

-- 
dhruva (dk)
Contents reflect my personal views only!

Re: emacsclientw

[Juanma Barranquero]

On 11/13/06, dhruva <dhruvakm@gmail.com> wrote:

> I feel there is a
> need to have emacsclient's "--no-wait" option to be able to set in an
> environmental variable.

What for?

> Once I associate the file extensions to open
> with emacsclientw, I do not want to keep getting the message in the
> minibuffer area warning about clients...This did not happen with
> gnuclientw.

emacsclientw is like emacsclient. If you don't pass --no-wait (or -n),
it *will* wait, so the message in Emacs' minibuffer is justified. If
you don't want the message, run emacsclient(w) with -n !

                    /L/e/k/t/u

Re: emacsclientw

[dhruva]

Hi,

On 11/13/06, Juanma Barranquero <lekktu@gmail.com> wrote:
> On 11/13/06, dhruva <dhruvakm@gmail.com> wrote:
>
> > Once I associate the file extensions to open
> > with emacsclientw, I do not want to keep getting the message in the
> > minibuffer area warning about clients...This did not happen with
> > gnuclientw.
>
> emacsclientw is like emacsclient. If you don't pass --no-wait (or -n),
> it *will* wait, so the message in Emacs' minibuffer is justified. If
> you don't want the message, run emacsclient(w) with -n !

I could do that if I run it from a shell or dos prompt. If I double
click on the explorer to open the file, I cannot pass that extra
parameter. When I open multiple files 9also through ctags), it can be
rather tiresome to keep pressing 'y' to all the messages. The default
key bound to "server-edit" requires 4 key strokes (C-x & S-5 to get #)
and can be cumbersome too (though I can write a small lisp function to
check if the buffer is from server and decide to call the
corresponding kill buffer).

Also, I am seeing a strange behavior. I associate a file extension
'.C' to run emacsclientw.exe. With no Emacs running, I double click on
a '.C' file from explorer. It launches Emacs (with the splash screen).
I go to the buffer containing the file I have opened and close it and
do not see any message in the minibuffer. I double click on another
'C' file and open it. When I close the second file, I get to see the
message. This seems inconsistent.

-dk

-- 
dhruva (dk)
Contents reflect my personal views only!

Re: emacsclientw

[Juanma Barranquero]

On 11/13/06, dhruva <dhruvakm@gmail.com> wrote:

> I could do that if I run it from a shell or dos prompt. If I double
> click on the explorer to open the file, I cannot pass that extra
> parameter.

Why not? How was the association to run Emacs created?

> When I open multiple files 9also through ctags), it can be
> rather tiresome to keep pressing 'y' to all the messages.

I think I don't follow you. What messages require you to answer 'y'?
Are you receiving messages about local variables?

> Also, I am seeing a strange behavior. I associate a file extension
> '.C' to run emacsclientw.exe. With no Emacs running, I double click on
> a '.C' file from explorer. It launches Emacs (with the splash screen).

That's only possible if you've defined ALTERNATE_EDITOR, or passing it
with -a to emacsclient.exe...

> I go to the buffer containing the file I have opened and close it and
> do not see any message in the minibuffer. I double click on another
> 'C' file and open it. When I close the second file, I get to see the
> message. This seems inconsistent.

If emacsclient.exe runs Emacs (through --alternate-editor or
ALTERNATE_EDITOR), Emacs does not necessarily start the server, and if
it does, it has no way to know the file passed on the command line
(which is what emacsclient does: run the alternate editor passing it
the rest of its command line) should be processed by server.el. In
fact, even if it did, the emacsclient.exe that started Emacs is no
longer running.

The second time, emacsclient.exe connects with the running server, so
it does wait indeed.

(In my opinion, if you're gonna use emacsclient that way, it is better
to have an always running instance of Emacs, but I digress.)

To do the "right" thing there, emacsclient should know how to run
Emacs as a subprocess, and specifically how to run it with server.el
active. I don't think that kind of intelligence belongs on
emacsclient.

The next best thing is doing what I'm doing now: instead of running
emacs.exe, or runemacs.exe, or emacsclient.exe, I run a .BAT script
which first tries to run emacsclient, and if it fails, starts emacs
and then retries emacsclient. Unfortunately my script runs on a
proprietary CMD replacement, and I haven't yet got the time to adapt
it to CMD. I will, with time.

                    /L/e/k/t/u

Re: emacsclientw

[Jason Rumney]

dhruva wrote:
> Also, I am seeing a strange behavior. I associate a file extension
> '.C' to run emacsclientw.exe. With no Emacs running, I double click on
> a '.C' file from explorer. It launches Emacs (with the splash screen).

That is strange indeed, since emacsclient does not launch Emacs in such 
circumstances, and emacsclientw is just emacsclient compiled with 
different options.

Re: emacsclientw

[Lennart Borgman]

Jason Rumney wrote:
> dhruva wrote:
>> Also, I am seeing a strange behavior. I associate a file extension
>> '.C' to run emacsclientw.exe. With no Emacs running, I double click on
>> a '.C' file from explorer. It launches Emacs (with the splash screen).
>
> That is strange indeed, since emacsclient does not launch Emacs in 
> such circumstances, and emacsclientw is just emacsclient compiled with 
> different options.

What does "assoc .c" and ftype of the result of assoc show?

Re: emacsclientw

[dhruva]

Hi,

On 11/14/06, Jason Rumney <jasonr@gnu.org> wrote:
> dhruva wrote:
> > Also, I am seeing a strange behavior. I associate a file extension
> > '.C' to run emacsclientw.exe. With no Emacs running, I double click on
> > a '.C' file from explorer. It launches Emacs (with the splash screen).
>
> That is strange indeed, since emacsclient does not launch Emacs in such
> circumstances, and emacsclientw is just emacsclient compiled with
> different options.

I just re-confirmed. "emacsclientw.exe" launches emacs if it is not
running. I have built the whole stuff using MSVC on WXP.

-dk

-- 
dhruva (dk)
Contents reflect my personal views only!

Re: emacsclientw

[Mathias Dahl]

> I just re-confirmed. "emacsclientw.exe" launches emacs if it is not
> running. I have built the whole stuff using MSVC on WXP.

Just the way I would like it. Reading the latest message gets me a bit
scared: one of the nice things with gnuserv/gnuclient/gnudoit on
Windows is that Emacs is started if it is not started already.
Splitting this into two different clients seems no good, IMHO. Trying
to get collegues to use Emacs is hard as it is, they barely accept
using gnuclient(w).exe (they wonder why they just cannot associate the
emacs exe directly with certain file types without getting multiple
copies running).

My 0.2 Euro.

Re: emacsclientw

[Jason Rumney]

Mathias Dahl wrote:
> (they wonder why they just cannot associate the
> emacs exe directly with certain file types without getting multiple
> copies running).

They can't do that with any other program either without knowing the 
internals of what DDE commands it uses, and setting them up in the 
association.

Re: emacsclientw

[Mathias Dahl]

> > (they wonder why they just cannot associate the
> > emacs exe directly with certain file types without getting multiple
> > copies running).
>
> They can't do that with any other program either without knowing the
> internals of what DDE commands it uses, and setting them up in the
> association.

I did not know that.

Re: emacsclientw

[Stuart D. Herring]

Not attempting to raise the dead (threads) here, but I realized I never
actually replied to this:

>> > (they wonder why they just cannot associate the
>> > emacs exe directly with certain file types without getting multiple
>> > copies running).
>>
>> They can't do that with any other program either without knowing the
>> internals of what DDE commands it uses, and setting them up in the
>> association.
>
> I did not know that.

It's not entirely true.  Explorer (the shell) is capable of remembering
DDE commands for a file type and executing them itself when the program is
already running, and many installers arrange for this to happen (because
it's too complicated to do manually).  (Obviously such an installer could
be developed for emacsclient, but it's also a valid goal to minimize the
complexity of installation.)

However, nothing prevents a program that is so-minded from detecting that
it is already running (this is particularly easy on Windows), executing a
DDE transaction with said established process that corresponds to its
command-line arguments, and then exiting.

Many if not most "professional" Windows programs do this, as their
monolithic (often MDI with a complicated GUI) design heavily favors having
precisely 0 or 1 copies running at any time.  Unfortunately, many of them
do this without providing any alternative behavior.

The emacsclient design is arguably better, where the decision between
communication and execution is made by a separate process with its own
customizable logic.  However, it is not true that Windows users will
automatically accept as reasonable the situation where said separate
program must be the one associated with their files, because the
automatic/monolithic behavior is so common.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: emacsclientw

[dhruva]

On 11/14/06, Mathias Dahl <mathias.dahl@gmail.com> wrote:
> > I just re-confirmed. "emacsclientw.exe" launches emacs if it is not
> > running. I have built the whole stuff using MSVC on WXP.
>
> Just the way I would like it. Reading the latest message gets me a bit
> scared: one of the nice things with gnuserv/gnuclient/gnudoit on
> Windows is that Emacs is started if it is not started already.
> Splitting this into two different clients seems no good, IMHO. Trying
> to get collegues to use Emacs is hard as it is, they barely accept
> using gnuclient(w).exe (they wonder why they just cannot associate the
> emacs exe directly with certain file types without getting multiple
> copies running).

I take back my words, I did a cvs update (now) and built emacs from
scratch (bootstrap). The resulting emacsclientw does not start emacs
if it is not running! I remember a quote by a fellow developer long
back when a nice feature that worked just stopped working "All good
things must come to an end sooner or later...."
I was very happy with the behavior except that I wanted an option to
set the "--no-wait" as default so that I will not be prompted by emacs
before killing every file visited using emacsclientw (or emacsclient).

The minibuffer prompt I get:
Buffer `_emacs' still has clients; kill it? (y or n)

-dk

-- 
dhruva (dk)
Contents reflect my personal views only!

Re: emacsclientw

[Jason Rumney]

dhruva wrote:
> I just re-confirmed. "emacsclientw.exe" launches emacs if it is not
> running. I have built the whole stuff using MSVC on WXP.

And emacsclientw does not create a command prompt window when you use it 
from the GUI? That is what I'm more interested in, as the -mwindows link 
option seems an elegant solution to the problem of superfluous command 
prompt windows, but it is not documented as being recognized by the 
microsoft linker, only by GNU ld.

Re: emacsclientw

[Lennart Borgman]

Jason Rumney wrote:
> Have you tested the emacsclientw.exe build with MSVC?
>
> I think there is also a need for something that starts Emacs if it is 
> not already running, so I came up with the following (based on 
> runemacs.c), which I intended to check into the nt directory. The 
> intention is to use this to associate Emacs with file types in 
> Explorer and other applications that allow external editors.

I like the idea but I think it will need some enhancement to take care 
of the --no-wait flag in the case when Emacs is not running from the 
beginning.

Actually I would prefer that this code made it into emacsclient. If it 
were it would be easier to take care of the --no-wait flag.

Another thing would like is to have emacsclient optionally request that 
emacs runs `server-start´ when starting emacs. Is not that much easier 
for new emacs users? Does not that also makes it easier to take care of 
the --server-file option? (I added the feature to start emacs to 
gnuclient on w32 before and it seems like users like it.)

Re: emacsclientw

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On 11/13/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Another thing would like is to have emacsclient optionally request that
> emacs runs `server-start´ when starting emacs. Is not that much easier
> for new emacs users? Does not that also makes it easier to take care of
> the --server-file option?

How do you propose to do that in a generic way? You'll have to add
environment variables or new args to allow customizing it. For
example, I don't run `server-start', but `server-mode', because the
later runs `server-mode-hook', which I need. How do you know how much
to wait before retrying emacsclient? (Depending on the size and
complexity of your .emacs, Emacs will delay from a few fractions of a
second to more than a few seconds before server.el is ready to process
incoming connections.) Will you pass to Emacs the server-name?

That's my only objection to what you propose: that emacsclient should
know nothing about how I do run my Emacs. So, if it doesn't, you'll
have to pass it somehow. So more args.

                    /L/e/k/t/u

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: emacsclientw

[Stefan Monnier]

>> Another thing would like is to have emacsclient optionally request that
>> emacs runs `server-start´ when starting emacs. Is not that much easier
>> for new emacs users? Does not that also makes it easier to take care of
>> the --server-file option?

> How do you propose to do that in a generic way? You'll have to add
> environment variables or new args to allow customizing it.

I don't see much problem here: just start Emacs with something like
"emacs <file> --eval (server-mode 1)".

> For example, I don't run `server-start', but `server-mode', because the
> later runs `server-mode-hook', which I need.

I consider `server-start' as a left over from the past.

> How do you know how much to wait before retrying emacsclient?

One way is to not wait: let this Emacs server handle the request
immediately, without going through emacsclient/server.  The server is only
started as a convenience for subsequent uses of emacsclient.

> Will you pass to Emacs the server-name?

We should, yes.


        Stefan

Re: emacsclientw

[Juanma Barranquero]

On 11/13/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I consider `server-start' as a left over from the past.

Well, as I've said, `server-mode-hook' is useful.

> One way is to not wait: let this Emacs server handle the request
> immediately, without going through emacsclient/server.  The server is only
> started as a convenience for subsequent uses of emacsclient.

And what if emacsclient was run from a tool that needs to wait for
Emacs (i.e., the user) to do something to the file and send it back?

                    /L/e/k/t/u

Re: emacsclientw

[Stefan Monnier]

>> I consider `server-start' as a left over from the past.
> Well, as I've said, `server-mode-hook' is useful.

So we're in violent agreement, aren't we?

>> One way is to not wait: let this Emacs server handle the request
>> immediately, without going through emacsclient/server.  The server is only
>> started as a convenience for subsequent uses of emacsclient.
> And what if emacsclient was run from a tool that needs to wait for
> Emacs (i.e., the user) to do something to the file and send it back?

Hmm... good point.  Well, then we can start the server, then wait for some
signal that it's ready, then start emacsclient.  Nothing insurmountable,


        Stefan

Re: emacsclientw

[Lennart Borgman]

Stefan Monnier wrote:
>> And what if emacsclient was run from a tool that needs to wait for
>> Emacs (i.e., the user) to do something to the file and send it back?
>>     
>
> Hmm... good point.  Well, then we can start the server, then wait for some
> signal that it's ready, then start emacsclient.  Nothing insurmountable,
>   

I have been coding this today, but had some problems recompiling at the 
moment. Coming back.

Re: emacsclientw

[Juanma Barranquero]

On 11/13/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> So we're in violent agreement, aren't we?

Yes, sorry. I somehow read it as if you had said that `server-mode'
was a leftover, not `server-start'.

> Hmm... good point.  Well, then we can start the server, then wait for some
> signal that it's ready, then start emacsclient.  Nothing insurmountable,

Yeah, but I don't think that belongs to emacsclient. I think that
should be another application; perhaps the "launch emacs" app that
Jason has started.

                    /L/e/k/t/u

Re: emacsclientw

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/13/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> So we're in violent agreement, aren't we?
>
> Yes, sorry. I somehow read it as if you had said that `server-mode'
> was a leftover, not `server-start'.
>
>> Hmm... good point.  Well, then we can start the server, then wait for 
>> some
>> signal that it's ready, then start emacsclient.  Nothing insurmountable,
>
> Yeah, but I don't think that belongs to emacsclient. I think that
> should be another application; perhaps the "launch emacs" app that
> Jason has started.
>
>                    /L/e/k/t/u

I think it will be just a few lines in emacsclient.c. Though I am unsure 
about some details ... - if setup of a network socket fails, is it then 
ok to try again later? I mean I assume that the socket setup failed 
because there was no emacs server running. Can those cases be recognized?

Re: emacsclientw

[Juanma Barranquero]

On 11/13/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> Though I am unsure
> about some details ... - if setup of a network socket fails, is it then
> ok to try again later? I mean I assume that the socket setup failed
> because there was no emacs server running. Can those cases be recognized?

That's one of the reasons I don't like this. emacsclient is based upon
the idea that you try to connect to Emacs, and if you can't, you just
run the alternate editor. Now, you're going to be forced to
distinguish between running the alternate editor, and running Emacs,
because they should be treated in two very different ways, and have
all sort of configuration options for the case that you run Emacs.
Unless you're thinking of getting rid of --alternate-editor, which
wouldn't be a good idea.

It would be far easier, I think, to have a second program (let's call
it launchemacs) that does:

  1) Run Emacs and wait until Emacs is running the server. The program
should have options to start Emacs the way the user wants (either a
config file, command line options, environmente variables, whatever)
  2) Once the seerver is running, execvp emacsclient(w?).exe with the
original arguments passed to launchemacs.

The trick is that then you can do

  emacsclient --alternate-editor=launchemacs myfile.txt

and you don't have to modify emacsclient *at all*.

                    /L/e/k/t/u

Re: emacsclientw

[Lennart Borgman]

Juanma Barranquero wrote:
> On 11/13/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
>> Though I am unsure
>> about some details ... - if setup of a network socket fails, is it then
>> ok to try again later? I mean I assume that the socket setup failed
>> because there was no emacs server running. Can those cases be 
>> recognized?
>
> That's one of the reasons I don't like this. emacsclient is based upon
> the idea that you try to connect to Emacs, and if you can't, you just
> run the alternate editor. Now, you're going to be forced to
> distinguish between running the alternate editor, and running Emacs,
> because they should be treated in two very different ways, and have
> all sort of configuration options for the case that you run Emacs.
> Unless you're thinking of getting rid of --alternate-editor, which
> wouldn't be a good idea.
>
> It would be far easier, I think, to have a second program (let's call
> it launchemacs) that does:
>
>  1) Run Emacs and wait until Emacs is running the server. The program
> should have options to start Emacs the way the user wants (either a
> config file, command line options, environmente variables, whatever)
>  2) Once the seerver is running, execvp emacsclient(w?).exe with the
> original arguments passed to launchemacs.
>
> The trick is that then you can do
>
>  emacsclient --alternate-editor=launchemacs myfile.txt
>
> and you don't have to modify emacsclient *at all*.

My idea is a little, little bit different. Keep --alternative-editor. 
Add a new option --start-timeout=[seconds]. If this new option is given 
then wait max that many seconds for emacs server to be available after 
launching --alternative-editor.

Let the default for --alternative-editor be "emacs" (or "runemacs" on 
w32). With full path taken from emacsclient path.

Doing it this way no second program is needed and it is (I hope) easy to 
wait for emacs server.

Re: emacsclientw

[Jason Rumney]

Juanma Barranquero wrote:
> Yeah, but I don't think that belongs to emacsclient. I think that
> should be another application; perhaps the "launch emacs" app that
> Jason has started.
Actually, I think the functionality I was trying to provide is covered 
by ALTERNATE_EDITOR and emacsclientw.exe, so I don't see any point in my 
extra app any more. The solution is probably to improve the 
ALTERNATE_EDITOR handling to recognise Emacs as a special case, or at 
least delay exit until the spawned editor is done.

Re: emacsclientw

[Eli Zaretskii]

> Date: Mon, 13 Nov 2006 15:11:38 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> 
> Actually I would prefer that this code made it into emacsclient.

Is it a good idea?  What if I want to run an $EDITOR from a console
program?  In that case, usually the program should wait for Emacs to
finish editing before it continues.  I think your suggestion would
cause the invoking program to continue without waiting.

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:

> I'm using the cygwin tools to make mingw build. Nothing weird about it.

You're using the cygwin gcc compiler to do the mingw build, you mean?

I build with the MinGW compiler and it works like a charm.

                    /L/e/k/t/u

Re: I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Juanma Barranquero skrev:
> On 11/12/06, Eric Lilja <mindcooler@gmail.com> wrote:
> 
>> I'm using the cygwin tools to make mingw build. Nothing weird about it.
> 
> You're using the cygwin gcc compiler to do the mingw build, you mean?
> 
> I build with the MinGW compiler and it works like a charm.
> 
>                    /L/e/k/t/u

The only pure mingw tool I have installed is the mingw version of gnu 
make. Since I can put cygwins gcc compiler in mingw mode I see no reason 
to install mingws gcc. The steps I described in my OP are more or less 
the same I have used for two years now. And now it wont work, possibly 
due to how make is told to build emacsclient.c?

/ E

Re: I can't build from cvs sources on cygwin for some time now

[Juanma Barranquero]

On 11/13/06, Eric Lilja <mindcooler@gmail.com> wrote:

> The steps I described in my OP are more or less
> the same I have used for two years now. And now it wont work, possibly
> due to how make is told to build emacsclient.c?

Possibly.

But you're the one that can really research what's happening and
propose a fix. I have no cygwin environment in my computer.

                    /L/e/k/t/u

Re: I can't build from cvs sources on cygwin for some time now

[Eric Lilja]

Eric Lilja skrev:
[snip original problem report]

Thank you Jason and Juanma! With your changes, I was able to 
successfully bootstrap emacs.

Now I can start with trying to solve my problems using emacs. :-)

/ Eric