emacsclient 22 and 23 incompatibility

emacsclient 22 and 23 incompatibility

[David Reitter]

Is there a way to make Emacs 23 compatible with the 22-series  
emacsclient?

It's a pity that this doesn't work out-of-the-box, given that not all  
platforms use an install procedure that will update a centrally  
installed emacsclient program along with the new Emacs main  
application. 

Re: emacsclient 22 and 23 incompatibility

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> Is there a way to make Emacs 23 compatible with the 22-series
> emacsclient?

Don't think so.

> It's a pity that this doesn't work out-of-the-box, given that not all
> platforms use an install procedure that will update a centrally
> installed emacsclient program along with the new Emacs main
> application.

All platforms supported by Emacs do AFAICT.  If there are install
procedures outside of the control of the Emacs maintainers which don't
do the right thing, I don't see why it would be a good idea to bend over
backwards to support them.

-- 
David Kastrup

Re: emacsclient 22 and 23 incompatibility

[David Reitter]

On Aug 1, 2009, at 12:55 PM, David Kastrup wrote:
>> It's a pity that this doesn't work out-of-the-box, given that not all
>> platforms use an install procedure that will update a centrally
>> installed emacsclient program along with the new Emacs main
>> application.
>
> All platforms supported by Emacs do AFAICT.  If there are install
> procedures outside of the control of the Emacs maintainers which don't
> do the right thing, I don't see why it would be a good idea to bend  
> over
> backwards to support them.

Oh, I must have been missing out on something.  Could you please  
explain how the Nextstep port does that?

According to what I know:
"make install" installs a .app in the nextstep folder, which is then  
supposed to be moved by the user wherever they want on their file  
system.  The emacsclient binary is inside the .app and not copied to  
anywhere in PATH.   That is why the existing 22 emacsclient binary  
(which is in PATH) stays in place and gets called by other  
applications such as "Skim" in order to communicate with Emacs, which  
fails.

Re: emacsclient 22 and 23 incompatibility

[Christian Lynbech]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

David> That is why the existing 22 emacsclient binary (which is in PATH)
David> stays in place

But how did the emacs 22 client get into PATH?

Obviously, if one is mixing distributions such as fink or macports with
a new emacs 23 app, trouble could be expected.

For instance CarbonEmacs.app has its emacsclient in 

    /Applications/CarbonEmacs.app/Contents/MacOS/bin/

which isn't automatically copied to typical PATH places. I could then be
lucky to have installed something which did put a compatible emacsclient
into my PATH, but I would consider that more as an accident than a
conscious action of some .app.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: emacsclient 22 and 23 incompatibility

[CHENG Gao]

A solution is to install a command line only version of Emacs 23.1 to
repalce 22.1.1 in MacOSX.

The plan I have is to 

1. Install a command line only version to /usr/local

2. Install Cocoa port building with:
./configure --with-ns --disable-ns-self-contained

This way /usr/local/share/emacs/site-lisp can be used by two
installations.

It's useful when installing some Emacs packages. Without a command line
Emacs 23, Emacs 22 in /usr/bin is often choosen if you forget to use:

./configre --with-emacs=/Applications/Emacs.app/Contents/MacOS/Emacs

That can mean a lot of trouble.

I have not installed command line version yet, but I plan to.


BTW, I have a question.

Apple's original installation of emacs 22 has (in /usr/bin):

,----
| -r-xr-xr-x  1 root  wheel     38544  2  6  2008 emacs
| -rwxr-xr-x  1 root  wheel  13072480 12 17  2008 emacs-i386
| -rwxr-xr-x  1 root  wheel   5301856 11 25  2008 emacs-undumped
`----
Does this mean:
the first emacs is dumped? How could it be so small?


Please pay attention to size of three files.

My build of Emacs 23.1 has:
,----
| -rwxr-xr-x  2 chenggao  staff  8916252  8  2 03:51 emacs
| -rwxr-xr-x  2 chenggao  staff  8916252  7 31 15:31 emacs-23.1.1
| -rwxr-xr-x  2 chenggao  staff  8916252  8  2 03:51 emacs-23.1.2
`----

