GNU bug report logs - #36940
tests slowness and failure after recent Tramp changes

Previous Next

Full log

Message #109 received at 36940 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: eggert <at> cs.ucla.edu, stefan <at> marxist.se, 36940 <at> debbugs.gnu.org
Subject: Re: bug#36940: tests slowness and failure after recent Tramp changes
Date: Mon, 26 Aug 2019 12:59:33 +0300

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: eggert <at> cs.ucla.edu,  stefan <at> marxist.se,  36940 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.