all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
@ 2005-01-17  0:34 Chip Coldwell
  2005-01-17 16:08 ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Chip Coldwell @ 2005-01-17  0:34 UTC (permalink / raw)



I realize that I should expect problems if I choose to live on the
bleeding edge, but I figure I might as well report this problem just
in case the developers aren't already aware of it.

The problem is with Emacs 21.3.50.1 that I checked out from CVS
sources and compiled using the emacs/mac/make-package shell script on
the Macintosh OS X (10.3.7).  If I am editing in tex-mode and I run
the function 'tex-file' (by default bound to C-c C-f) emacs goes into
an infinite loop.  The loop is in the function 
lisp/tex-mode.el:tex-start-shell

(defun tex-start-shell ()
   (with-current-buffer
       (make-comint
        "tex-shell"
        (or tex-shell-file-name (getenv "ESHELL") shell-file-name)
        nil)
     (let ((proc (get-process "tex-shell")))
       (set-process-sentinel proc 'tex-shell-sentinel)
       (set-process-query-on-exit-flag proc nil)
       (tex-shell)
       (while (zerop (buffer-size))
 	(sleep-for 1)))))

The function creates a shell using "make-comint", then waits for the
shell to start in the loop at the bottom.  Presumably, when the shell
has started, it will issue a prompt and the (buffer-size) procedure
will return non-zero and break out of the loop.  The problem is that
it never does.

I am informed by Andreas Schwab that ptys are broken on Mac OS X, and 
therefore process-connection-type is set to nil so instead of allocating a 
pseudo-terminal to communicate with the sub-process emacs uses a pipe.
The shell discovers that its not connected to a terminal and runs as 
non-interactive, suppressing the prompts and causing the infinite loop I 
describe above.

My proposed solution is a tiny patch:

--- emacs/lisp/textmodes/tex-mode.el.~1.153.~   Sat Dec 11 17:00:38 2004
+++ emacs/lisp/textmodes/tex-mode.el    Sun Jan 16 13:59:50 2005
@@ -1495,7 +1495,8 @@
        (make-comint
         "tex-shell"
         (or tex-shell-file-name (getenv "ESHELL") shell-file-name)
-       nil)
+       nil
+       "-i")
      (let ((proc (get-process "tex-shell")))
        (set-process-sentinel proc 'tex-shell-sentinel)
        (set-process-query-on-exit-flag proc nil)

This adds the "-i" switch to the command line that exec's the shell, 
causing it to run interactively.

I have tested this on Mac OS X and it did solve the problem.  A very 
similar "-i" switch appears in lisp/shell.el ("M-x shell").

Chip

-- 
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-17  0:34 Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug Chip Coldwell
@ 2005-01-17 16:08 ` Stefan Monnier
  2005-01-17 17:41   ` Steven Tamm
  2005-01-19  0:49   ` Richard Stallman
  0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2005-01-17 16:08 UTC (permalink / raw)
  Cc: emacs-devel

> The function creates a shell using "make-comint", then waits for the
> shell to start in the loop at the bottom.  Presumably, when the shell
> has started, it will issue a prompt and the (buffer-size) procedure
> will return non-zero and break out of the loop.  The problem is that
> it never does.

> I am informed by Andreas Schwab that ptys are broken on Mac OS X, and
> therefore process-connection-type is set to nil so instead of allocating
> a pseudo-terminal to communicate with the sub-process emacs uses a pipe.
> The shell discovers that its not connected to a terminal and runs as
> non-interactive, suppressing the prompts and causing the infinite loop
> I describe above.

AFAIK the "broken tty" issue was solved a while back (somewhere around 10.3)
and I thought we had reverted process-connection-type's default to t.
But indeed I see in lisp/term/mac-win.el that we still set
process-connection-type to nil.  Shouldn't we remove it, or at least make it
depend on the OS's version?

> --- emacs/lisp/textmodes/tex-mode.el.~1.153.~   Sat Dec 11 17:00:38 2004
> +++ emacs/lisp/textmodes/tex-mode.el    Sun Jan 16 13:59:50 2005
> @@ -1495,7 +1495,8 @@
>         (make-comint
>          "tex-shell"
>          (or tex-shell-file-name (getenv "ESHELL") shell-file-name)
> -       nil)
> +       nil
> +       "-i")
>       (let ((proc (get-process "tex-shell")))
>         (set-process-sentinel proc 'tex-shell-sentinel)
>         (set-process-query-on-exit-flag proc nil)

> This adds the "-i" switch to the command line that exec's the shell, causing
> it to run interactively.

> I have tested this on Mac OS X and it did solve the problem.  A very similar
> "-i" switch appears in lisp/shell.el ("M-x shell").

Indeed, shell uses the same trick.  So I guess it's OK to do it in tex-shell
as well.  If anybody wants to install that patch, please do it for me.


        Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-17 16:08 ` Stefan Monnier
@ 2005-01-17 17:41   ` Steven Tamm
  2005-01-17 18:59     ` Stefan Monnier
  2005-01-19  0:49   ` Richard Stallman
  1 sibling, 1 reply; 13+ messages in thread
From: Steven Tamm @ 2005-01-17 17:41 UTC (permalink / raw)
  Cc: Chip Coldwell, emacs-devel

I checked in this fix.  It seemed like the right thing to do regardless.

As for pty's, there were still some issues with the last few characters 
of a process being eaten.  I can't seem reproduce it now as easily as 
before, so maybe it was actually solved.  If there's a consensus, I can 
switch it back.

Index: lisp/term/mac-win.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/term/mac-win.el,v
retrieving revision 1.30
diff -u -d -b -w -r1.30 mac-win.el
--- lisp/term/mac-win.el        30 Dec 2004 02:04:31 -0000      1.30
+++ lisp/term/mac-win.el        17 Jan 2005 17:40:12 -0000
@@ -1696,8 +1696,9 @@

  ;; Tell Emacs to use pipes instead of pty's for processes because the
  ;; latter sometimes lose characters.  Pty support is compiled in since
-;; ange-ftp will not work without it.
-(setq process-connection-type nil)
+;; ange-ftp will not work without it.  Fixed with darwin 7 (OS X 10.3).
+(setq process-connection-type
+      (not (string-match "-darwin[0-6]\\." system-configuration)))

  ;; Assume that fonts are always scalable on the Mac.  This sometimes
  ;; results in characters with jagged edges.  However, without it,


-Steven


On Jan 17, 2005, at 8:08 AM, Stefan Monnier wrote:

>> The function creates a shell using "make-comint", then waits for the
>> shell to start in the loop at the bottom.  Presumably, when the shell
>> has started, it will issue a prompt and the (buffer-size) procedure
>> will return non-zero and break out of the loop.  The problem is that
>> it never does.
>
>> I am informed by Andreas Schwab that ptys are broken on Mac OS X, and
>> therefore process-connection-type is set to nil so instead of 
>> allocating
>> a pseudo-terminal to communicate with the sub-process emacs uses a 
>> pipe.
>> The shell discovers that its not connected to a terminal and runs as
>> non-interactive, suppressing the prompts and causing the infinite loop
>> I describe above.
>
> AFAIK the "broken tty" issue was solved a while back (somewhere around 
> 10.3)
> and I thought we had reverted process-connection-type's default to t.
> But indeed I see in lisp/term/mac-win.el that we still set
> process-connection-type to nil.  Shouldn't we remove it, or at least 
> make it
> depend on the OS's version?
>
>> --- emacs/lisp/textmodes/tex-mode.el.~1.153.~   Sat Dec 11 17:00:38 
>> 2004
>> +++ emacs/lisp/textmodes/tex-mode.el    Sun Jan 16 13:59:50 2005
>> @@ -1495,7 +1495,8 @@
>>         (make-comint
>>          "tex-shell"
>>          (or tex-shell-file-name (getenv "ESHELL") shell-file-name)
>> -       nil)
>> +       nil
>> +       "-i")
>>       (let ((proc (get-process "tex-shell")))
>>         (set-process-sentinel proc 'tex-shell-sentinel)
>>         (set-process-query-on-exit-flag proc nil)
>
>> This adds the "-i" switch to the command line that exec's the shell, 
>> causing
>> it to run interactively.
>
>> I have tested this on Mac OS X and it did solve the problem.  A very 
>> similar
>> "-i" switch appears in lisp/shell.el ("M-x shell").
>
> Indeed, shell uses the same trick.  So I guess it's OK to do it in 
> tex-shell
> as well.  If anybody wants to install that patch, please do it for me.
>
>
>         Stefan
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-17 17:41   ` Steven Tamm
@ 2005-01-17 18:59     ` Stefan Monnier
  2005-01-18  4:08       ` Steven Tamm
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2005-01-17 18:59 UTC (permalink / raw)
  Cc: Chip Coldwell, emacs-devel

> --- lisp/term/mac-win.el        30 Dec 2004 02:04:31 -0000      1.30
> +++ lisp/term/mac-win.el        17 Jan 2005 17:40:12 -0000
> @@ -1696,8 +1696,9 @@

>   ;; Tell Emacs to use pipes instead of pty's for processes because the
>   ;; latter sometimes lose characters.  Pty support is compiled in since
> -;; ange-ftp will not work without it.
> -(setq process-connection-type nil)
> +;; ange-ftp will not work without it.  Fixed with darwin 7 (OS X 10.3).
> +(setq process-connection-type
> +      (not (string-match "-darwin[0-6]\\." system-configuration)))

>   ;; Assume that fonts are always scalable on the Mac.  This sometimes
>   ;; results in characters with jagged edges.  However, without it,

BTW, I think I've never noticed the tex-shell problem on my Mac because
I build it for X11 so mac-win.el is not loaded (and thus
process-connection-type stays t).

Shouldn't the process-connection-type be set somewhere else than in
mac-win.el.


        Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-17 18:59     ` Stefan Monnier
@ 2005-01-18  4:08       ` Steven Tamm
  2005-01-18 11:14         ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 13+ messages in thread
From: Steven Tamm @ 2005-01-18  4:08 UTC (permalink / raw)
  Cc: YAMAMOTO Mitsuharu, emacs-devel '

The problem only applied to the carbon build, I believe.  The pty's 
weren't setup correctly when launching from a bundle.  My recollection 
is fuzzy, so it could be something else.

-Steven

On Jan 17, 2005, at 10:59 AM, Stefan Monnier wrote:

>> --- lisp/term/mac-win.el        30 Dec 2004 02:04:31 -0000      1.30
>> +++ lisp/term/mac-win.el        17 Jan 2005 17:40:12 -0000
>> @@ -1696,8 +1696,9 @@
>
>>   ;; Tell Emacs to use pipes instead of pty's for processes because 
>> the
>>   ;; latter sometimes lose characters.  Pty support is compiled in 
>> since
>> -;; ange-ftp will not work without it.
>> -(setq process-connection-type nil)
>> +;; ange-ftp will not work without it.  Fixed with darwin 7 (OS X 
>> 10.3).
>> +(setq process-connection-type
>> +      (not (string-match "-darwin[0-6]\\." system-configuration)))
>
>>   ;; Assume that fonts are always scalable on the Mac.  This sometimes
>>   ;; results in characters with jagged edges.  However, without it,
>
> BTW, I think I've never noticed the tex-shell problem on my Mac because
> I build it for X11 so mac-win.el is not loaded (and thus
> process-connection-type stays t).
>
> Shouldn't the process-connection-type be set somewhere else than in
> mac-win.el.
>
>
>         Stefan

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-18  4:08       ` Steven Tamm
@ 2005-01-18 11:14         ` YAMAMOTO Mitsuharu
  2005-01-18 17:31           ` Steven Tamm
  2005-02-25  6:19           ` YAMAMOTO Mitsuharu
  0 siblings, 2 replies; 13+ messages in thread
From: YAMAMOTO Mitsuharu @ 2005-01-18 11:14 UTC (permalink / raw)
  Cc: Stefan Monnier, emacs-devel

>>>>> On Mon, 17 Jan 2005 20:08:50 -0800, Steven Tamm <steventamm@mac.com> said:

> The problem only applied to the carbon build, I believe.  The pty's
> weren't setup correctly when launching from a bundle.  My
> recollection is fuzzy, so it could be something else.

How about this?  I used uname(3) because the variable
system-configuration corresponds to the build environment, not the
execution environment.

I guess Darwin x86 also has the same kind of problem.  Does anyone
know about that?  Should we define and use DARWIN instead of MAC_OSX?

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

Index: lisp/term/mac-win.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/term/mac-win.el,v
retrieving revision 1.30
diff -c -r1.30 mac-win.el
*** lisp/term/mac-win.el	30 Dec 2004 02:04:31 -0000	1.30
--- lisp/term/mac-win.el	18 Jan 2005 10:43:11 -0000
***************
*** 1694,1704 ****
  (if (string= default-directory "/")
      (cd "~"))
  
- ;; Tell Emacs to use pipes instead of pty's for processes because the
- ;; latter sometimes lose characters.  Pty support is compiled in since
- ;; ange-ftp will not work without it.
- (setq process-connection-type nil)
- 
  ;; Assume that fonts are always scalable on the Mac.  This sometimes
  ;; results in characters with jagged edges.  However, without it,
  ;; fonts with both truetype and bitmap representations but no italic
--- 1692,1697 ----
Index: src/process.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/process.c,v
retrieving revision 1.447
diff -c -r1.447 process.c
*** src/process.c	27 Dec 2004 16:06:43 -0000	1.447
--- src/process.c	18 Jan 2005 10:43:12 -0000
***************
*** 117,122 ****
--- 117,126 ----
  #include <sys/wait.h>
  #endif
  
+ #ifdef MAC_OSX
+ #include <sys/utsname.h>
+ #endif
+ 
  #include "systime.h"
  #include "systty.h"
  
***************
*** 6632,6637 ****
--- 6636,6656 ----
  
    return 0;
  }
+ 
+ #ifdef MAC_OSX
+ /* Return the major release number of Darwin.  */
+ 
+ static int
+ darwin_major_release ()
+ {
+   struct utsname uts;
+ 
+   if (uname (&uts) == 0)
+     return atoi (uts.release);
+   else
+     return -1;
+ }
+ #endif
  \f
  void
  init_process ()
***************
*** 6704,6709 ****
--- 6723,6733 ----
     Fprovide (intern ("make-network-process"), subfeatures);
   }
  #endif /* HAVE_SOCKETS */