emacs-23.1.2 is made with 
,----
| temacs -batch -l loadup dump
`----
while I try to dump emacs (since I think original build is undumped).


So this means while installing, emacs is dumped. Where is the undumped
emacs?


-- 
Homo sum, humani being nil a me alienum puto

Re: emacsclient 22 and 23 incompatibility

[Ken Raeburn]

On Aug 1, 2009, at 15:58, CHENG Gao wrote:
> Apple's original installation of emacs 22 has (in /usr/bin):
>
> ,----
> | -r-xr-xr-x  1 root  wheel     38544  2  6  2008 emacs
> | -rwxr-xr-x  1 root  wheel  13072480 12 17  2008 emacs-i386
> | -rwxr-xr-x  1 root  wheel   5301856 11 25  2008 emacs-undumped
> `----
> Does this mean:
> the first emacs is dumped? How could it be so small?

% strings emacs
/usr/libexec/dumpemacs
Failed to dump emacs
/usr/bin/emacs-i386
execv(%s) failed
[...]

So I'm thinking Apple's "emacs" program doesn't come out of the normal  
GNU Emacs build process (or sources) at all, but does its own thing,  
which may involved dumping after installation.  If the dumped version  
is available as emacs-i386, then Apple's "emacs" will run it.  (If you  
fire up emacs and run "ps", you'll see the process listed as "emacs",  
but if you run "lsof" on it, you'll see the text image comes from  
emacs-i386.)

% file emacs-undumped emacs-i386
emacs-undumped: Mach-O universal binary with 2 architectures
emacs-undumped (for architecture i386):	Mach-O executable i386
emacs-undumped (for architecture ppc7400):	Mach-O executable ppc
emacs-i386:     Mach-O executable i386
%

So "emacs-undumped" is probably a "universal" binary version of src/ 
temacs, which normally would never be installed, and "emacs-i386" is  
probably the dumped version, with only the native architecture  
support.  Though, how it could still be so much larger than both the  
pre-dumped version (divided roughly in half, remember, for the i386  
portion only) and the emacs-23 binaries you built, I don't know.

Ken

Re: emacsclient 22 and 23 incompatibility

[CHENG Gao]

*On Sat, 1 Aug 2009 18:18:56 -0400
* Also sprach Ken Raeburn <raeburn@raeburn.org>:

