bug#63539: 29.0.90; TRAMP fails to detect shell prompts containing ]

[Spencer Baugh <sbaugh@janestreet.com>]

Michael Albinus <michael.albinus@gmx.de> writes:
>>> Multiple escape codes are not regarded indeed, my patch did expect that
>>> there is not more as one escape code at the end of the shell prompt.
>>>
>>> Your example is an indication of escape codes, mixed inside the shell
>>> prompt. My first attempt (removing all escape codes from the buffer
>>> region) did handle that. But as said, there were other regressions with
>>> that attemot.
>>
>> What's wrong with my diff, though?  It produces behavior which is much
>> closer to how TRAMP behaved before your change, while still fixing my
>> issue.
>
> I've pushed another change to master which goes back to my first
> approach: Remove escape sequences in the buffer, before you look for the
> prompt.
>
> The difference is now, that this happens *only* in the initial
> connection phase with a remote host, and not later. After that phase we
> have a PS1 setting applied by Tramp, which is escape sequences free.
>
> This approach should avoid the problems I've seen when I've applied a
> similar change some days ago. I still need to run all regression test
> cases, but a check for crucial tests tell me that we could be optimistic
> now :-)
>
> Could you pls check this change?

Thanks, this works with both my prompts.  (Fixing both the regression
and the original bug)