Character mode for comint?

Character mode for comint?

[Antoine Levitt]

Hi,

Is there any way to get a kind of shell-like "character-mode" for comint
buffers? Ie something that'd pass litteral keypresses to the underlying
app. Specifically, I'm interested in running ipython, which basically
uses readline. That'd allow me to use tab, C-r, that kind of stuff.

Antoine

Re: Character mode for comint?

[Andreas Schwab]

See terminal-emulator.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Character mode for comint?

[Antoine Levitt]

29/10/11 11:29, Andreas Schwab
> See terminal-emulator.
>
> Andreas.

I should have been more clear: I'm looking for something that'd allow me
to toggle between the "normal" operation mode and a character-based
one. Just like C-c C-j and C-c C-k in shell-mode.

Re: Character mode for comint?

[Andreas Schwab]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> Just like C-c C-j and C-c C-k in shell-mode.

What do they do?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Character mode for comint?

[Antoine Levitt]

29/10/11 12:37, Andreas Schwab
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> Just like C-c C-j and C-c C-k in shell-mode.
>
> What do they do?
>
> Andreas.

They switch between a character- and line-based input. In character
mode, every key is passed directly to the underlying shell, and line
mode, input is buffered and only sent on RET. This disables the usual
readline features such as TAB, C-r and the like. Comint only has "line
mode", I was wondering if there was a simple way to have a
character-mode input.

Re: Character mode for comint?

[Andreas Schwab]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> 29/10/11 12:37, Andreas Schwab
>> Antoine Levitt <antoine.levitt@gmail.com> writes:
>>
>>> Just like C-c C-j and C-c C-k in shell-mode.
>>
>> What do they do?
>>
>> Andreas.
>
> They switch between a character- and line-based input.

I don't see any such functionality in shell-mode.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Character mode for comint?

[Antoine Levitt]

29/10/11 13:50, Andreas Schwab
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> 29/10/11 12:37, Andreas Schwab
>>> Antoine Levitt <antoine.levitt@gmail.com> writes:
>>>
>>>> Just like C-c C-j and C-c C-k in shell-mode.
>>>
>>> What do they do?
>>>
>>> Andreas.
>>
>> They switch between a character- and line-based input.
>
> I don't see any such functionality in shell-mode.
>
> Andreas.

Apologizes, I was talking about term-mode.

Re: Character mode for comint?

[Andreas Schwab]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> Apologizes, I was talking about term-mode.

So what's wrong with it?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Character mode for comint?

[Antoine Levitt]

29/10/11 14:17, Andreas Schwab
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> Apologizes, I was talking about term-mode.
>
> So what's wrong with it?
>
> Andreas.

Right, so, from the top.

In term-mode, I can switch between line-mode and character-mode via C-c
C-j, C-c C-k. In comint buffers (for instance: emacs -Q, M-x
run-python), there is only the default line-based input mode. I'd like
to be able to input characters directly. Is there a simple way that
could be done?

Antoine

Re: Character mode for comint?

[Andreas Schwab]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> In term-mode, I can switch between line-mode and character-mode via C-c
> C-j, C-c C-k. In comint buffers (for instance: emacs -Q, M-x
> run-python), there is only the default line-based input mode. I'd like
> to be able to input characters directly. Is there a simple way that
> could be done?

What's wrong with using term-mode in the first place?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Character mode for comint?

[Antoine Levitt]

29/10/11 17:15, Andreas Schwab
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> In term-mode, I can switch between line-mode and character-mode via C-c
>> C-j, C-c C-k. In comint buffers (for instance: emacs -Q, M-x
>> run-python), there is only the default line-based input mode. I'd like
>> to be able to input characters directly. Is there a simple way that
>> could be done?
>
> What's wrong with using term-mode in the first place?
>
> Andreas.

Because then you don't benefit from the emacs interaction features of
the various python modes, like sending the current
buffer/region/defun. If your question is "why are these features
implemented with comint rather than term-mode", I have no clue.

Re: Character mode for comint?

[Andreas Schwab]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> Because then you don't benefit from the emacs interaction features of
> the various python modes, like sending the current
> buffer/region/defun. If your question is "why are these features
> implemented with comint rather than term-mode", I have no clue.

Because you need to have control over the input in order to do that.
You cannot have them when the underlying process is doing the input
editing.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Character mode for comint?

[Stephen J. Turnbull]

Antoine Levitt writes:

 > Because then you don't benefit from the emacs interaction features of
 > the various python modes, like sending the current
 > buffer/region/defun. If your question is "why are these features
 > implemented with comint rather than term-mode", I have no clue.

Here's a clue:

;;; term.el --- general command interpreter in a window stuff

;; Copyright (C) 1988-1995, 1997 Free Software Foundation, Inc.

;; Author: Per Bothner <bothner@cygnus.com>
;; Based on comint mode written by: Olin Shivers <shivers@cs.cmu.edu>

