Here are the reports of the shell mode "invisible force field" bugs, that were closed but not fixed, then opened again, then closed again, and still not fixed, because the bug was apparently put back in, for reasons I can't fathom.

I still suffer from this bug every day, and have developed elaborate work-arounds involving many extra key presses that I've committed to muscle memory and do without thinking now.

Well actually I do think about how stupid it is this isn't fixed, and how stupid it is somebody designed and implemented it in the first place, and how stupid it is that somebody put the bug it back in after somebody fixed it, every time I have to work around it, which is regularly, quite often.

Shell mode didn't originally have this problem, not in UniPress/Gosling Emacs, and not in the original Gnu emacs. Somebody actually came up with it and programmed it and got it past the gatekeepers and reviewed and committed in the main code (possibly twice!), and now nobody will acknowledge that it is a problem, even after Daniel's extremely detailed step-by-step bug report showing how to reproduce it (as if it didn't happen many times a day under normal usage), and my reminder that it was back.

The irony is that the broken shell mode is supposed to be one of the primary and most powerful advantages and flexible ways to use emacs, which can be synergistically combined with keyboard macros (which are also broken) to make on-the-fly macros that copy and paste and edit the long-lined output of one program and feed it into another (which can go terribly wrong, because of these two bugs and their interactions).

i.e.: split the shell window, switch to the top output window, position the cursor on the first line of output from a previously run command in the top window, switch to the bottom input window, position the cursor at the end on the prompt, switch back to the input window, start a keyboard macro, copy a line of output from the top output window, move to the next line (invoking the visual-lines bug), switch to the bottom output window, yank the line of text and edit it into a new input or command, and hit return to enter it into the shell (invoking the shell invisible force field bug), then switch back to the first window, end the macro, then ^U <count> ^X e repeat as much as needed. But no, you get hit by the visual-lines bug in the top output window, and the invisible force field bug in the bottom input window, again and again, spewing invalid mangled commands to the shell that do god knows what. It's like getting Eiffel-Towered by two bugs at once, one in each window!

https://debbugs.gnu.org/db/37/3735.html

>Introduction:

>In shell mode, editing of command output and previous command lines into
new command lines and submission of those new command lines are quite
broken.

>For example, editing a previous command's output lines to turn them into
a new command line and then typing RET (executing comint-send-input) to
try to submit it to the shell frequently submits only part of the line,
and C-a and C-e frequently stop somewhere in the middle of the line.

>These problems severely reduce the usability of shell mode, which,
before the breakage, was great for editing command output into related
command lines (and editing it in general).

>Also, note that the partial submission can be very dangerous. For
example, trying to edit an output line "one_thing" (e.g., from an
"ls /dir" command) into the command line "rm -rf /dir/one_thing" can
easily result in the command line "rm -rf /dir/" instead.

>The problem appears to be because of changes made to distinguish
shell-prompt text from command text (and maybe also changes made to
highlight error lines in command output. Apparently, boundaries
between runs of text with different attributes cause commands to hit
those boundaries instead of their normal boundaries (e.g., line
boundaries for C-e, C-a, RET (comint-send-input)).

>Version information: This problem:

>- did not exist in Emacs 20.7.2,

>- first appeared somewhere in Emacs 21.x,

>- exists in Emacs 22.2.21 (NTEmacs and Debian Etch's emacs22 package,
version_22.2+2-5), and

>- exists in Emacs 22.3 (built from the source in http://ftp.gnu.org/pub/gnu/emacs/emacs-22.3.tar.gz as of 2009-06-30).

>Details:

>Most of the problems occur when editing a line that originally was a
command output line and that is being edited into a new command line,
or when typing RET (to run comint-send-input) on such a line to execute
the command line.

>However, some of the problems also occur when editing or when typing RET
on a line that was a previously entered command.

>The main subproblems are:

[Pages of detailed step-by-step instructions to reproduce it under many circumstances omited]

https://debbugs.gnu.org/db/18/18135.html

>Daniel submitted this excellent bug report for a bug that has really been causing me problems, which was claimed to have been fixed, but definitely is not fixed in Emacs 23.3.1 or 24.3.1.

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3735

>Chong mentioned it was fixed in Emacs 23, but said he didn't recall who fixed it.

>Apparently it was put back in and has been back for a long time.

>Could you please investigate to see who fixed it, and who put it back in, and WHY?

>This bug REALLY needs to be fixed, as it makes shell mode practically unusable, and as Daniel described, can lead to some very dangerous and inexplicable accidents.

>And whoever put the bug back in after it was fixed last time needs to stop doing that, please.

>-Don