[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: bug#36940: tests slowness and failure after recent Tramp changes
Date: Mon, 26 Aug 2019 12:59:33 +0300

> From: Michael Albinus <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> 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.

reply via email to

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