Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Maybe someone could help to deal with the next trouble.
The class org.epic.perleditor.actions.FormatSourceAction found in org.epic.source_0.5.46 plugin contains method 'getAnchorString' in which the local string variable 'posAnchor' is defined and initialized with the obscure char sequence that has incorrect for UTF-8 hex view: f6dfa7b2. The Google Chrome and Internet Explorer define the encoding of the source as 'Windows-1251' and show this string as "цЯ§І", which has no sense. So, I don't know how to restore the original characters. I ran into this problem when I tried to make some changes to the pereditor plugin (specific to my RCP application).
IIRC, EPIC inserts the marker before reformatting action to track where the caret has to be moved after it's completed. The marker itself should then be removed from source text. Not sure what your exact problem is and why you're seeing it at all.
Thank you for the reply. When I opened the sources of perleditor plugin In Eclipse as a java project (workspace has UTF-8 encoding set by default) and then started to build it I obtained error that pointed to the described char sequence as incorrecrt UTF-8 symbols. So, I tried to get original chars by opening not modified sources in Google Chrome hoping that it will define encoding correctly. But I've got "цЯ§І" from Chrome. I did not undestand clearly the meaning of 'posAnchor'. But if this value is used just while formatting process, as you wrote, so, it could be any in a manner and it is no sense try to restore original chars - esier will be to leave it as "цЯ§І".
Even if this shouldn't matter for execution, you probably shouldn't change the byte sequence used in the marker. The source files are encoded in iso8859-1 (rather than utf8), so you can fix that. You can select a file encoding in Properties of this single source file if you don't want to change the global workspace setting. Alternately (and maybe better) you could replace the literal iso8859-1 characters with their escape sequences (\uxxxx) = pure ASCII.
Yes, using escape sequences for these characters is an exactly better way, thank you.