shell mode - how to stop division into bogus fields

shell mode - how to stop division into bogus fields

[Silvio Levy]

[Better version of a message I tried to send a few minutes ago]

So, starting with Emacs 21 (if I recall correctly) the behavior of
shell mode changed so that it's become much harder to reuse previous
commands.  For instance, suppose you have run the command 

myprompt> foo bar

In the old behavior, if you went back to that line, edited it, and hit
return, the whole line would be fed to the shell, except for myprompt>.

In the new behavior, most kinds of editing break up the line into
bogus "fields". For instance, suppose you realize you forgot an
argument, and you supply it from the kill-ring. You now have

myprompt> foo baz bar

(where "baz" was dropped in via C-y). Now, if hit return with point on
top of "baz", only "bar" is sent - somehow, emacs regards "baz" as a
prompt and what comes after as the desired command. (If point is on
"bar", likewise) only "bar" is sent.

In effect the line has been chopped into multiple logical lines, and
that causes many errors.

I've spent quite a bit of time searching for documentation about this,
without success. The file comint.el talks about fields but I see a
variable to turn off this behavior. And worse, it looks like such
documentation as there is, is wrong. For instance,

 http://www.gnu.org/s/libtool/manual/emacs/Shell-Prompts.html

says that "when point is in input on the same line as a prompt, C-a
puts point at the beginning of the input if comint-use-prompt-regexp
is nil and at the beginning of the line otherwise." 

In fact, for me (under emacs 23.1.1, called with -q, and having hit
M-x shell which opens my default shell, csh), C-a always puts point at
the beginning of the "piece" it's on, regardless of the value of
comint-use-prompt-regexp.

Can anyone teach me how the old behavior can be restored?

Thanks in advance

Silvio Levy
levy@msri.org

Re: shell mode - how to stop division into bogus fields

[XeCycle]

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

Silvio Levy <levy@msri.org> writes:

[...]

> In the old behavior, if you went back to that line, edited it, and hit
> return, the whole line would be fed to the shell, except for myprompt>.
>
> In the new behavior, most kinds of editing break up the line into
> bogus "fields". For instance, suppose you realize you forgot an
> argument, and you supply it from the kill-ring. You now have
>
> myprompt> foo baz bar
>
> (where "baz" was dropped in via C-y). Now, if hit return with point on
> top of "baz", only "bar" is sent - somehow, emacs regards "baz" as a
> prompt and what comes after as the desired command. (If point is on
> "bar", likewise) only "bar" is sent.

Cannot reproduce your problem.

> In effect the line has been chopped into multiple logical lines, and
> that causes many errors.
>
> I've spent quite a bit of time searching for documentation about this,
> without success. The file comint.el talks about fields but I see a
> variable to turn off this behavior. And worse, it looks like such
> documentation as there is, is wrong. For instance,
>
>  http://www.gnu.org/s/libtool/manual/emacs/Shell-Prompts.html
>
> says that "when point is in input on the same line as a prompt, C-a
> puts point at the beginning of the input if comint-use-prompt-regexp
> is nil and at the beginning of the line otherwise." 
>
> In fact, for me (under emacs 23.1.1, called with -q, and having hit
> M-x shell which opens my default shell, csh), C-a always puts point at
> the beginning of the "piece" it's on, regardless of the value of
> comint-use-prompt-regexp.

Cannot reproduce this, either.  I'm using GNU Emacs 24.0.91.2
(x86_64-unknown-linux-gnu, GTK+ Version 2.24.8) of 2011-11-19.
You can also try `-Q', to see if your distro or local admin broke
it.

-- 
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: shell mode - how to stop division into bogus fields

[Bob Proulx]

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

XeCycle wrote:
> Silvio Levy writes:
> > In the old behavior, if you went back to that line, edited it, and hit
> > return, the whole line would be fed to the shell, except for myprompt>.
> >
> > In the new behavior, most kinds of editing break up the line into
> > bogus "fields". For instance, suppose you realize you forgot an
> > argument, and you supply it from the kill-ring. You now have
> >
> > myprompt> foo baz bar
> >
> > (where "baz" was dropped in via C-y). Now, if hit return with point on
> > top of "baz", only "bar" is sent - somehow, emacs regards "baz" as a
> > prompt and what comes after as the desired command. (If point is on
> > "bar", likewise) only "bar" is sent.
> 
> Cannot reproduce your problem.

I can reproduce it.  It annoyed me too.  I see this same problem on
emacs 23.3.1 from Debian Sid using emacs -Q.

I have no solution for it however.

> > says that "when point is in input on the same line as a prompt, C-a
> > puts point at the beginning of the input if comint-use-prompt-regexp
> > is nil and at the beginning of the line otherwise." 
> >
> > In fact, for me (under emacs 23.1.1, called with -q, and having hit
> > M-x shell which opens my default shell, csh), C-a always puts point at
> > the beginning of the "piece" it's on, regardless of the value of
> > comint-use-prompt-regexp.
> 
> Cannot reproduce this, either.  I'm using GNU Emacs 24.0.91.2
> (x86_64-unknown-linux-gnu, GTK+ Version 2.24.8) of 2011-11-19.
> You can also try `-Q', to see if your distro or local admin broke
> it.