> On Aug 1, 2009, at 15:58, CHENG Gao wrote:
>> Apple's original installation of emacs 22 has (in /usr/bin):
>>
>> ,----
>> | -r-xr-xr-x  1 root  wheel     38544  2  6  2008 emacs
>> | -rwxr-xr-x  1 root  wheel  13072480 12 17  2008 emacs-i386
>> | -rwxr-xr-x  1 root  wheel   5301856 11 25  2008 emacs-undumped
>> `----
>> Does this mean:
>> the first emacs is dumped? How could it be so small?
>
> % strings emacs
> /usr/libexec/dumpemacs
> Failed to dump emacs
> /usr/bin/emacs-i386
> execv(%s) failed
> [...]
>
> So I'm thinking Apple's "emacs" program doesn't come out of the normal
> GNU Emacs build process (or sources) at all, but does its own thing,
> which may involved dumping after installation.  If the dumped version
> is available as emacs-i386, then Apple's "emacs" will run it.  (If you
> fire up emacs and run "ps", you'll see the process listed as "emacs",
> but if you run "lsof" on it, you'll see the text image comes from
> emacs-i386.)
>
> % file emacs-undumped emacs-i386
> emacs-undumped: Mach-O universal binary with 2 architectures
> emacs-undumped (for architecture i386):	Mach-O executable i386
> emacs-undumped (for architecture ppc7400):	Mach-O executable ppc
> emacs-i386:     Mach-O executable i386
> %
>
> So "emacs-undumped" is probably a "universal" binary version of src/
> temacs, which normally would never be installed, and "emacs-i386" is
> probably the dumped version, with only the native architecture
> support.  Though, how it could still be so much larger than both the
> pre-dumped version (divided roughly in half, remember, for the i386
> portion only) and the emacs-23 binaries you built, I don't know.
>
> Ken

Thank you very much for your explanation. 



-- 
The truth which makes men free is for the most part the truth which men prefer not to hear.

Re: emacsclient 22 and 23 incompatibility

[David Reitter]

Emacs 22 (TTY) comes with OS X by default.
Also, if users upgrade to Emacs 23 from the "sudo make install" based  
22 to 23, then this may happen (haven't tested though) and then this  
is definitely our omission.

Even a warning in emacsclient would have gone a long way.


On Aug 1, 2009, at 21:18, Christian Lynbech <christian@defun.dk> wrote:

>>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:
>
> David> That is why the existing 22 emacsclient binary (which is in  
> PATH)
> David> stays in place
>
> But how did the emacs 22 client get into PATH?
>
> Obviously, if one is mixing distributions such as fink or macports  
> with
> a new emacs 23 app, trouble could be expected.
>
> For instance CarbonEmacs.app has its emacsclient in
>
>    /Applications/CarbonEmacs.app/Contents/MacOS/bin/
>
> which isn't automatically copied to typical PATH places. I could  
> then be
> lucky to have installed something which did put a compatible  
> emacsclient
> into my PATH, but I would consider that more as an accident than a
> conscious action of some .app.
>
>
> ------------------------ 
> +-----------------------------------------------------
> Christian Lynbech       | christian #\@ defun #\. dk
> ------------------------ 
> +-----------------------------------------------------
> Hit the philistines three times over the head with the Elisp  
> reference manual.
>                                        - petonic@hal.com (Michael A.  
> Petonic)
>
>
>
>
>
>
>

Re: emacsclient 22 and 23 incompatibility

[Leo]

On 2009-08-02 20:24 +0100, David Reitter wrote:
> Emacs 22 (TTY) comes with OS X by default.
> Also, if users upgrade to Emacs 23 from the "sudo make install" based
> 22 to 23, then this may happen (haven't tested though) and then this
> is definitely our omission.
>
> Even a warning in emacsclient would have gone a long way.

Maybe apple should be encouraged to upgrade their packaged GNU software
more often. For example, if they upgrade to 23.1 in their Snow leopard
product due next month, this problem will go away for a while.

-- 
Leo's Emacs uptime: 1 day, 22 hours, 18 minutes, 38 seconds

Re: emacsclient 22 and 23 incompatibility

[Vagn Johansen]

Leo <sdl.web@gmail.com> writes:

> On 2009-08-02 20:24 +0100, David Reitter wrote:
>> Emacs 22 (TTY) comes with OS X by default.
>> Also, if users upgrade to Emacs 23 from the "sudo make install" based
>> 22 to 23, then this may happen (haven't tested though) and then this
>> is definitely our omission.
>>
>> Even a warning in emacsclient would have gone a long way.
>
> Maybe apple should be encouraged to upgrade their packaged GNU software
> more often. For example, if they upgrade to 23.1 in their Snow leopard
> product due next month, this problem will go away for a while.

23.1 is very buggy on OS X, at least on 10.4. It would be a very bad
idea if they did this.

I have had several crashes. Also with "emacs -Q" I cannot enter '\' and
'|' on a danish keyboard.

-- 
Vagn Johansen

Re: emacsclient 22 and 23 incompatibility

[Leo]

On 2009-08-03 08:29 +0100, Vagn Johansen wrote:
> 23.1 is very buggy on OS X, at least on 10.4. It would be a very bad
> idea if they did this.
>
> I have had several crashes. Also with "emacs -Q" I cannot enter '\'
> and '|' on a danish keyboard.

Do you know if this happens with emacs compiled with no gui toolkit? I
would expect it to be nearly equivalent to that of GNU/Linux, no?

-- 
Leo's Emacs uptime: 2 days, 10 hours, 39 minutes, 7 seconds

Re: emacsclient 22 and 23 incompatibility

[Vagn Johansen]

Leo <sdl.web@gmail.com> writes:

> On 2009-08-03 08:29 +0100, Vagn Johansen wrote:
>> 23.1 is very buggy on OS X, at least on 10.4. It would be a very bad
>> idea if they did this.
>>
>> I have had several crashes. Also with "emacs -Q" I cannot enter '\'
>> and '|' on a danish keyboard.
>
> Do you know if this happens with emacs compiled with no gui toolkit? 

Is that a possibility on OS X?

I run

   ./configure --with-ns --prefix=..

> I would expect it to be nearly equivalent to that of GNU/Linux, no?

If you mean "emacs -nw" I have only tried it for about 5 minutes. It
has some redrawing problems when run in the Terminal application: top
menu bar partially drawn and also doing a C-x C-f will sometimes not
show the "Find file:" text. 

If I launch XDarwin and run "emacs -nw -Q" in an xterm then he
redrawing works properly.

-- 
Vagn Johansen

Re: emacsclient 22 and 23 incompatibility

[Ian Eure]

On Aug 3, 2009, at 8:14 AM, Vagn Johansen wrote:

> Leo <sdl.web@gmail.com> writes:
>
>> On 2009-08-03 08:29 +0100, Vagn Johansen wrote:
>>> 23.1 is very buggy on OS X, at least on 10.4. It would be a very bad
>>> idea if they did this.
>>>
>>> I have had several crashes. Also with "emacs -Q" I cannot enter '\'
>>> and '|' on a danish keyboard.
>>
>> Do you know if this happens with emacs compiled with no gui toolkit?
>
> Is that a possibility on OS X?
>
> I run
>
>   ./configure --with-ns --prefix=..
>
You want:

./configure --without-ns


>> I would expect it to be nearly equivalent to that of GNU/Linux, no?
>
> If you mean "emacs -nw" I have only tried it for about 5 minutes. It
> has some redrawing problems when run in the Terminal application: top
> menu bar partially drawn and also doing a C-x C-f will sometimes not
> show the "Find file:" text.
>
I don't use it regularly, but I haven't seen any obvious problems with  
Emacs 23.1 (or the last six months of CVS) running in a terminal on OS  
X. Using `emacsclient -t' with a server running on NS also works fine  
for me. I definitely can't reproduce the drawing issues you mention.

  - Ian