+ #ifdef MAC_OSX
+   /* Darwin version < 7 has a problem in pty handling.  */
+   if (darwin_major_release () < 7)
+     Vprocess_connection_type = Qnil;
+ #endif
  }
  
  void

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-18 11:14         ` YAMAMOTO Mitsuharu
@ 2005-01-18 17:31           ` Steven Tamm
  2005-02-25  6:19           ` YAMAMOTO Mitsuharu
  1 sibling, 0 replies; 13+ messages in thread
From: Steven Tamm @ 2005-01-18 17:31 UTC (permalink / raw)
  Cc: Stefan Monnier, emacs-devel

Darn.  I forgot that 10.2 and 10.3 are still binary compatible (unlike 
10.1).  Are pty's still broken on 10.2.8?  In any case it makes sense 
to have it be #ifdef DARWIN.

I'd also suggest that we have a "darwin-kernel-release" variable 
defined only with system-type darwin and place it someplace like 
sysdep.c or editfns.c.  Should this, perhaps be a built-in variable 
across all *nix platforms?  Something similar to 
get_emacs_configuration in w32.c?

-Steven

On Jan 18, 2005, at 3:14 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Mon, 17 Jan 2005 20:08:50 -0800, Steven Tamm 
>>>>>> <steventamm@mac.com> said:
>
>> The problem only applied to the carbon build, I believe.  The pty's
>> weren't setup correctly when launching from a bundle.  My
>> recollection is fuzzy, so it could be something else.
>
> How about this?  I used uname(3) because the variable
> system-configuration corresponds to the build environment, not the
> execution environment.
>
> I guess Darwin x86 also has the same kind of problem.  Does anyone
> know about that?  Should we define and use DARWIN instead of MAC_OSX?
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
>
> Index: lisp/term/mac-win.el
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/lisp/term/mac-win.el,v
> retrieving revision 1.30
> diff -c -r1.30 mac-win.el
> *** lisp/term/mac-win.el	30 Dec 2004 02:04:31 -0000	1.30
> --- lisp/term/mac-win.el	18 Jan 2005 10:43:11 -0000
> ***************
> *** 1694,1704 ****
>   (if (string= default-directory "/")
>       (cd "~"))
>
> - ;; Tell Emacs to use pipes instead of pty's for processes because the
> - ;; latter sometimes lose characters.  Pty support is compiled in 
> since
> - ;; ange-ftp will not work without it.
> - (setq process-connection-type nil)
> -
>   ;; Assume that fonts are always scalable on the Mac.  This sometimes
>   ;; results in characters with jagged edges.  However, without it,
>   ;; fonts with both truetype and bitmap representations but no italic
> --- 1692,1697 ----
> Index: src/process.c
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/src/process.c,v
> retrieving revision 1.447
> diff -c -r1.447 process.c
> *** src/process.c	27 Dec 2004 16:06:43 -0000	1.447
> --- src/process.c	18 Jan 2005 10:43:12 -0000
> ***************
> *** 117,122 ****
> --- 117,126 ----
>   #include <sys/wait.h>
>   #endif
>
> + #ifdef MAC_OSX
> + #include <sys/utsname.h>
> + #endif
> +
>   #include "systime.h"
>   #include "systty.h"
>
> ***************
> *** 6632,6637 ****
> --- 6636,6656 ----
>
>     return 0;
>   }
> +
> + #ifdef MAC_OSX
> + /* Return the major release number of Darwin.  */
> +
> + static int
> + darwin_major_release ()
> + {
> +   struct utsname uts;
> +
> +   if (uname (&uts) == 0)
> +     return atoi (uts.release);
> +   else
> +     return -1;
> + }
> + #endif
>   \f
>   void
>   init_process ()
> ***************
> *** 6704,6709 ****
> --- 6723,6733 ----
>      Fprovide (intern ("make-network-process"), subfeatures);
>    }
>   #endif /* HAVE_SOCKETS */
> + #ifdef MAC_OSX
> +   /* Darwin version < 7 has a problem in pty handling.  */
> +   if (darwin_major_release () < 7)
> +     Vprocess_connection_type = Qnil;
> + #endif
>   }
>
>   void
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-17 16:08 ` Stefan Monnier
  2005-01-17 17:41   ` Steven Tamm
@ 2005-01-19  0:49   ` Richard Stallman
  2005-01-19 19:16     ` Steven Tamm
  1 sibling, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2005-01-19  0:49 UTC (permalink / raw)
  Cc: coldwell, emacs-devel

    But indeed I see in lisp/term/mac-win.el that we still set
    process-connection-type to nil.  Shouldn't we remove it, or at least make it
    depend on the OS's version?

If ptys work, Emacs ought to use them (in the cases where it normally
does use them).

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-19  0:49   ` Richard Stallman
@ 2005-01-19 19:16     ` Steven Tamm
  2005-01-20 21:32       ` Richard Stallman
  2005-01-21  6:20       ` Nozomu Ando
  0 siblings, 2 replies; 13+ messages in thread
From: Steven Tamm @ 2005-01-19 19:16 UTC (permalink / raw)
  Cc: coldwell, Stefan Monnier, emacs-devel

I added a new variable called operating-system-release (to editfns.c) 
that returns the string that would be returned "uname -r" on systems 
with sys/utsname defined.

I changed mac-win.el to use ptys on darwin 7 and higher (i.e. OSX 10.3) 
based on this variable.  Since builds on 10.2 and 10.3 are binary 
compatible (unlike 10.1) this is the only way to tell the difference.

-Steven

On Jan 18, 2005, at 4:49 PM, Richard Stallman wrote:

>     But indeed I see in lisp/term/mac-win.el that we still set
>     process-connection-type to nil.  Shouldn't we remove it, or at 
> least make it
>     depend on the OS's version?
>
> If ptys work, Emacs ought to use them (in the cases where it normally
> does use them).
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-19 19:16     ` Steven Tamm
@ 2005-01-20 21:32       ` Richard Stallman
  2005-01-21  6:20       ` Nozomu Ando
  1 sibling, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2005-01-20 21:32 UTC (permalink / raw)
  Cc: coldwell, monnier, emacs-devel

    I added a new variable called operating-system-release (to editfns.c) 
    that returns the string that would be returned "uname -r" on systems 
    with sys/utsname defined.