I have different behavior of C-a.  For me it takes me to the beginning
of what emacs thinks is the beginning of the line.  But because of the
above described behavior that is incorrect.  The two problems are
definitely related.

  $ echo one two
  one two

Then move the point to this position:

  $ echo one two
            ^-point is now here

Then type C-c . invoking comit-insert-previous-argument and the result
will be:

  $ echo one two two
                 ^-point is now here

The syntax highlighting is, using my own html-like coloration for
description, the following:

  <green>$</green>
    <bold white>echo one</bold white> two <bold white>two</bold white>

C-e always takes point to the end of the line.  C-a takes point to one
of three places depending upon location.

  $ echo one two two
    ^a       ^b  ^c

If point is within "echo one" then C-a goes to position marked 'a'.
If within "two " then C-a goes to position 'b'.  If within the last
"two" then it goes to position 'c'.  And C-e always goes to the end of
the line.

Bob

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: shell mode - how to stop division into bogus fields

[Silvio Levy]

Thanks to Bob and XeCycle for checking out the problem. XeCycle, were
you trying it with -Q?

Bob, your elaboration of the 2nd part of the problem (below) agrees
with what I see, I think.  But your way of expressing it is clearer.

I've made a bit of progress. If I set comint-use-prompt-regexp to "t"
*and* change comint-prompt-regexp to match my csh prompt, <return>
does actually send the interpolated line (rather than just a piece of
it) to the shell. That's the desired behavior.

The problem then comes when I'm interacting with a subprogram -- e.g.,
if I call Mathematica or mysql in the shell, I have to either change
comint-prompt-regexp to match the prompt of whatever software I'm
interacting with at the moment, or erase each prompt before sending
the line.

Silvio


> Silvio Levy writes:
> > In the old behavior, if you went back to that line, edited it, and hit
> > return, the whole line would be fed to the shell, except for myprompt>.
> >
> > In the new behavior, most kinds of editing break up the line into
> > bogus "fields". For instance, suppose you realize you forgot an
> > argument, and you supply it from the kill-ring. You now have
> >
> > myprompt> foo baz bar
> >
> > (where "baz" was dropped in via C-y). Now, if hit return with point on
> > top of "baz", only "bar" is sent - somehow, emacs regards "baz" as a
> > prompt and what comes after as the desired command. (If point is on
> > "bar", likewise) only "bar" is sent.
>=20
> Cannot reproduce your problem.
 
I can reproduce it.  It annoyed me too.  I see this same problem on
emacs 23.3.1 from Debian Sid using emacs -Q.

I have no solution for it however.

> > says that "when point is in input on the same line as a prompt, C-a
> > puts point at the beginning of the input if comint-use-prompt-regexp
> > is nil and at the beginning of the line otherwise."=20
> >
> > In fact, for me (under emacs 23.1.1, called with -q, and having hit
> > M-x shell which opens my default shell, csh), C-a always puts point at
> > the beginning of the "piece" it's on, regardless of the value of
> > comint-use-prompt-regexp.
>=20
> Cannot reproduce this, either.  I'm using GNU Emacs 24.0.91.2
> (x86_64-unknown-linux-gnu, GTK+ Version 2.24.8) of 2011-11-19.
> You can also try `-Q', to see if your distro or local admin broke
> it.

I have different behavior of C-a.  For me it takes me to the beginning
of what emacs thinks is the beginning of the line.  But because of the
above described behavior that is incorrect.  The two problems are
definitely related.

  $ echo one two
  one two

Then move the point to this position:

  $ echo one two
            ^-point is now here

Then type C-c . invoking comit-insert-previous-argument and the result
will be:

  $ echo one two two
                 ^-point is now here

The syntax highlighting is, using my own html-like coloration for
description, the following:

  <green>$</green>
    <bold white>echo one</bold white> two <bold white>two</bold white>

C-e always takes point to the end of the line.  C-a takes point to one
of three places depending upon location.

  $ echo one two two
    ^a       ^b  ^c

If point is within "echo one" then C-a goes to position marked 'a'.
If within "two " then C-a goes to position 'b'.  If within the last
"two" then it goes to position 'c'.  And C-e always goes to the end of
the line.

Bob

--UHN/qo2QbUvPLonB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7MUwUACgkQ0pRcO8E2ULY5MQCeI2XiJ9VaQ9BsA1ep1XmnJKy7
stkAnjHTlfdYAx3ASRFg2ln75kCm1ohz
=Z26r
-----END PGP SIGNATURE-----

--UHN/qo2QbUvPLonB--