bug#36940: tests slowness and failure after recent Tramp changes

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: eggert@cs.ucla.edu,  stefan@marxist.se,  36940@debbugs.gnu.org
> Date: Mon, 26 Aug 2019 11:22:16 +0200
> 
> > Are the strings returned by the remote compared as unibyte strings?
> > If not, maybe there's a subtle bug in the comparison that does fail.
> > For example, could it be that you decode those strings as utf-8, not
> > as utf-8-hfs?  The latter should produce back the composed characters,
> > I think.
> 
> The error happens while searching in a process buffer, which is set properly:
> 
> 14:40:39.573073 tramp-open-connection-setup-interactive-shell (5) # Setting coding system to `utf-8-hfs' and `utf-8-hfs-mac'
> 
> But the search string needs to be normalized as proposed by you. Will do.

Sorry for bothering you, but now I am confused.  If the process
buffer's contents is decoded with utf-8-hfs, then decoding should have
composed the characters back, I believe.  So the text to be searched
in the buffer should use the precomposed character U+03AF GREEK SMALL
LETTER IOTA WITH TONOS.  Is that so?  And if so, is the problem with
the regexp you pass to re-search-forward?  Then where did that regexp
come from -- maybe the problem happens while you produce that regexp?

Feel free to ignore my questions if they are just a distraction, due
to my unfamiliarity with the text internals.