[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comint-insert-input on non-command lines: A trivial fix, a quibble,

From: Miles Bader
Subject: Re: comint-insert-input on non-command lines: A trivial fix, a quibble, and a bug
Date: Wed, 10 May 2006 15:27:45 +0900

Luc Teirlinck <address@hidden> writes:
> I was talking about people who wanted to use `C-c RET' to insert old
> output at the current prompt.  Given the current code, people who want
> that have to set comint-use-prompt-regexp non-nil and hence can not
> use fields.  That is what seems weird to me.

Yes.  I think that by and large the user-visible behavior should be the
same regardless of what value `comint-use-prompt-regexp' has -- other
than the obvious consequences of using or not using fields of course
(e.g., the behavior of C-a).

I find comint-insert-input a confusing command, as its behavior is so
context dependent.

The current behavior of `C-c C-m' on an output field (when
comint-use-prompt-regexp is nil) seems not very useful to me; in a shell
buffer, for instance, it just does nothing.

For the keybinding case, at least, a simple behavior like "always insert
the current field (whether input or output) or line (when
comint-use-prompt-regexp is non-nil)" would seem a lot cleaner, easier to
explain, and more useful.

For the mouse-binding, in a shell buffer for instance, I think the same
simple behavior would also be better; perhaps for some modes, alternative
handling of output fields is better -- but maybe a cleaner way to handle
that would be to just bind other command to mouse-2?

"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]