Subject: bug#78508: Tramp confused by bracketed paste after remote prompt

From: Daniel Colascione <[email-masked]>
Date: Thu, 22 May 2025 12:02:01 -0400

On May 22, 2025 7:25:47 AM EDT, Michael Albinus <[email-masked]> wrote:
>Daniel Colascione <[email-masked]> writes:
>
>Hi Daniel,
>
>>>> When the remote shell emits bracketed paste escape codes (as zsh does
>>>> even when TERM=dumb), tramp ends up timing out unable to find the shell
>>>> prompt on initial connection.
>>>
>>>Have you checked the recipe from the Tramp manual in (info "(tramp)
>>>Frequently Asked Questions") ?
>>
>> It shouldn't be necessary to do that. Sometimes modifying the target
>> system isn't all that straightforward, and control sequences should be
>> straightforward to strip. There's already an attempt to strip ANSI
>> color, yes? It's not like Tramp is trying to avail itself of the
>> opportunities SSH provides to make noninteractive use feasible.
>
>Tramp won't go into the prompt parsing business. Filtering ANSI color
>sequences out was a compromise a while ago. You let feel me that it was
>an error to do so.

We live in a world in which people spew hard coded terminal escape sequences constantly, often without regard for isatty, TERM, or basic common sense. Tramp can either work or refuse to work. It's no excuse to say people are just all holding it wrong when other systems that talk to shells work fine.

>> Failure mode is just "when I try to use Emacs to connect to
>> this family of hosts, it hangs. VSCode works. I guess I'll stick with
>> that"
>
>That's unfair, and you know it.

It's not only fair, but an accurate paraphrase of what's actually happened.

>Have you tried the patch I've shown?

Doesn't help. This system emits the control codes regardless of TERM. Is that wrong? Yes. Are people going to stop? No, they are not.