That seems useful.  Although it's a new feature, it internal and safe
and needed to fix a bug, so it is ok.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-19 19:16     ` Steven Tamm
  2005-01-20 21:32       ` Richard Stallman
@ 2005-01-21  6:20       ` Nozomu Ando
  2005-01-21 19:40         ` Steven Tamm
  1 sibling, 1 reply; 13+ messages in thread
From: Nozomu Ando @ 2005-01-21  6:20 UTC (permalink / raw)
  Cc: emacs-devel


Steven Tamm <steventamm@mac.com> writes:
> I changed mac-win.el to use ptys on darwin 7 and higher (i.e. OSX
> 10.3) based on this variable.

If my understanding is correct, we cannot use ptys at all on darwin 6
or below now?

Ptys on darwin 6 have the problem of data loss at the end of the stream,
but they are still useful for interactive subprocesses, such as M-x shell.

Moreover, we can fix the kernel of darwin 6 becuase its source is available.

Could you please re-consider the last change and make it user's selectable
that emacs should use ptys or not by setting process-connection-type ?
---
Nozomu Ando

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-21  6:20       ` Nozomu Ando
@ 2005-01-21 19:40         ` Steven Tamm
  0 siblings, 0 replies; 13+ messages in thread
From: Steven Tamm @ 2005-01-21 19:40 UTC (permalink / raw)
  Cc: emacs-devel