So comint can do it, and term-mode can teach you how to tickle comint
mode into doing what you want it to do.  If you're very lucky, your
investigation of term-mode may show that this is a feature of comint
itself and you just have to enable it.

I-got-no-fish-today-but-here's-a-rod-and-reel-ly y'rs,

Re: Character mode for comint?

[Stefan Monnier]

> Is there any way to get a kind of shell-like "character-mode" for comint
> buffers? Ie something that'd pass litteral keypresses to the underlying
> app. Specifically, I'm interested in running ipython, which basically
> uses readline. That'd allow me to use tab, C-r, that kind of stuff.

I think you're asking for a better integration between term-mode and
comint-mode.  Agreed.  Please M-x report-emacs-bug requesting this as
a new feature.


        Stefan

Re: Character mode for comint?

[Antoine Levitt]

29/10/11 18:17, Andreas Schwab
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> Because then you don't benefit from the emacs interaction features of
>> the various python modes, like sending the current
>> buffer/region/defun. If your question is "why are these features
>> implemented with comint rather than term-mode", I have no clue.
>
> Because you need to have control over the input in order to do that.
> You cannot have them when the underlying process is doing the input
> editing.
>
> Andreas.

Why not? You can certainly send stuff to a terminal by just copy/pasting
it and that works fine.

Re: Character mode for comint?

[Antoine Levitt]

29/10/11 18:35, Stephen J. Turnbull
> Antoine Levitt writes:
>
>  > Because then you don't benefit from the emacs interaction features of
>  > the various python modes, like sending the current
>  > buffer/region/defun. If your question is "why are these features
>  > implemented with comint rather than term-mode", I have no clue.
>
> Here's a clue:
>
> ;;; term.el --- general command interpreter in a window stuff
>
> ;; Copyright (C) 1988-1995, 1997 Free Software Foundation, Inc.
>
> ;; Author: Per Bothner <bothner@cygnus.com>
> ;; Based on comint mode written by: Olin Shivers <shivers@cs.cmu.edu>
>
> So comint can do it, and term-mode can teach you how to tickle comint
> mode into doing what you want it to do.  If you're very lucky, your
> investigation of term-mode may show that this is a feature of comint
> itself and you just have to enable it.

Actually, the basic code seems to be pretty simple. In character mode,
pretty much everything is mapped to term-send-raw, which is just a
wrapper around process-send-string. But what's more complex is the fact
that ipython (for instance) reacts to special strings (for instance,
tab, C-p, C-p ...) in a more complex way than just outputting something,
which comint doesn't seem to understand. In the end, that's probably the
difference between an input/output interface like comint and a real
terminal emulator like term. So the solution (for what I want to do
anyway) might be to run python inside term, and rewrite the shell
interaction code to send to term instead of comint.

Re: Character mode for comint?

[Stefan Monnier]

> Actually, the basic code seems to be pretty simple. In character mode,
> pretty much everything is mapped to term-send-raw, which is just a
> wrapper around process-send-string.

Indeed.  In inferior-prolog-mode, for example we mix the two in some
occasions (because some Prolog systems read a single char (rather than
a string) to decide how to continue).


        Stefan

Re: Character mode for comint?

[Antoine Levitt]

29/10/11 18:36, Stefan Monnier
>> Is there any way to get a kind of shell-like "character-mode" for comint
>> buffers? Ie something that'd pass litteral keypresses to the underlying
>> app. Specifically, I'm interested in running ipython, which basically
>> uses readline. That'd allow me to use tab, C-r, that kind of stuff.
>
> I think you're asking for a better integration between term-mode and
> comint-mode.  Agreed.  Please M-x report-emacs-bug requesting this as
> a new feature.

I think the whole shell situation on emacs is a can of worms. There's
term, ansi-term, nterm, multi-term, shell, comint, each with specific
caveats and gotchas. I've reported this as you asked, but I'm not very
hopeful that someone will take it on :)

Re: Character mode for comint?

[Stephen J. Turnbull]

Antoine Levitt writes:

 > I think the whole shell situation on emacs is a can of worms. There's
 > term, ansi-term, nterm, multi-term, shell, comint, each with specific
 > caveats and gotchas.

No, there's just comint, (most of?) the rest are layered on top of it.

The plan is pretty obvious: move features from the various
higher-level (user-level) interfaces into comint.  This can probably
done ad hoc as you need features (but you need to test with everything
that matches `grep -E "(require 'comint)"' before pushing).

In python-mode, though, Emacs provides a powerful history mechanism
for comint.  While it's true that Python users will be familiar with
the readline interface, Emacs users shouldn't have too much trouble
with switching to the Emacs bindings (and if they don't like that,
they may as well remap Emacs bindings since it's fundamentally more
powerful).

Re: Character mode for comint?

[Stephen J. Turnbull]

Stephen J. Turnbull writes:

 > that matches `grep -E "(require 'comint)"' before pushing).

Oops, I meant "grep -F", of course.