Re: emacsclient 22 and 23 incompatibility

[Christoph Conrad]

Hi Vagn,

> 23.1 is very buggy on OS X, at least on 10.4.

The precompiled windows version i downloaded from an official german GNU
mirror also had a lot of problems (windows xp), first crashed with old
bytecompiled files, then other very odd behaviours, all trackable down
to loading old bytecompiled files. After recompiling all used .el files
it worked aside from randomly stopping emacs to react to any user input
for seconds, even Ctrl-g does not work. So i switched back to emacs 22
after three hours of searching for a workaround.

The GNU/Linux version on kubuntu 9.04: Downloaded tar ball, compile,
install, everything works out of the box. My GNU/Linux emacs is equally
heavily configured as the windows version.

Regards,
Christoph

Re: emacsclient 22 and 23 incompatibility

[Leo]

On 2009-08-03 11:15 +0100, Christoph Conrad wrote:
> After recompiling all used .el files it worked aside from randomly
> stopping emacs to react to any user input for seconds, even Ctrl-g
> does not work.

This happens to me when Gnus is trying to connect to servers while one
of them is not responding. I find the fact that C-g could not interrupt
it rather annoying.

-- 
Leo's Emacs uptime: 2 days, 11 hours, 43 minutes, 3 seconds

Re: emacsclient 22 and 23 incompatibility

[Christoph Conrad]

Hi Leo,

> This happens to me when Gnus is trying to connect to servers while one
> of them is not responding. I find the fact that C-g could not
> interrupt it rather annoying.

Yes, but with exactly the same configuration this effect occurs only
with Emacs 23.1, not with Emacs 22.3.

Regards,
Christoph

Re: emacsclient 22 and 23 incompatibility

[Leo]

On 2009-08-03 13:47 +0100, Christoph Conrad wrote:
>> This happens to me when Gnus is trying to connect to servers while
>> one of them is not responding. I find the fact that C-g could not
>> interrupt it rather annoying.
>
> Yes, but with exactly the same configuration this effect occurs only
> with Emacs 23.1, not with Emacs 22.3.

I have never used emacs 22.x. This seems like a regression. Could you
generate a bug report on this?

-- 
Leo's Emacs uptime: 2 days, 14 hours, 9 minutes, 22 seconds

Re: emacsclient 22 and 23 incompatibility

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 03 Aug 2009 14:47:41 +0200, Christoph Conrad <conrad@surgitaix.com> said:

>> This happens to me when Gnus is trying to connect to servers while
>> one of them is not responding. I find the fact that C-g could not
>> interrupt it rather annoying.

> Yes, but with exactly the same configuration this effect occurs only
> with Emacs 23.1, not with Emacs 22.3.

That sounds like the case where we want some `immediate_quit'
replacement when SYNC_INPUT is defined.

http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01283.html

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: emacsclient 22 and 23 incompatibility

[Stefan Monnier]

>>> This happens to me when Gnus is trying to connect to servers while
>>> one of them is not responding. I find the fact that C-g could not
>>> interrupt it rather annoying.

>> Yes, but with exactly the same configuration this effect occurs only
>> with Emacs 23.1, not with Emacs 22.3.

> That sounds like the case where we want some `immediate_quit'
> replacement when SYNC_INPUT is defined.

> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01283.html

Indeed,


        Stefan

Re: emacsclient 22 and 23 incompatibility

[Gilaras Drakeson]

Hi,

>>> It's a pity that this doesn't work out-of-the-box, given that not all
>>> platforms use an install procedure that will update a centrally
>>> installed emacsclient program along with the new Emacs main
>>> application.
>>
>> All platforms supported by Emacs do AFAICT.  If there are install
>> procedures outside of the control of the Emacs maintainers which don't
>> do the right thing, I don't see why it would be a good idea to bend
>> over
>> backwards to support them.
>
> Oh, I must have been missing out on something.  Could you please
> explain how the Nextstep port does that?
>
> According to what I know:
> "make install" installs a .app in the nextstep folder, which is then
> supposed to be moved by the user wherever they want on their file
> system.  The emacsclient binary is inside the .app and not copied to
> anywhere in PATH.   That is why the existing 22 emacsclient binary
> (which is in PATH) stays in place and gets called by other
> applications such as "Skim" in order to communicate with Emacs, which
> fails.

Regarding Mac OS 10.5.*,
It's a pity that /usr/libexec/path_helper does not do exactly what it
says in the commentary at the top of it. If you fix it [1], you can
actually decide what goes in PATH (and MANPATH), and in which order.

--
Gilaras

[1] patch for /usr/libexec/path_helper at the bottom of this message,
patch /etc/paths.d according to something like this:
  $ ls -l /etc/paths.d
  total 48
  -rw-r--r--   1 root  wheel    31 Apr 15 20:28 30-port
  -rw-r--r--   1 root  wheel    82 Apr 15 21:04 31-emacs
  lrwxr-xr-x   1 root  wheel    10 Apr 15 21:19 50-default -> /etc/paths
  -rwxr-xr-x   1 root  wheel    12 Nov  5  2008 70-TeX
  -rw-r--r--   1 root  wheel    13 Dec  5  2007 71-X11
  -rw-r--r--   1 root  wheel    50 Apr 15 21:05 72-inkscape
also patch /etc/manpaths.d to look like:
  $ ls -l /etc/manpaths.d
  total 32
  -rw-r--r--  1 root  wheel  15 Apr 15 20:27 30-port
  lrwxr-xr-x  1 root  wheel  13 Apr 15 21:20 50-default -> /etc/manpaths
  -rwxr-xr-x  1 root  wheel  52 Nov  5  2008 70-TeX
  -rw-r--r--  1 root  wheel  13 Dec  5  2007 71-X11

patch for /usr/libexec/path_helper:
diff:
--- path_helper.old	2009-08-01 16:09:25.000000000 -0400
+++ path_helper.new	2009-08-01 16:10:00.000000000 -0400
@@ -1,8 +1,10 @@
 #!/bin/sh
 #
-# Each line of the text files in /etc/paths are directories that should be
-# added to the current path.  We source /etc/paths/default first, so that
-# the default paths (/usr/bin:/bin:/usr/sbin:/sbin) appear early in the path.
+# Each line of the text files in /etc/paths.d are directories that
+# should be added to the current path. The text files are read in
+# lexical order, and the default file is /etc/paths.d/50-default.  
+# We source /etc/paths.d/50-default first, so that the default paths
+# (/usr/bin:/bin:/usr/sbin:/sbin) appear early in the path.
 #
 
 shopt -s extglob
@@ -11,8 +13,8 @@
 NEWPATH="$2"
 SEP=""
 IFS=$'\n'
-if [ -d "$DIR".d ]; then
-	for f in "$DIR" "$DIR".d/* ; do
+if [ -d "$DIR" ]; then
+	for f in "$DIR"/* ; do
 	  if [ -f "$f" ]; then
 		for p in $(< "$f") ; do
 			[[ "$NEWPATH" = *(*:)${p}*(:*) ]] && continue
@@ -25,8 +27,8 @@
 echo $NEWPATH
 }
 
-P=`read_path_dir /etc/paths "$PATH"`
-MP=`read_path_dir /etc/manpaths "$MANPATH"`
+P=`read_path_dir /etc/paths.d`
+MP=`read_path_dir /etc/manpaths.d`
 
 if [ "$1" == "-c" -o \( -z "$1" -a "${SHELL%csh}" != "$SHELL" \) ]; then
 	echo setenv PATH \"$P\"\;