Your understanding is correct.  However I had seen data loss even with 
interactive processes, although the data was always useless.

Perhaps it would be better to have process-connection-type default to 
nil with darwin 6, but allow the user to override it if they know what 
they are doing?
Something like this.

Index: src/process.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/process.c,v
retrieving revision 1.447
diff -u -d -b -w -r1.447 process.c
--- src/process.c       27 Dec 2004 16:06:43 -0000      1.447
+++ src/process.c       21 Jan 2005 19:38:57 -0000
@@ -187,6 +187,7 @@
  #include "syswait.h"

  extern void set_waiting_for_input P_ ((EMACS_TIME *));
+extern char *get_operating_system_release ();

  #ifndef USE_CRT_DLL
  extern int errno;
@@ -6704,6 +6705,19 @@
     Fprovide (intern ("make-network-process"), subfeatures);
   }
  #endif /* HAVE_SOCKETS */
+
+#ifdef DARWIN
+  /* PTYs are broken on Darwin < 6, but are sometimes useful for 
interactive
+     processes.  As such, we only change the default value.  */
+ if (initialized)
+  {
+    char *release = get_operating_system_release();
+    if (!release || !release[0] || (release[0] < MIN_PTY_KERNEL_VERSION
+                                   && release[1] == '.')) {
+      Vprocess_connection_type = Qnil;
+    }
+  }
+#endif
  }

  void
