* Emacs 21.3.50.1 (CVS sources) tex-mode bug
@ 2005-01-16 18:44 Chip Coldwell
2005-01-16 19:51 ` Chip Coldwell
0 siblings, 1 reply; 4+ messages in thread
From: Chip Coldwell @ 2005-01-16 18:44 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 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 tried the following trivial program
(setq subshell (make-comint "subshell" "/bin/bash"))
(switch-to-buffer subshell)
And it does indeed create a subshell in a buffer, but the shell never
issues a prompt string. Setting the PS1 environment variable has no
effect in this buffer, for reasons I haven't figured out yet.
Chip
--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Emacs 21.3.50.1 (CVS sources) tex-mode bug
2005-01-16 18:44 Emacs 21.3.50.1 (CVS sources) tex-mode bug Chip Coldwell
@ 2005-01-16 19:51 ` Chip Coldwell
2005-01-16 20:37 ` Andreas Schwab
0 siblings, 1 reply; 4+ messages in thread
From: Chip Coldwell @ 2005-01-16 19:51 UTC (permalink / raw)
I discovered that the sub shell will prompt correctly if invoked as an
interactive shell. I wonder if Apple has been tinkering with how
bash(1) behaves (or perhaps someone at FSF?). I suppose it is
arguably the right thing to do (i.e. not to prompt if not
interactive). Here's a tiny patch that fixes my problem (although it
could create problems for others):
--- 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)
Chip
--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
On Sun, 16 Jan 2005, Chip Coldwell wrote:
>
> 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 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 tried the following trivial program
>
> (setq subshell (make-comint "subshell" "/bin/bash"))
> (switch-to-buffer subshell)
>
> And it does indeed create a subshell in a buffer, but the shell never
> issues a prompt string. Setting the PS1 environment variable has no
> effect in this buffer, for reasons I haven't figured out yet.
>
> Chip
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Emacs 21.3.50.1 (CVS sources) tex-mode bug
2005-01-16 19:51 ` Chip Coldwell
@ 2005-01-16 20:37 ` Andreas Schwab
2005-01-17 23:42 ` Richard Stallman
0 siblings, 1 reply; 4+ messages in thread
From: Andreas Schwab @ 2005-01-16 20:37 UTC (permalink / raw)
Cc: bug-gnu-emacs
Chip Coldwell <coldwell@frank.harvard.edu> writes:
> I discovered that the sub shell will prompt correctly if invoked as an
> interactive shell. I wonder if Apple has been tinkering with how
> bash(1) behaves (or perhaps someone at FSF?).
The shell only starts interactively when input is connected to a (pseudo)
terminal. On MacOS ptys are buggy, so pipes are used instead (see
process-connection-type).
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-01-17 23:42 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-16 18:44 Emacs 21.3.50.1 (CVS sources) tex-mode bug Chip Coldwell
2005-01-16 19:51 ` Chip Coldwell
2005-01-16 20:37 ` Andreas Schwab
2005-01-17 23:42 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).