Index: src/s/darwin.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/s/darwin.h,v
retrieving revision 1.19
diff -u -d -b -w -r1.19 darwin.h
--- src/s/darwin.h      20 Jan 2005 18:13:48 -0000      1.19
+++ src/s/darwin.h      21 Jan 2005 19:38:59 -0000
@@ -37,6 +37,10 @@
  #define BSD_SYSTEM
  /* #define VMS */

+#ifndef        DARWIN
+#define        DARWIN 1
+#endif
+
  /* MAC_OS is used to conditionally compile code common to both MAC_OS8
     and MAC_OSX.  */
  #ifdef MAC_OSX
@@ -103,25 +107,17 @@

  /*
   *     Define HAVE_PTYS if the system supports pty devices.
+ *      Note: PTYs are broken on darwin <6.  Use at your own risk.
   */

  #define HAVE_PTYS

-
-/*
- * PTYs only work correctly on Darwin 7 or higher.  So make 
PTY_ITERATION
- * Test the operating system release and only allow PTYs if it is 
greater
- * than 7.
+/**
+ * PTYs only work correctly on Darwin 7 or higher.  So make the
+ * default for process-connection-type dependent on the kernel
+ * version.
   */
  #define MIN_PTY_KERNEL_VERSION '7'
-#define PTY_ITERATION  \
-  char *release = get_operating_system_release();      \
-  if (!release || !release[0] || (release[0] < MIN_PTY_KERNEL_VERSION \
-                                 && release[1] == '.'))              \
-    return -1; \
-  for (c = FIRST_PTY_LETTER; c <= 'z'; c++)    \
-    for (i = 0; i < 16; i++)
-

  /*
   *     Define NONSYSTEM_DIR_LIBRARY to make Emacs emulate


-Steven

On Jan 20, 2005, at 10:20 PM, Nozomu Ando wrote:

>
> Steven Tamm <steventamm@mac.com> writes:
>> I changed mac-win.el to use ptys on darwin 7 and higher (i.e. OSX
>> 10.3) based on this variable.
>
> If my understanding is correct, we cannot use ptys at all on darwin 6
> or below now?
>
> Ptys on darwin 6 have the problem of data loss at the end of the 
> stream,
> but they are still useful for interactive subprocesses, such as M-x 
> shell.
>
> Moreover, we can fix the kernel of darwin 6 becuase its source is 
> available.
>
> Could you please re-consider the last change and make it user's 
> selectable
> that emacs should use ptys or not by setting process-connection-type ?
> ---
> Nozomu Ando
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug
  2005-01-18 11:14         ` YAMAMOTO Mitsuharu
  2005-01-18 17:31           ` Steven Tamm
@ 2005-02-25  6:19           ` YAMAMOTO Mitsuharu
  1 sibling, 0 replies; 13+ messages in thread
From: YAMAMOTO Mitsuharu @ 2005-02-25  6:19 UTC (permalink / raw)
  Cc: Stefan Monnier, emacs-devel

>>>>> On Tue, 18 Jan 2005 20:14:23 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I guess Darwin x86 also has the same kind of problem.  Does anyone
> know about that?  Should we define and use DARWIN instead of
> MAC_OSX?

Sorry.  The macro DARWIN is already used in some system headers to
distinguish Mac OS X from bare Darwin.  (For example, see
/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h)
So we should not define this on Mac OS X.

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2005-02-25  6:19 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-17  0:34 Emacs 21.3.50.1 (CVS sources) MacOS X tex-mode bug Chip Coldwell
2005-01-17 16:08 ` Stefan Monnier
2005-01-17 17:41   ` Steven Tamm
2005-01-17 18:59     ` Stefan Monnier
2005-01-18  4:08       ` Steven Tamm
2005-01-18 11:14         ` YAMAMOTO Mitsuharu
2005-01-18 17:31           ` Steven Tamm
2005-02-25  6:19           ` YAMAMOTO Mitsuharu
2005-01-19  0:49   ` Richard Stallman
2005-01-19 19:16     ` Steven Tamm
2005-01-20 21:32       ` Richard Stallman
2005-01-21  6:20       ` Nozomu Ando
2005-01-21 19:40         ` Steven Tamm

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.